DWC 3.2.0 beta-1 SBC: "M84 XYE" causes parser error
I just started my journey with RRF on a SKR 1.4 Turbo. Today, I switched from an ESP based connection over to the SBC integration. However, uploading some gcode that had worked earlier today, I received the following error:
Failed to get file info for CaribouSKR_PETG_calicat_calico_0.2000mm.gcode Operation failed (Reason: CodeParserException in GetFileInfo: Failed to parse major M-code number (otors))
It seems that the parsed had some issues with the very last gcode in the file, which reads
However, the same gcode worked in the files when uploaded via ESP.
Can you confirm that you are also running DSF version 3.2beta1 on the SBC?
$ dpkg --list | grep Duet ii duetcontrolserver 3.2.0-beta1+1 armhf Control server application for Duet 3 series ii duetruntime 3.2.0-beta1+1 armhf .NET Core runtime libraries for the Duet software framework ii duetsd 1.0.7 all Virtual SD card directory for the Duet software framework ii duetsoftwareframework 3.2.0-beta1+1 armhf Meta package for the full Duet software framework ii duetwebcontrol 3.2.0-beta1+2 all Official web interface for Duet electronics ii duetwebserver 3.2.0-beta1 armhf Optional web server for Duet 3 series
thanks for the report, this is one for @chrishamm
I cannot confirm this problem.
M84 XYEis correctly parsed by DSF and your error message suggests that you have an unescapted
Motorsexpression somewhere in your file. If that is not the case, please provide the full G-code file and I'll look into it again.
docbobo last edited by docbobo
You are right, it seems to be slightly more complicated than that. Even though I cannot upload my gcode file here - upload always fails with an error (?) - I was able to reduce the problem to exactly one line:
M84 XYE; disable motors
A gcode file that just contains this line will produce the error. Adding a whitespace in front of the semicolon seems to fix this problem, btw.
Just checked - that even produces the same error when pasted into the GCode command box at the top of DWC.
Thanks for sharing those details. I'll fix it in 3.2-b2.