Gcode weird interpretation?

deadlock

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

jay_s_uk

@deadlock how are you setting your Z workplace position? where are you setting 0 to before it starts etc?
these 3 lines (11 to 13) take you down to 0.11mm from Z0

N40 Z15
N45 Z5
N50 G1 Z0.11 F50

deadlock

@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

gloomyandy

@deadlock What version of RRF are you running? I wonder if the use of line numbers and missing G0 operations is causing a problem?

N35 G0 X28.815 Y0.51
N40 Z15
N45 Z5
N50 G1 Z0.11 F50

I assume you are operating in CNC mode with M453? According to this https://docs.duet3d.com/User_manual/Reference/Gcodes#m453-select-cnc-device-mode the above type of move should be valid when in that mode. Probably a good idea to post your config.g file so folks can see how you have things set up.

deadlock

@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.

chrishamm

@deadlock I suppose it's just the G-code viewer that's off? One for @Sindarius

deadlock

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

Sindarius

@deadlock So the G-Code Viewer does not appreciate sequential commands

For example

G0 X10 Y10 Z10
X11

I am implementing a fix for this in the viewer. It's not something that I run into with fdm printing but know it's more common in milling applications.

The one thing that I need to look at is the G2/G3 arcs do not look right on the surfacing in the viewer so I need to check why those do not look right.

chrishamm

@deadlock In order for RRF to process FANUC-style G-code like

G1 X1234
X234
Y567

the Duet must be set to CNC mode via M453 (or Laser mode) - it will NOT work in the default FFF mode. Can you confirm that the Status panel shows "Mode: CNC" in the top right corner?

deadlock

@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.

deadlock

@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.

T3P3Tony

@deadlock please post the new gcode that appears to work.

deadlock

@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

T3P3Tony

@deadlock thanks, so the new version is using gcode with the movement command on each line. We will continue to investigate why the fanuc style caused the crash.

deadlock

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!

Sindarius

@deadlock looks good!

dc42

@deadlock can you provide a simple sequence of GCode commands that demonstrates the issue when running firmware 3.4.5 ?

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