Tool changer wait for cooldown... :(

Chriss

Hi *,

I have a tiny prodblem with my toolchanger setup, I hope somebody can help my with the setup.

I see that the new tool waits till the old tool has reached its standby temp. That is not very effective and it is not needed at all. Anybody with an idee to work around it?

My tool change g code in the slicer is:

T{next_extruder}

I hand over all of the temps via a custom gcode in the slicer:

;##################### Start g-Code



set global.tool_temp_initial={first_layer_temperature[initial_extruder]}
set global.tool_initial=[initial_tool]

set global.bed_temp_initial=[first_layer_bed_temperature]
set global.bed_temp=[bed_temperature]

set global.tool0_inital=[first_layer_temperature_0]
set global.tool1_inital=[first_layer_temperature_1]
set global.tool2_inital=[first_layer_temperature_2]
set global.tool3_inital=[first_layer_temperature_3]

set global.tool0_all=[temperature_0]
set global.tool1_all=[temperature_1]
set global.tool2_all=[temperature_2]
set global.tool3_all=[temperature_3]

set global.tool0_standby=[idle_temperature_0]
set global.tool1_standby=[idle_temperature_1]
set global.tool2_standby=[idle_temperature_2]
set global.tool3_standby=[idle_temperature_3]

M98 P"/sys/lib/start2.g"
;##################### End of Start g-Code

The start2.g does some tiny things, the most important in this case:

; Set the standby temps to all tools
M568 P0 R{global.tool0_standby}
M568 P1 R{global.tool1_standby}
M568 P2 R{global.tool2_standby}
M568 P3 R{global.tool3_standby}

tpre0.g

G91			; Relative
G1 Z5

G90			; Absolute
G1 X11 Y357 F9000
G91
G1 Y10 F6000

M98 P"0:/sys/lib/coupler-lock.g"

G91			; Relative
G1 Y-30 F6000

M593 P"none"      	; disable input shaping

tfree0.g

G91                     ; Relative
G1 Z5

G90			; Absolute
G53 G1 X11 Y298 F9000	; Go in front of the park position, step 1
G53 G1 Y337 F8000	; Go in front ot the park position, step 2
G91			; Relative
G1 Y30 F6000		; Go into park position
M98 P"0:/sys/lib/coupler-unlock.g"     ; unlock Coupler
G91			; Relative
G1 Y-15	F6000		; Move the coupler out
G90			; Absolute

M106 P10 S0		; Fan off

And the tpost0.g which I think is the problem:

; Wait for set temperatures to be reached
M116 P0

That looks like that: (grep M116 tpost*)

tpost0.g:M116 P0
tpost1.g:M116 P1
tpost2.g:M116 P2
tpost3.g:M116 P3

I had the hope that the M116 is ignoring the standby temp but it does not. And better ideas?

Cheers, Chriss

droftarts

@Chriss M116 P# should wait for just that tool to reach temperature. From https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m116-wait-for-temperature-to-be-reached

The second shows the optional 'P' parameter that is used to specify a tool number. If this parameter is present, then the system only waits for temperatures associated with that tool to arrive at their set values. This is useful during tool changes, to wait for the new tool to heat up without necessarily waiting for the old one to cool down fully.

What version of RRF are you using? Has this worked before, and if so, what RRF version? What hardware is this running?

Ian

Chriss

@droftarts My apologies Ian, I was so focused on the issue that I have forgotten to mention the hardware.

I'm not sure that it was working in the past, maybe but I can not say it for certain.
That is my Toolchanger project which I use to dump some spare time in. I think that I saw that from the beginning but there were so many issues to solve that I was able to run away from that one.
I have to admit that I was indeed a bit confused about the behavior.... I was printing today the first time with a tool change after some hardware fixes. And t0 paused right after the tool pickup, coming from t1. The standby temp on both tools was set to 100°C, I waited a while to understand what is going on. A changed the standby temp of T1 to 140 when the tool was at 143°Cish and T0 started to move/print.

I'm very sure that I used the P on M116 to avoid exactly this behavior.

Cheers, Chriss

droftarts

@Chriss Okay, thanks. I've asked for it to be tested, as I don't have a tool changer or multiple tool machine.

Ian

Chriss

@droftarts So we have misunderstood us. I have this:

tpost0.g:M116 P0
tpost1.g:M116 P1
tpost2.g:M116 P2
tpost3.g:M116 P3

So every tpost has a "M116 with Px" accordingly. I can remember that I stumbled over that when I started to write the config and the effect is present with that config.

We agree that we want to M116 in the tpost, don't we?

Cheers, Chriss

Edit: I just saw that "M116" only (without the P) has effect to the current selected too only. I'm not sure that this is correct. I can remember that I added the "P" later because I saw that "waiting for standby" in the past. But it could be that there was a firmware update since than and all of my memory is not valid anymore.

droftarts

@Chriss Maybe it should be just M116. According to this change in 3.5.1 https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x#reprapfirmware-351-stable-changes-since-346

M116 without parameters only waits for slow heaters (beds, chambers) and for the selected tool heaters of the current tool (if any) assigned to the current motion system. In previous versions, M116 waited for all heaters to reach their target temperatures

Ian

Chriss

@droftarts Good morning Ian,

I gave it a shoot but with the very same result. The active tool waits till the tool which went into standby reached the standby temp.

And that "new" (3.5.1) behavior does not seems to make much sense to me to be honest.

It would be far more logical to me to have:
M116 = wait for all
M116 P0,1,2 = wait for the list of tools
M116 P-1 = wait for all
And maybe a other switch like: "X0" = do not wait for standby temp at all. There are maybe some very rare edge cases where you want to wait till the temp went down.

Cherrs, Chriss

Edit: I was unable to resist and had a quick look into the current code (well at 3.5-dev), I have to admit that I do not fully understand how that value of P is handed over:

if (gb.Seen('P'))
        {
         // Wait for the heaters associated with the specified tool to be ready
          if (!ToolHeatersAtSetTemperatures(Tool::GetLockedTool(gb.GetIValue()).Ptr(), true, lerance, gb.IsFileChannel()))
                      {
              return false;
                        }
                          seen = true;
                 }

I do think to use "H" in the meantime, that looks a bit more promising:

  if (gb.Seen('H'))
              {
                // Wait for specified heater(s) to be ready
                uint32_t heaters[MaxHeaters];
                size_t heaterCount = MaxHeaters;
                gb.GetUnsignedArray(heaters, heaterCount, false);
                                        
                for (size_t i = 0; i < heaterCount; i++)
                                                                                        {
        if (!reprap.GetHeat().HeaterAtSetTemperature(heaters[i], true, tolerance, gb.
                                        IsFileChannel()))
                       {
             return false;
   }
         }
                seen = true;
           }

droftarts

@Chriss Thanks for checking the code! The code in 3.6-dev looks the same: https://github.com/Duet3D/RepRapFirmware/blob/5c06d3b1e200de8c7cc2b70f00d9234a28f49fea/src/GCodes/GCodes2.cpp#L1940

@dc42 will need to have a look at this.

Ian

Chriss

@droftarts Hi Ian,
I had the hope to see how the value of P is handed over. The "GetLockedTool" seems to me like it is pointing to the attached tool. Anyway, just guessing. I guess that David can point it out here.

I have the feeling that we end her in a feature request and I will work around that with the H parameter. It seems to me that H will do what I need too.

Cheers, Chriss

droftarts

@Chriss @dc42 tested M116 last night, and found it to be working correctly from his tests. These were very simplified, please could you try the same?

Test 1 (tested with 3.6.0-beta.4 in standalone mode):

T2 heater is on an expansion board, T1 heater on the main board. But it shouldn't make a difference where the heaters are because the main board does the waiting.
File tpost1.g has M116 P1 in it
Temperatures set manually in DWC. T2 to 195/140, T1 to 100/100.
T2 selected manually, and wait for it to heat up
Run this macro:
```
T1
G1 X-50 Y-50
```
Macro selects T1 which has active/standby temps 100 and 100
Followed by a G1 move, which happens immediately, with T1 at temperature, and T2 still cooling down from 195.

Test 2

temperatures manually in DWC. T2 to 192/140, T1 to 110/100, in case having to heat T1 makes a difference
Worked correctly. After selecting T1 it waited for it to heat from 100 to 110C, then moved and the machine went idle. T2 was still cooling down through 180C.

Notes fro dc42

I've looked at the code several times and I really don't think there is a problem with it. Are we certain that the user doesn't have more than one M116 command for each tool? Or could it be that he has a heater that is shared between tools, and that is complicating the issue? (I said no, I don't think this is the case)
Has he tried running M122 while he says the tool is waiting to cool down? It should report under GCodes which commands it is waiting on. (Please try this)
There is no difference in how tool change is handled in SBC mode, it's all handled by RRF, so this shouldn't be different between SBC and standalone.
Please test with the new tool active and standby temps set the same, like dc42 did. If that works OK, try making them just slightly different.
M116 P# is working correctly for me.

And perhaps most importantly ... !

Maybe his slicer is inserting temperature commands for the old tool or its heater? (Please check the gcode you're running to see if this is the case)

Ian

mikeabuilder

I had some temperature challenges with my tool changer and found I had some temperature settings in my filament config.g file which I was calling via M703 and those were messing me up. But I don't see any M703 in your tpost.g.