M109 command does not run tool change macro's

St Taw

Firmware details.

Firmware Name: RepRapFirmware for Duet 2 WiFi/Ethernet
Firmware Electronics: Duet WiFi 1.02 or later + DueX5
Firmware Version: 2.02(RTOS) (2018-12-24b1)
WiFi Server Version: 1.22
Web Interface Version: 1.22.6

dc42

On my list to investigate.

dc42

I confirm there is a problem, at least in the case where no tool is selected initially.

NicoLab28

take a look to this thread

https://forum.duet3d.com/topic/9405/first-t0-in-gcode-does-not-work

dc42

@nicolab28 said in M109 command does not run tool change macro's:

take a look to this thread

https://forum.duet3d.com/topic/9405/first-t0-in-gcode-does-not-work

That looks like the same issue. There is a M109 S225 T0 command in the GCode file, before the T0 command.

St Taw

Note sure if associated or a different issue but if I Pause and then Cancel a print from Panel Due the tool becomes deselected but no macro run. Hence the tool remains attached to the head.

clegg78

@dc42 said in M109 command does not run tool change macro's:

f all axes are flagged as having been homed, then the tfree file for the current tool should be run (if a tool is already selected), followed by the tpre and tpost files for tool 3.

Ha, happy I found this, I was just finding this same issue when troubleshooting a related odd tool selection behavior of M109.

Simplify runs the HE heat up sequence before the custom scripts can be run, so I see this :

"M104 S255 T1
M109 S255 T1"

And if no tool has been called yet, M109 seems to set Tool 1 (from no tool being selected - this is a problem in its own right, as I cant run the tool Tfree and tPost that I was planning on at the start of a print to ensure everything is where it should be. This is before the axis have been homed.

But I noticed that even if I manually tweaked the script so that the weird M109 tool selection behavior happened after G28, I wouldn't get the scripts to fire.

Any reason M109 picks a Tool when M104 does not? In S3D's case, it means I cant actually run any of the tool change scripts before printing starts without throwing in a tool switch back and forth which seems kind of clumsy.

dc42

The reason M109 does a tool change is that most slicers assume that a tool is already selected at the start of a print. There used to be many users reporting prints failing, which was because no tool was ever selected. As M109 waits for heating to complete, it's unlikely that you will use it unless you are about to use that tool. Also a slicer that is aware that it is generating code for RepRapFirmware should be using G10 (or possibly M104) and then M116, not M109. So we take the view that any GCode that includes M109 probably doesn't select a tool before it prints, which is why we make tool selection implicit when the firmware sees M109.

M104 is used by some slicers to set the temperatures of standby tools, so I didn't consider it appropriate to make it select a tool.

St Taw

Thanks for reply.

Does anyone use Slic3r PE for an E3D like tool changer that works without having to edit the gcode file to overcome this issue of no tool being got?
The Firmware setting in Slic3r I have set to RepRap/Sprinter. Would one of the other 'Flavors' be better to generate G10 commands?

Any E3D toolchange users out there that are using Slic3r? If so how do you get the tool to be physically picked up on print run if currently physically no tool selected and firmware starts with no tool selected.

Phaedrux

You may have to use the slicer post processing capabilities to convert the M109 to G10.

dc42

@st-taw said in M109 command does not run tool change macro's:

Thanks for reply.

Does anyone use Slic3r PE for an E3D like tool changer that works without having to edit the gcode file to overcome this issue of no tool being got?
The Firmware setting in Slic3r I have set to RepRap/Sprinter. Would one of the other 'Flavors' be better to generate G10 commands?

Any E3D toolchange users out there that are using Slic3r? If so how do you get the tool to be physically picked up on print run if currently physically no tool selected and firmware starts with no tool selected.

Have you tried putting a T0 command in the start.g file?

St Taw

I tried putting a T0 command in start.g

It appears to run the tfree0.g macro then the T3 tpre3.g and tpost3.g.

The head does go to put T0 back in place at the start of printing even though it does not have the tool in place is a small compromise to get it working.

On a similar note I have
M0 in the Cancel.g which also deselects the tool without running the tfree?.g macro. I have resolved this by putting a T-1 before it.

Is there any documentation which describes which commands select and deselect tools without running there respective free, pre and post macro's?

dc42

@st-taw said in M109 command does not run tool change macro's:

On a similar note I have
M0 in the Cancel.g which also deselects the tool without running the tfree?.g macro. I have resolved this by putting a T-1 before it.

I will investigate this. Note, you can define what M0 does by creating a stop.g file.

Is there any documentation which describes which commands select and deselect tools without running there respective free, pre and post macro's?

The intention is that the tool change macros are always run, unless one of the following is true:

One or more axes are flagged as not having been homed;
You use the T command with a P parameter to specify that you do not want some of the tool change files to be run.

In any other situation, not running tool change files on a tool change is a bug.