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....

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

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

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

@bearer Thanks.. that did it. I'm a bit confused, it my first reflex was the mode 8 but it did not work. Well, I played a bit with the config in the meantime, that ańd your confirmation did the trick.
At least one success today.

Cheers, Chriss

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

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

Cheers....

@jay_s_uk

That is a bit strange, I have found this in one of my older configs:

;; Bed Corner temp sensor (2=Orange, 3=Brown, 4=Green, 5=Yellow, 6=Purple 7=Black, )
; Configure Bed corner temp sensor as thermistor on pin temp2
M308 S5 P"0.temp1" Y"thermistor" A"Bed-Corner" T100000 B4138

So at least the colours of the sensors have/had that feature. I can remember that I created the list of colours in the past.

I guess that we all agree that we want to change the colours here, don't we?

"BtnCmd"?

Cheers, Chriss

Hi *,

I can remember that there is/was a possibility to specify the tool colour in the DWC somehow in the config but I can not find it anymore. Could somebody give me a hint please?
The docu from M563 or M308 did not help me.

Cheers, Chriss

@dc42
Let me point out one more thing here: The printer I see this problem does not have this problem since some weeks anymore. But all of the print which the printer performed are below 100mm in Z. I'm not sure whether that is time ore high related. I just wanted to let you know my observation.

@chrishamm said in duetpluginservice(-root) not starting....:

@Chriss said in duetpluginservice(-root) not starting....:

Is there a am64 repo for that? I would like to play with that in a VM.

No. You could build it from the sources for different architectures but since it requires an SPI link to work I guess that's rather pointless.

OK, so no VM than, I will grep a other PI than for testing that.

@Chriss said in duetpluginservice(-root) not starting....:

I'm confused that I'm the only person reporting that, I used the most recent raspberry image from the duet homepage and I did not altered anything.

If anything went wrong during start-up, the journal should tell you. No idea why they were empty on your machine, though. They should be enabled by default. What variant are you using, 32 or 64-bit, with or without GUI?

64 and without GUI.

Cheers, Chriss

@chrishamm Strange, most strange.... Is there a am64 repo for that? I would like to play with that in a VM.

Am I right when I assume that we need to have the process running twice, one as uid 0 and one as the dsf? I will create two supervisord script to manage the processes till I found the reason for that behavior via the systemd.

I'm confused that I'm the only person reporting that, I used the most recent raspberry image from the duet homepage and I did not altered anything.

Needless to say that I want my init system back.

Cheers, Chriss

Nobody with an idea?

@droftarts Yes, yopu are right, the limit page says that. But I can remember from the top of my head that the limits are very often mentioned command sections too. Maybe the lack of consistency confused me here. I will keep an eye on it and let you know if I come across again.

Cheers, Chriss

Hi *,

I play with my "Duet 3 MB6HC MB6HC 3.5.3, Duet 3 Expansion EXP3HC EXP3HC 3.5.3 " a bit and I found that in the docu about M308:

This code replaces M305 in RepRapFirmware 3. In earlier versions of RepRapFirmware, sensors only existed in combination with heaters, which necessitated the concept of a "virtual heater" to represent a sensor with no associated heater (e.g. MCU temperature sensor). RepRapFirmware 3 allows sensors to be defined independently of heaters, up to a max of 32 sensors. The association between heaters and sensors is defined using M950.

How is it possible to use "M308 S55" when the docu speaks about "max 32 sensors?

M308 S56 P"mcu-temp" Y"mcu-temp" A"mcu"
Error: M308: Sensor number out of range
ok
M308 S56 P"mcu-temp" Y"mcu-temp" A"mcu"
ok

Do I oversee something? Or the the docu not correct? Or should I read it as "max 32 sensors per heater" and the "total max sensors" is not documented in the section?
Maybe I do simply do not get it...

Edit: And I just saw that I can not find the max fans in M950 too. :? I think that it would be nice to have the allowed range at the "Parameters" section .

Cheers, Chriss

@chrishamm Oh, they are not disabled as you see, they are "inactive". I enabled them manually (just in case) and rebooted a couple of times. It seems that they do nothing at all.

It is very strange to be honest, I see no reason why they shout not start even if I start them with a "systemctl start ....". I have never ever seen a daemon on a UN*X like system with never come back after you started it. (Well, at least not if it is not totally malfunction)
And I would expect at least any kind of message on stdout or in the system log, but there is simply nothing.
I did not thing to the image, I downloaded the latest version, dd it to the SD card, booted the pi and did a "apt update ; apt upgrade -y", that's it. I came across the issue when I tried to start the "DuetPi Management Plugin".

root@blimy:~/SD-Card/sys# ls -al /etc/systemd/system/multi-user.target.wants/duet*
lrwxrwxrwx 1 root root 50 Sep 19 17:17 /etc/systemd/system/multi-user.target.wants/duetpluginservice-root.service -> /lib/systemd/system/duetpluginservice-root.service
lrwxrwxrwx 1 root root 45 Oct 15 15:38 /etc/systemd/system/multi-user.target.wants/duetpluginservice.service -> /lib/systemd/system/duetpluginservice.service
lrwxrwxrwx 1 root root 41 Sep 19 17:17 /etc/systemd/system/multi-user.target.wants/duetwebserver.service -> /lib/systemd/system/duetwebserver.service
root@blimy:~/SD-Card/sys#

Edit: Changing the shell of the user dfs to bash is the only thing I have changed in the meantime. I needed to do that to su to the user to see how the bin behaves when I start it manually to see if there is any error report.

Cheers, Chriss