Thanks a lot for your answers.

I found a very good solution from a nice Company, they have a nice system where you can by the pliers and add inserts for various connectors.
https://www.rennsteig.com/en/products/crimping/200-crimp-system-tool-pew-12

I talked a bit with the support and they told me that there insert "624 1324 3 0" should work with the WE connectors.

I will send them some connectors and some wires for testing now. Let's see what they say after there tests.

That may sounds a bit over the top but I love good tools and I'm sure that it makes sense to support good engineering. I think that this is the case with duet, isn't it?

Cheers, Chriss

@jay_s_uk It seems like I instantly felt in love with BtnCmd.

Cheers....

I use Cura and I hate it... the very last version needs a restart after every print and it is crashing all the time. (on my linux workstation)
But the tree support is a gamechanger for me.

I will test PrusaSlicer 2.3.0-alpha2 after I saw that here in the thread.

This is how a real slicer should look like:

+1 This would be nice. And I ask for a Endstop status too!

@oliof said in Error messages improvement?:

@Chriss you aren't the first to ask for this, see https://forum.duet3d.com/post/325796

Not a surprise to be honest.... It is more a surprise that it took so long that people ask for that feature....

Hi * and happy x-mas,

I can remember that we had the discussion about the colours in the DWC and the temp chart, I remember from the top of my head that this colours are not configurable, aren't they?

I do not feel very satisfied with some colours here:

Brown seams a bit low in contrast, the difference between Tool1 and tool3 is hard to tell. And the black on that nice gray looks very ruff to me.

It would be very, very nice if we could make that configurable or if some colours would not be used, specially in some combinations liek this red and orange.

Cheers, Chriss

Yes, we can close the topic now..... It was my bad! The tool 0 was selected for homez and not deselected anymore. I changed that and it is working as expected now.

Thanks for your support guys!

Cheers, Chriss

https://duet3d.dozuki.com/Wiki/Duet_3_Mainboard_6HC_Wiring_Diagram

I rebuild the toolhead including the extruder and it seems to me like the problem is gone now. I will do some more test prints but I think that we can close the problem now.

Cheers, Chriss

@Argo Argo is back in town...

@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 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;
           }

@Aurimas When was the last time you replaced a USB-C connector on a pcb? I guess not once, you would not call it super easy to replace if you did it.

Have you ever compared a USB-C connector with a XT30 2x2? They are far bigger. And have you ever seen a plug where you can solder the wires in? Or crimp them? Many users use cables which are certified for drag chains, one of the USB cables I found are.

Do do you plan to consume 10A over a USB connector?
How to you build cables with custom length?

And almost every USB-C connector to solder on a PCB has a higher price tag than a XT30 2x2 connector. Every XT30 2x2 plug has a lower price than a USB-C cable. What are you talking about?

And how do you explain the weakness at the soldering point when you solder drag chain compatible wires at the cable coming out of the USB-Connector?

Cheers, 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 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

@T3P3Tony I akes a while ago for a toolboard with more than one stepper connector too. That would help a lot when you build things like Enraged Rabbit or if you want to power a gantry with a can board.

To be honest: I would love to see more smaller and specialized tool boards.
Why not having a toolbaord which is specialized for a chamber heater? Just some outputs for SSRs and some temp sensors plus a servo?
Why not a board with 2 or 4 stepper drivers and 4-6 I/Os for endstops? (For gantries in a corexy)

Or an toolboard just to control RGB Leds. And why not one like a daughter board which you can be stacked on the toolboard for the head?

And what is about a can multiplexer board? It would be nice to have more than 1 can bus in the system to make it more flexible. The stup setup is not ideal, you hit the 1m limit very easy.

I think that it is easy to come to more idea for boards which are dedicated to a very special usecase.

Cheers, Chriss

@jay_s_uk The XT30 2+x are nice, but that is the idea to get CAN out of the board than? A other connector? Solder pats?

@Aurimas
No no USB is a horrible choice. The connectors are far to big and have my downsides for our usecase. And you need to use other wires anyway, the USB cables do not last long in chains.
Everything is better than this USB connectors.

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

I see, there are plenty of other good ideas. I like the ides with the stepper endstops from the pic @oliof posted.

Yes, @T3P3Tony, you have the biggest so far.