Fusion 360 & post processor

Software / Firmware
141

Ted, The G0 patch I implemented in RC7 works but is not backwards compatible with the old G0/G1 combination if people rely on G0 behaving like G1. They shouldn’t be but all kinds of crazy shit happens out there. If anyone’s interested in the code I can post it here or email.

Are you sure about the steppers maxing out at 60RPM? Or do you mean 600RPM? At 60RPM and a 5/16-18 screw that 60/18=3.333 IPM (84.666 MM/M) max. What thread did you do the math in. FWIW, I’m actually running 8 micro steps on my machine.

I’ve been having problems with my VBX bearings locking up after a while and with MDF dust getting into the belts. The dust in the belts can cause the belt to skip teeth. I’ve been looking into hooking up a vacumn system but I’m afraid a dust shoe will cut down on travel too much. I should have done this a long time ago from the looks of my shop :frowning:

Drew

142

Not speed maxing out, the torque. Above 60rpms and it rapidly falls.

I don;t trust my machine alone. So I am always nearby. I hand vacuum the cuts every few minutes. Now that the software side looks to be getting squared away maybe I can trust it more and add a dust shoe soon. (after the big boy since it already has a dust shoe built in).

143

Looks like we should toss micro steps on the Z entirely. With no micro stepping we’d get 1/18/200 inches per step which is .0003". More than enough for what I’m doing.

144

Doesn’t seem to make any kind of difference either way. Since we can’t benefit from added speed it is a wash, pull some jumpers and re-flash with new steps, no problem.

For me though If I switch it I will always have to put out at least 2 new firmware with each update. No thanks. I might add a laser based firmware that would mean 4 to maintain.

145

You do always need some micro stepping full steps sound horrible and can have oscillations.

146

Rayn to avoid the fake feedrate try to invert the lines that put xy and z movements. Do first the xy movement and then the z.

147

If you want to upload a file that I can run the Post on then I can do my own debugging but for now you can try making the change below to get rid of those dummy lines. This may keep it from spitting out the useless feed commands if there is no move to be made on the axis.

In the onRapid function:

Change Line:
if (!properties.useG0) {
writeBlock(gMotionModal.format(1), x, y, feedOutput.format(highXYFeedrate)); //write G1 command for XY
writeBlock(gMotionModal.format(1), z, feedOutput.format(highZFeedrate)); //write G1 command for Z
} else {
writeBlock(gMotionModal.format(0), x, y, z);
}

To this:
if (!properties.useG0) {
if (x || y)
{
writeBlock(gMotionModal.format(1), x, y, feedOutput.format(highXYFeedrate)); //write G1 command for XY
}
if(z)
{
writeBlock(gMotionModal.format(1), z, feedOutput.format(highZFeedrate)); //write G1 command for Z
}
} else {
writeBlock(gMotionModal.format(0), x, y, z);
}

148

@vicious1 : I just tested the code I posted above. It seems to get rid of the empty feed commands in the gcode. I didn’t do a test cut though. I’ll leave that to you.

149

You are the man! Ive been trying to get all the orders out and run some errands. I should be back in an hour or so to test it out. I appreciate all the help.

150

One thing you might want to change is to do any Z motion before the XY. This gives the tool a better chance of being out of the part.

151

Rapids should only be done at a safe Z height to begin with but not a bad idea to reverse the order just in case.

152

This is starting to become amazingly polished, Leo69 The new updates are perfect.

Now, Not one to leave good enough alone anymore I have some more questions.

#1

capabilities = CAPABILITY_MILLING;
tolerance = spatial(0.002, MM);
highXYFeedrate = (unit == IN) ? 500 : 2100; //specify XY axis rapid feed rate in inches:mm
highZFeedrate = (unit == IN) ? 100 : 420; //specify Z axis rapid feed rate in inches:mm
  • Can this be moved down into the User defined section to set these values in the options window for those who might want to speed it up? I tried just moving it down and that is a no go, is there a different format needed, Also can I take some of those options out somehow?

#2 - Why is M106 getting triggered? I see ductsoup’s edit but why not use the coolant trigger or something else? Should I leave this in I guess it doesn’t hurt anything but doesn’t seem like best practice.

#3

N40 G1 X24.683 Y97.731 F2100
N45 G1 Z7 F420
N50 G1 Z2 F420
  • If we can switch the order of operations on the first 3 generated moves we can get rid of the extra z moves and use the clearance plane like intended. right now it is moving over than up, we need up then over.

*Side note I hope this doesn’t offend any of you guys that have originally put this together That I am just jumping in here and making changes. I can move this somewhere else and fork it if you would prefer. Just let me know publicly or privately and I will move it. I don’t want to step on anyone’s toes just striving for a more perfect experience.

153

Which features did you want to add/remove to user defined section? Comment out or delete the highXYFeedrate and highZFeedrate variable declarations and move them as shown below:

//highXYFeedrate = (unit == IN) ? 500 : 2000; These can be commented out or deleted completely
//highZFeedrate = (unit == IN) ? 100 : 400; These can be commented out or deleted completely

// user-defined properties
properties = {
writeMachine: true, // write machine
writeTools: true, // writes the tools
preloadTool: true, // preloads next tool on tool change if any
showSequenceNumbers: false, // show sequence numbers
sequenceNumberStart: 10, // first sequence number
sequenceNumberIncrement: 5, // increment for sequence numbers
optionalStop: true, // optional stop
separateWordsWithSpace: true, // specifies that the words should be separated with a white space
useG0: false, // allow G0 when moving along more than one axis,
highXYFeedrate: (unit == IN) ? 500 : 2000, // Set XY rapid feedrate - only active if useG0 is false
highZFeedrate: (unit == IN) ? 100 : 400 // Set Z rapid feedrate - only active if useG0 is false
};

154

A couple of folks suggested putting the rapid z moves before the XY. I think I’m going to go ahead and patch the file and repost it with the Z moves first. Gimme a few minutes

155

Hey guys, do me a favor and test this new post-processor when you get time. I implemented most of the suggestions in the last few posts. Also removed a hard-coded Z +10 move that was added in V5. Now that the Z moves come before the XY rapids, it wasn’t necessary anymore. The XY and Z rapids are in the user-defined section but are in MM units so keep that in mind.

MPCNC_Fusion360_V8_SDcard.zip (5.01 KB)

156

Soooo Close.

There is a stray z move at the very end, and no feedrate for the last rapid move home.

157

`G1 X181.103 Y11.18 Z-6.553 F240
G1 X181.111 Y11.182 Z-6.483 F240
G1 Z7 F400
G1 Z15
G1 X0 Y0 Z15
M107
M84; Turn steppers off’

The Z7 should be the last move it is to the clearance plane. The z 15 is not needed, and the move home is not needed. The last move should just be up.
Just to really fine tune it switch to showSequenceNumbers: false, and that beggining M106 and ending M107 shouldn’t be there (if everyone want them I can just comment them out, But I don’t really think the ramps power up an unused port is ideal). I don;t think too many have a spindle power switch.

158

The Z15 and origin move at the end are hard-coded. I can go ahead and remove them. If the clearance plane is set then none of these hard-coded moves should be necessary. Easy enough to patch. I’m still scratching my head trying to figure out the mystery of the M106/M107 commands in this post. We’ll get there…

159

The 106/7 are hard coded as well but the first is commented with ductsoup

160

There are a few other things in there I am bot sure why they are there. I swear I saw a post generator on the fusion site but can’t find it now. Seems like there is some fluff in there I wouldn’t mind starting over. Now that I’m learning this a bit compared to arduino/c++.