Duet not waiting for hot end to come to temperature
-
@sinnedwrong You need to use G10 to set the temperature before using M116.
https://duet3d.dozuki.com/Wiki/Gcode#Section_G10_Tool_Offset_and_Temperature_Setting
-
Stephen6309
Thanks for the input however this is the beginning of the gcode produced by SlicR
; generated by Slic3r 1.2.9 on 2020-12-07 at 14:50:20; external perimeters extrusion width = 0.50mm
; perimeters extrusion width = 0.50mm
; infill extrusion width = 0.50mm
; solid infill extrusion width = 0.50mm
; top infill extrusion width = 0.50mmM107
M190 S57 ; set bed temperature
G28 ; home all axes
M83;
G10 P0 S195 R160 ; Set tool 0 operating and standby temperatures
T0As you can see G10 is triggered before T0, which is if my reading is correct should then call tpost0.g, which is where the M116 command is.
So I repeat my question, what am I doing wrong?
Dennis
-
@sinnedwrong I might be wrong, but I'm not sure if the tool change files are called on T0 if tool 0 is already selected. Do you have a T0 line in your config by any chance? Failing that, I think T-1 deselects all tools. You could put that in your start script?
-
@sinnedwrong I believe, tpost0.g is only called when you are using a different tool number.
Add a M116 to the start up code.
-
M109 should still work just fine.
Add T0 to the end of your config.g to select the first tool at startup so that the G10 can take effect. Add M116 as well so that it waits.
As for the ancient firmware, the problem with support is that so much has changed and been fixed since then that it's difficult to know if the problems encountered are due to differences in configuration behaviour between then and now, or bugs that have since been fixed.
On a continuously evolving platform like the Duet I think it's best to try and keep with the pack. Especially when modern firmware is made available for even very old boards. I think 1.09 is probably the oldest firmware I've ever seen someone post about.
Even your Maestro at 2.02RC3 should be updated to at least 2.05.1 to benefit from bug fixes.
on the grounds if it ain't broke don't fix it I'm not changing.
That's the thing though, wouldn't you consider known bugs being fixed as broke?
-
@sinnedwrong said in Duet not waiting for hot end to come to temperature:
Stephen6309
Thanks for the input however this is the beginning of the gcode produced by SlicR
; generated by Slic3r 1.2.9 on 2020-12-07 at 14:50:20; external perimeters extrusion width = 0.50mm
; perimeters extrusion width = 0.50mm
; infill extrusion width = 0.50mm
; solid infill extrusion width = 0.50mm
; top infill extrusion width = 0.50mmM107
M190 S57 ; set bed temperature
G28 ; home all axes
M83;
G10 P0 S195 R160 ; Set tool 0 operating and standby temperatures
T0As you can see G10 is triggered before T0, which is if my reading is correct should then call tpost0.g, which is where the M116 command is.
So I repeat my question, what am I doing wrong?
Dennis
My guess is that you have a T0 command at the end of config.g so that the T0 command in your start Gcode doesn't run the tool change files. Try adding M116 to your start Gcode, after the T0 command.
-
Thank you all for replying and especially for making me reread the Wiki carefully. The phrase If Tn is used to select tool n but that tool is already active, the command does nothing. Otherwise, the sequence followed is... to me implies that it always calls tpost0.g but now I know!
To answer specific questions no there isn't a T0 in config.g . As originally delivered by RepRapPro the T0 is put in by the custom Gcode in SlicR from the start GCODE section so I will add an M116 after that. Its interesting that the reprappro supplied SlicR start Gcode for the dual nozzle option doesn't include a T0 and T1. I can only presume that in version 1.09 there was an automatic wait which has gone in the intervening versions. I have looked at the versions in https://github.com/Duet3D/RepRapFirmware/blob/dev/WHATS_NEW.md but that only goes back to 1.12 and I can't see any mention of the change.
There are 2 reasons why I'm building a second Ormerod, first after 20 years as Clinical Director of a large NHS Pathology service I don't tend to make major changes to software without a fallback machine. My plan is to upgrade my original machine once I have a working spare. I also plan to play with dual nozzle so an understanding of tool changes etc. becomes relevant. The reason I'm on 2.02 RC3 was that was the current firmware when my Maestro was delivered. I got sidetracked into AI resulting in me teaching myself Python, Tensorflow and Linux.
My current plan is to is to put a M116 in the custom Gcode setting of Slicr after the T0 and when I move on to a second nozzle to also put in a T1 and M116. Looking at the gcode source of a 2 colour slicing that presumably will trigger the relevant tpostN.g macro each time as that will be a tool change.
Its been interesting and thanks for your input.
Dennis
-
@sinnedwrong, I don't know if you are interested, but my dual nozzle Ormerod is up for sale. https://reprap.org/forum/read.php?340,879035
-
DC, Thanks for the kind offer but that would remove all the fun of getting mine to work, besides you are running out of room? I live in suburban West London where the spare machine lives on top of a cupboard.
With further investigation accessing https://reprap.org/wiki/G-code listed from the mirror of RepRapPro's original instructions linked from RapRap Ltd. site under T is see the following
"Select tool (or in older implementations extruder) number 1 to build with.
The sequence followed is:
Set the current tool to its standby temperatures specified by G10 (see above),
Set the new tool to its operating temperatures specified by G10 and wait for all temperatures to stabilise,
Apply any X, Y, Z offset for the new tool specified by G10,
Use the new tool."If I get bored I will investigate whether it does this by always calling tpostN.g and if that got lost somewhere in subsequent versions.
Is there a description anywhere of the differences between versions 3.. , 2.. and 1.. apart from the different hardware requirements which as far as I can see relate to the ARM processor?
Dennis
-
@sinnedwrong said in Duet not waiting for hot end to come to temperature:
With further investigation accessing https://reprap.org/wiki/G-code
You may want to check the Duet Gcode wiki as well.
https://duet3d.dozuki.com/Wiki/Gcode@sinnedwrong said in Duet not waiting for hot end to come to temperature:
Is there a description anywhere of the differences between versions 3.. , 2.. and 1..
The release notes would probably give a good run down.
The main difference between 1.x and 2.x is that RRF2 is based on a real time kernel. And the main difference between 2.x and 3.x is the generalization of the hardware description for pins, conditional gcode and eventually variables, and allowing for the Duet3 hardware.RRF3 will run on all Duet 2 boards and up.
For older Duets the most recent firmware is 1.26.1 based on 2.05.1.
https://github.com/Duet3D/RepRapFirmware/releases/tag/2.05.1
-
@sinnedwrong said in Duet not waiting for hot end to come to temperature:
If I get bored I will investigate whether it does this by always calling tpostN.g and if that got lost somewhere in subsequent versions.
Very old versions of RRF always run the tool change files even if the active tool number is not changing. Newer versions only run them if the tool number is changing. If you want to run them always, use e.g. T-1 T0 instead of just T0.
-
Hi, Thanks all for the input. DCs answer has stopped me putting an M117 "Random message" into tpost0.g to see if it was run. I think this thread has just about run its course now. I'm presuming having read the wiki regarding T gcodes that there is a typo in DC42 last post and that it should read T-1 P0 followed by T0.
Thanks again for the input, will be starting a new post re upgrading firmware after more reading.
Dennis
-
T-1 P0 then T0 is OK if you don't want to run tfree.g for the outgoing tool (if any). T-1 then T0 mimics the behaviour of old versions of RRF.
