Gcode weird interpretation?

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