Solved RRF[3.5.1]/RRF[3.5.0] : Gcode bad command error
-
If I simulate the gcode, I get some errors like bad command or message box stating expected integer after Y.
Sometimes error says "C1 " instead of G1. When I look back at the line number in Gcode, Line looks ok.Because when I run it the second time, or simulate second time, bad command error either does not come at all, or it comes at a different line.
My problems are similar as posted in the thread :
https://forum.duet3d.com/topic/35553/bad-command-error-using-rrf-3-5-0-and-3-5-1-using-duet2-wifi/2- I tried with different versions of cura, problem remains same.
- Everytime line number and error changes for bad command, even during simulating
- I tried 3.5RC4, such problems are not faced before 3.5.0.
-
@JayT What board do you have and can you share the affected G-code file?
-
I am using Duet 2 wifi. Will share a few gcode files. As stated, this problem isn't in 3.5 RC4 much.
I am not able to upload gcode file directly. How do I share?. -
@JayT said in RRF[3.5.1]/RRF[3.5.0] : Gcode bad command error:
How do I share?.
dropbox or some sort of cloud storage if it's too large to upload
-
@Phaedrux : @chrishamm : It uploaded well please see with RRF 3.5.1version.
-
@JayT this sounds more like an SD card reading problem. Check SD card isn’t nearly full, back it up, then reformat it or try a fresh SD card. See https://docs.duet3d.com/en/User_manual/RepRapFirmware/SD_card#troubleshooting-sd-card-issues
Ian
-
@droftarts :
I will check on this , however...If its SD card issue, then why don't I get same problem when I flash 3.5 RC4/3 or on older version of RRF, for the same gcode file?
Can you try to simulate them in your printer with RRF3.5.1 for once, with Duet 2 wifi? -
@JayT I need to do a test Duet 2 setup next week anyway (I don’t have any printers running Duet 2 any more, only a 2D plotter), so will try simulating your files then.
Can you share your config.g, and any other files that config.g depends on (ie macros called) and daemon.g if used? Then I can set my Duet up the same, just with nothing physically connected.
In the meantime, try a different SD card. I don’t know if there’s been any changes to the SD card read/write code between 3.5.1 and older firmware that makes marginal cards fail, but there may be.
Ian
-
@droftarts : Please see config below. I am not using daemon.g
; General preferences G90 M83 M550 P"INFD300s" M551 P"INFD300" ; Network ;M552 S1 M552 S-1 M586 P0 S1 M586 P1 S0 M586 P2 S0 ; Drives M569 P0 S1 M569 P1 S1 M569 P2 S1 M569 P3 S1 M569 P4 S1 M569 P5 S1 M584 X0 Y1 Z2:3:4 E5 M350 X32 Y32 I0 M350 Z16 E16 I1 M92 X160.0 Y160.0 Z2133.33 E932.00 ;change as per machine M566 X720.00 Y720.00 Z300.00 E600.00 M203 X8400.00 Y8400.00 Z420.00 E8400.00 M201 X3000.00 Y3000.00 Z30.00 E250.00 ;M-curr M906 X2200 Y2200 Z1600 E800 I50 M84 S30 ; Axis Limits M208 X0 Y0 Z0 S1 M208 X300 Y300 Z304.1 S0 ; filament Sensor M591 D0 P7 C"exp.e3stop" R15:300 L7 E17 S1 ; Endstops M574 X1 S1 P"xstop" M574 Y1 S1 P"ystop" M574 Z1 S1 P"zstop+e0_stop+e1_stop" ; Z-Probe M950 S0 C"exp.heater3" M558 P9 C"^zprobe.in" H5 F120 T6000 G31 P500 X0 Y0 Z1.038 ; Auto level, coordinates as per motor order in M584 M671 X-17.66:297.34:140.00 Y-5.00:-5.00:327.61 S5.0 ;points position with left right ¢er ; define mesh grid M557 X30:300 Y30:300 S20 M376 H5 ; End Limits M950 J1 C"exp.e4stop" M581 P1 T2 R0 S1 M582 T2 M581 P-1 T2 M581 P1 T0 R0 S1 ;PA M572 D0 S0.055 ; Bed Heater M308 S0 P"bedtemp" Y"thermistor" T100000 B4138 M950 H0 C"bedheat" T0 M307 H0 B0 S1.00 M140 H0 M143 H0 S105 ; Extuder Heater M308 S1 P"e0temp" Y"pt1000" M950 H1 C"e0heat" T1 M307 H1 B0 S1.00 M143 H1 S320 ; cooling Fans M950 F0 C"fan0" Q500 M106 P0 S0 H-1 M950 F1 C"fan1" Q500 M106 P1 S0 H-1 ; Tools M563 P0 D0 H1 F0 G10 P0 X0 Y0 Z0 G10 P0 R0 S0 ; Miscellaneous M575 P1 S1 B57600 M501 M911 S21 R22.5 P"M913 X0 Y0 G91 M83 G1 Z5 E-5 F1000" M929 S3 P"/macros/log/DEBUG.txt" M17 -
@JayT said in RRF[3.5.1]/RRF[3.5.0] : Gcode bad command error:
; Network
;M552 S1
M552 S-1I notice you are not enabling networking. Are you running the simulation from a PanelDue?
M929 S3 P"/macros/log/DEBUG.txt"
Is there a reason you're running debug logging? This will impact performance, and means a lot of writes to the SD card. It could be that the level of logging has increased in 3.5.1, and is causing what was a marginal problem on the SD card to become a real one.
I set up a bench test, with a Duet 2 WiFi on RRF 3.5.1 and PanelDue, powered by USB, with your config.g. I enabled networking. I simulated all three files, which all completed fine.
08/05/2024, 16:24:30 M37 P"0:/gcodes/1714799702668-30mmtestcube_44min.gcode" Simulating print of file 0:/gcodes/1714799702668-30mmtestcube_44min.gcode 08/05/2024, 16:24:35 File 0:/gcodes/1714799702668-30mmtestcube_44min.gcode will print in 0h 45m plus heating time 08/05/2024, 16:24:50 M37 P"0:/gcodes/1714799702737-cfffp_flex_dino_keychain.gcode" Simulating print of file 0:/gcodes/1714799702737-cfffp_flex_dino_keychain.gcode 08/05/2024, 16:26:36 File 0:/gcodes/1714799702737-cfffp_flex_dino_keychain.gcode will print in 1h 31m plus heating time 08/05/2024, 16:26:48 M37 P"0:/gcodes/1714799702831-pcb-cover_500_5_15h.gcode" Simulating print of file 0:/gcodes/1714799702831-pcb-cover_500_5_15h.gcode 08/05/2024, 16:29:41 File 0:/gcodes/1714799702831-pcb-cover_500_5_15h.gcode will print in 5h 44m plus heating timeLooking at the DEBUG.txt file the logging created, there's a lot of writes during simulation. I think this is causing a degraded SD card problems. Please try with a new SD card.
Ian
-
undefined Phaedrux marked this topic as a question
-
@droftarts said in RRF[3.5.1]/RRF[3.5.0] : Gcode bad command error:
I notice you are not enabling networking. Are you running the simulation from a PanelDue?
Yes, I ran simulation via PanelDue, not from DWC.
Thanks for trying. If gcode simulated well, ***Will try with new SD card.@droftarts said in RRF[3.5.1]/RRF[3.5.0] : Gcode bad command error:
Is there a reason you're running debug logging? This will impact performance, and means a lot of writes to the SD card. It could be that the level of logging has increased in 3.5.1, and is causing what was a marginal problem on the SD card to become a real one.
Is that so for 3.5.1? I am writing to SD card with debugging enabled, to debug problems if faced during printing. This log file helps me to understand at times if the print fails or there are problems w.r.t gcode, if dwc isn't connected.
What solution do you propose then? Is there a way to create log some other memory place? -
@droftarts :
I see this is happening only with 1/2 versions of cura generated Gcode. If I use latest Cura version gcode, I don't see this problem much. However, I will see if stopping the log , helps anyway.
Also, I do see that this problem does not appear in previous versions of RRF. May be something is changed w.r.t certain gcode interpretation.@Phaedrux : Please mark this as solved.
-
undefined droftarts has marked this topic as solved
