Posts made by deadlock

@dc42 I'll try to run the Gcode while cutting some foam so I can pause it while it does the thing to know the exact region in Gcode that causes issues

Thanks to your help I was able to get it up and running. Final Gcode was slightly different as I decided to make a tool change in the middle, but everything works nicely now.
Thanks!

@T3P3Tony Here it is, same setup in F360 CAM, just WorkBee postprocessor
Still not done reprinting parts but seemed fine till I stopped it because I noticed a crack on a part.
working.GCODE

@gloomyandy here's my config.g, it's a little bit messy with incorrect comments as I changed config itself but forgot to change the comments describing it, I should fix it later.
config.g
Following @Sindarius suggestion I changed postprocessor to the WorkBee one and it seems to work at first glance, can't test further as my crashes made my CNC suffer more than I thought and I'm in process of reprinting parts.

@chrishamm it does, also I'm using work XYZ as I'm using endstops to define machine limits and separate XYZ systems based on the placement of the workpiece which I set by hand. The spiral ramp down move starting at N300 works fine too so the FANUC style syntax seems to work fine.

@chrishamm nope, it does full plunge into the workpiece and moves at full depth, just like Gcode viewer interprets it

@gloomyandy when I got the CNC it was running on 3.4.0beta4, I've updated to 3.4.5 and issue persists.
RRF doesn't seem to dislike the syntax with persistent G1 and just XYZ parameters changing as on the 2nd operation (2Dadaptive2) it seems to work fine, makes a ramp as told to.
I'm operating it in the CNC mode, I'll post config.g this evening.

@jay_s_uk I'm touching off the workpiece, Z0 is on the top surface, everything above is Z positive, Z negative is into the workpiece, that's why retracts should be to Z15

I got a CNC router running on RRF and I've been trying to use it. My first attempts at milling ended up with crashes due to hardware issue but it has been resolved since then.
Now I'm facing vastly different issue as seems like RRF interprets Gcode in a matter different from other softwares. I'm using F360 CAM to generate Gcode, RepRap postprocessor. Both F360 simulation and NCViewer show nice retraction to Z15 using G0, just like it can be seen in the Gcode.

(Please ignore very suboptimal settings as I wanted to verify if maybe too high chipload is the issue)
RRF on the other hand ignores this G0 Z15 and takes full plunge through the workpiece resulting in a pretty bad crash. At first I thought that it's firmware issue so I updated it but it crashed again, out of curiosity I checked the Gcode in GcodeViewer (previously I used NCViewer as it's faster to use and I can edit Gcode on the fly) and results from it are vastly different which is the reason of the crash.
These blue straight moves on the bottom shouldn't exist, they don't show up in F360 nor NCViewer.

Is there any way to fix this?
This is the code I'm struggling with
Trouble_making.g