[bug] 3.5.1+SBC: M37 simulation starts printing! [SBC mode]

resam

I'm running a Duet2 with SBC on the latest 3.5.1.

I uploaded a new print gcode file and started a simulation job via the SBC HTTP API. This piece of code is able to talk to SBC and direct-RRF boards using the new API and old rr_* API. It first tries the old API, which used to fail with a clear error, to then switch into "new-API" mode and try again.

In the DSF changelog I found this:

Added rr_ compatibility layer to DuetWebServer (HTTP calls in standalone mode)

This means that my code now always auto-detectes the old rr_* API, instead of switching over to the new one when available.

Now to the actual issue at hand:

Sending the following request causes the printer to actually start printing the file, instead of running a simulation job as intended by M37!

curl -vvv 'http://192.168.1.42/rr_gcode?gcode=M37%20P%220%3A%2Fgcodes%2Ftest.gcode%22'

Producing these SBC log from DWC/DSF/DCS:

May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Hosting.Diagnostics[1] Request starting HTTP/1.1 GET http://192.168.1.42/rr_gcode?gcode=M37%20P%220%3A%2Fgcodes%2Ftest.gcode%22 - -
May 26 12:40:56 voron DuetWebServer[634]: DuetWebServer.Singletons.SessionStorage[0] Session 2d8c1c548454408ab4a470c857aa2725 added (readWrite)
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Routing.EndpointMiddleware[0] Executing endpoint 'DuetWebServer.Controllers.RepRapFirmwareController.DoCode (DuetWebServer)'
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3] Route matched with {action = "DoCode", controller = "RepRapFirmware"}.
Executing controller action with signature System.Threading.Tasks.Task`1[Microsoft.AspNetCore.Mvc.IActionResult] DoCode(System.String) on controller DuetWebServer.Controllers.RepRapFirmwareController (DuetWebServer).
May 26 12:40:56 voron DuetWebServer[634]: DuetWebServer.Controllers.RepRapFirmwareController[0] [DoCode] Executing code 'M37 P"0:/gcodes/test.gcode"'
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Mvc.Infrastructure.ContentResultExecutor[1] Executing ContentResult with HTTP Response ContentType of application/json
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2] Executed action DuetWebServer.Controllers.RepRapFirmwareController.DoCode (DuetWebServer) in 104.242ms
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Routing.EndpointMiddleware[1] Executed endpoint 'DuetWebServer.Controllers.RepRapFirmwareController.DoCode (DuetWebServer)'
May 26 12:40:56 voron DuetWebServer[634]: Microsoft.AspNetCore.Hosting.Diagnostics[2] Request finished HTTP/1.1 GET http://192.168.1.42/rr_gcode?gcode=M37%20P%220%3A%2Fgcodes%2Ftest.gcode%22 - - - 200 27 application/json 163.1642ms
May 26 12:40:57 voron DuetControlServer[1649]: [info] Selected file 0:/gcodes/test.gcode
May 26 12:40:57 voron DuetControlServer[1649]: [info] Starting file print
May 26 12:40:57 voron DuetControlServer[1649]: [info] Simulation mode: off, move time: 0.0 sec, other time: 0.0 sec

This just caused my printer to crash and bend it's carriage rods, before I was able to jump to the E-stop button.

I'm the author of the Cura Duet-RRF Plugin, which is using the above mentioned auto-detection code. Meaning, potentially all users of Cura running the latest RRF 3.5.1 in SBC mode and the plugin who want to simulate a job are at risk of damage due to unplanned real printing activity instead of simulation.

What's the expected behaviour in this case?
Is this a bug in the emulated rr_* API in DSF, or something else?

edit
After some more debugging, it turns out that even using the new API is causing a simulation job to be executed as real print job!

This can also easily be triggered using DWC by right-clicking on a gcode file and selecting "Simulate File", upon which it will send the correct gcode M37 but will in fact start heating the hotend and bed and start homing!

May 26 13:54:01 voron DuetWebServer[634]: Microsoft.AspNetCore.Hosting.Diagnostics[1] Request starting HTTP/1.1 POST http://192.168.1.42/machine/code application/x-www-form-urlencoded 68
May 26 13:54:01 voron DuetWebServer[634]: Microsoft.AspNetCore.Routing.EndpointMiddleware[0] Executing endpoint 'DuetWebServer.Controllers.MachineController.DoCode (DuetWebServer)'
May 26 13:54:01 voron DuetWebServer[634]: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3] Route matched with {action = "DoCode", controller = "Machine"}. Executing controller action with signature System.Threading.Tasks.Task`1[Microsoft.AspNetCore.Mvc.IActionResult] DoCode(DuetWebServer.Singletons.ISessionStorage, Boolean) controller DuetWebServer.Controllers.MachineController (DuetWebServer).
May 26 13:54:01 voron DuetWebServer[634]: DuetWebServer.Singletons.SessionStorage[0] Session 5fbbc7e78464425b8c043dc244cf336f started a long-running request
May 26 13:54:01 voron DuetWebServer[634]: DuetWebServer.Controllers.MachineController[0] [DoCode] Executing code 'M37 P"0:/gcodes/test.gcode"'
May 26 13:54:01 voron DuetControlServer[9372]: [info] Selected file 0:/gcodes/test.gcode
May 26 13:54:01 voron DuetControlServer[9372]: [info] Starting file print

Is something wrong with my machin and setup - or was such a potentially dangerous bug not caught during testing and beta/RC releases?

droftarts

@resam one for @chrishamm

Ian

oliof

@resam I haven't tested simulation in a long time, and I will do so tomorrow.

Duet2 with SBC is a rare beast, so maybe that particular combo elicits this bug. I only have a atabdalone machine so my results may vary ...

resam

@Phaedrux not sure why you moved this to "Beta Firmware" -- v3.5.1 is marked stable, unless the Duet2-SBC variant is officially not supported any more?

Phaedrux

@resam said in [bug] 3.5.1+SBC: M37 simulation starts printing! [SBC mode]:

@Phaedrux not sure why you moved this to "Beta Firmware" -- v3.5.1 is marked stable, unless the Duet2-SBC variant is officially not supported any more?

Just collecting issues to in the current release for DC42 to investigate for the next beta.

chrishamm

@resam Thanks for reporting this and sorry for the trouble you had. Your curl call works as expected with a Duet 3 in SBC mode but something is off in RRF with a Duet 2 in SBC mode. I'm looking into it.

Edit: This is now fixed upstream.