M37 Simulate print leaves Tool 0 active when done

shirnschall

When using the Simulate Print feature the T command reports T0 as active after the simulation is finished.

My setup/configuration:
I have included a check if a tool is active in the bed.g file as the printer can only home z if no tool is active. When a print is done I call stop.g using M0 from the ending script in the slicer. In stop.g I run T-1 to deselect all tools. This works fine with real prints. After a real print is done the T command will report "no tool is selected" as intended.

At the moment I run T-1 P0 manually after a simulation.

Does the M37 command run a gcode file once it is done (I could not find this in the wiki) or is there some other way to prevent this behavior?

droftarts

@shirnschall what board and firmware version? Standalone or SBC?

If running a simulation in standalone, M0 should quit the SD card file. I’m not sure if the commands in stop.g are run; possibly not.

However, I found a minor bug in DSF a couple of days ago that might cause the issue you are seeing, if you’re running in SBC mode. I was running a simulation on a board with nothing connected. The simulation ran okay, but at the end it generated an "Error: Temperature reading fault on heater 1: sensor open circuit". I tracked it down to the following at the end of the Gcode:
M0
M104 S0
Cura put this in at the end of the file. The M0 causes the simulation to stop, but DSF does not quit the file, and runs any further Gcode ‘live’, causing the M104 S0 to be run. This puts the heater (which is not connected) into Standby, but then generates a fault as no thermistor is connected. If you have something similar, it will run after anything in M0 runs.

I asked @chrishamm to have a look at this issue.

Ian

shirnschall

@droftarts I am using a Duet2 with Duex5 without a SBC (Single board computer?)

Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.1.1 (2020-05-19b2)
Duet WiFi Server Version: 1.23

For me, M0 is the very last command in the gcode files.

If this is a firmware issue and not a configuration mistake on my part I should probably upgrade to rrf 3.2.2 before doing more testing.

droftarts

@shirnschall is there a tool active at the start of simulation? I can’t think of any reason why one would be activated by simulation. I’d have to check with @dc42 but maybe stop.g is not run, or is run as part of the simulation, so had no effect on an already active tool.

I’m not sure updating firmware will make much difference, but going from 3.1.1 to 3.2.2 should be straightforward. Check the upgrade notes, though.

Ian

shirnschall

@droftarts No, normally there is no tool active when I start a simulation.

After simulation, the tool is only reported as active using the T command.
In the webui the tool is "off" and it is not actually selected by the printer hardware.

I think the issue is in
/src/GCodes/GCodes3.cpp:

// Handle M37 to simulate a whole file
GCodeResult GCodes::SimulateFile(GCodeBuffer& gb, const StringRef &reply, const StringRef& file, bool updateFile)

and
/src/GCodes/Gcodes.cpp:

// Restore positions etc. when exiting simulation mode
void GCodes::EndSimulation(GCodeBuffer *gb)

here restore points for the current position as well as the axesHomed status are created and later restored.
But the curretnTool status is not.

I have no eclipse installed to build/confirm this however.

droftarts

@shirnschall thanks, I’ll ask @dc42 to look at it.

Ian

dc42

@shirnschall, I confirm this is a bug.

dc42

This is now fixed in the RRF 3.3 source code.

shirnschall

@dc42 Thank you