[Issue#184] Some issues where starting the job the z axis crashes on top.

#1 – neilferreri 于 2017-08-07

@kikolobo I use Fusion 360 with CNCJS all the time with no issues. Are you using the default GRBL post in Fusion? If not, use it. If you are, can you share your Fusion file?

#2 – kikolobo 于 2017-08-07

@neilferreri I think the issue is with the post processor. I am using the inventables easel post processor, but when I run the program I found that the console reports this error:

So my guess is that it is related to the way CNCJS sends the G53 command, but its also related to the way the post processor makes the nc file..

I will try to use standard GRBL file and see what that does.

Thanks for the help!
PS:If it does not work, il post the file no problem!

#3 – neilferreri 于 2017-08-07

@kikolobo That error is likely from a tool change (M6) command. I remove them manually when using cncjs,but you can ignore it (as long as you are comfortable with that error).
The easel post has a 15mm Z-lift after going to a starting XY. Based on your video, you don’t have room for that. Your starting Z-height is only 7.4mm down from your max Z. There really shouldn’t be a reference to G53 in your code at all. Did you look at the g-code and see a G53 somewhere? G53 refers to the absolute machine coordinates. All of your work is done in your WCS, or Work coordinate system.
Try the default grbl post as it will lift to a height set by your CAM operation in Fusion, a combination of “Clearance Height” and “Retract Height” depending on how you have those set up. Your ramping settings could cause those to change as well.
Basically, that foam is too thick for your current settings and setup.

#4 – cheton 于 2017-08-07

CNCjs will not break a line into two or multiple lines, so you won’t see G53 G0 Z-10 being separated to G53 and G0 Z-10. To see what commands being sent to Grbl, you can run cnc -vvv to watch the output.

The character-counting streaming protocol is used by CNCjs for streaming a G-code program to Grbl, this method will delay the ok or error response, in certain cases the reported line may not be the actual line of error. Just as @neilferreri mentioned, the actual error might be caused by a M6 tool change command.

Could you post your G-code using the post-processor? Thanks.

#5 – nsfilho 于 2017-08-22

Probably the cause is in the Post Processor. I use Fusion 360 to do CAM too. After test many of them (post processors), I discovery of some of than, like xcarve.cpl needs changed before you use this file.

Some parameters is harded code, i.e. about homing before start and the position after the end of gcode default program.

An important thing: in the xcarve.cpl the direction of Z axis are inverted to start and stop. Be sure to read the xcarve.cpl and configure properly the parameters before use this king of gcode….

#6 – nsfilho 于 2017-08-22

If you would, I can attach my post processor for fusion 360 for you…. and in this way, you for you test to see if this solve your problem.