The different B values where the key. I tried the probe on temp1 and it worked. The hot end tool board was 23,6°C which is now controllable. I checked the pin connectors and plugged it into Temp0 and after booting it up it works their as well. B values affect the reported temperature.

@droftarts Thanks. For now , it looks solved. I did a format with the SD_Card format tool. Checked: only one partition, put the files back and now it starts up again and find it's configfile. I will do the next days intensif testing with the stop and emergency stop and see if the problem still exists. But for now it looks the double partition was the culprit.

@dc42 Really! You were right. I checked my old config.g backup.
The current value of the rod length was 350.55,H380,00 but the original value in the backup was 340.55. H384,56
After the test print, the size of the circle is OK.
I don't understand why this value changed.
But the problem seems to be solved. Thank you

@MintyTrebor
WORKS GOOD!
Thanks for your help.

@torstha if you track the OK responses from each command then you can use the M400 command to wait for all movement to stop. You won't get an OK response from the M400 command until motion has stopped.

Alternatively, use the M409 command to read state.status in a loop and wait for it to become "idle".

@wayneosdias the 4Hz sampling rate only applies to the rate at which data from sensors (configured using M307) is collected and returned from the expansion board to the main board; and to the collection of data from sensors connected to the main board into the object model. The actual sampling in the ADC is much faster on both main boards and expansion boards. Changes to digital inputs are also signalled from expansion boards to the main board very quickly. Likewise when an analog input configures as general purpose input crosses the threshold value.

So it's entirely possible to do the processing you want on your custom expansion board and pass it back to the main board over CAN.

OTOH if you need the data to be passed directly into the Pi (or other computer running OpenPnP) then that would be a reason for bypassing the expansion board processor and CAN and using a separate cable back to the Pi.

@adventureman See the guides on the wiki, on the left side. Work through them to understand how to change the configuration with config.g. Specifically for changing the motor direction, see https://docs.duet3d.com/en/How_to_guides/Commissioning#h-10-check-stepper-motors and see the sub section 'Reversing a stepper motor". But really you want to start at the beginning of this page, and check through everything.

Ian

@Timothee-Leblond There's no one quick way to set it, unfortunately, because it depends on the motors, current, speed and Duet board you're using, so you have to tune it. See this guide https://docs.duet3d.com/en/User_manual/Connecting_hardware/Sensors_stall_detection

Ian

@CarlosR What Duet board and firmware version are you running? Send M122 and post the response. How is it currently configured?

I haven't set up MQTT myself, so I don't have any experience. Can you look at the documentation here, and see how far that gets you:
https://docs.duet3d.com/User_manual/Reference/Gcodes#m5864-configure-mqtt-client
https://github.com/Duet3D/MQTT-WPA2-Enterprise-Demo

Have a look at some of the forum threads on MQTT too: https://forum.duet3d.com/search?term=Mqtt&in=titles

Ian

@Electriceye try clearing your browser cache

@drivetrainsystems if you are using a Single Board Computer attached to the Duet using SPI then you can read the object model from Duet Software Framework, either in a plugin or via the REST API.

@Tim_fransman the M584 order should match the order of the pivot points in M671.
So make sure probe point 1 is driver 7 and so on. You probably have the orders wrong

@qlqlo 0.26A at 24V is only about 6W which is nowhere near enough for a filament hot end let alone a pellet extruder. Are you certain that the heater is intended for 24V? Perhaps it is intended for AC mains voltage, in which case you will need a SSR to drive it from the Duet. Check the heater specification with the manufacturer of the pellet extruder.

@Esteban yes that does seem odd. When you run M122 do drivers 5 and 6 show up in the Move section, or are they flagged as not present?

In theory you could forcefully move the motors by hand so fast as to create an over-voltage condition that could blow multiple drivers both on the main board and the 2-driver daughterboard; but I doubt that you would be able to move them that fast.

@Garth_42 when you try to calibrate and it gives the message that motion was less than expected, does the motor turn forwards and back slightly, and does the message give you an estimate of the CPR? If so, is it close to the actual CPR of the encoder?

@drivetrainsystems yes you need to use a single quote to refer to a lowercase letter axis, in GCode commands when referring to that axis and in the names of homing files. I suspect it is either your zip program or perhaps the unzip in DWC (used when you upload a zip file) that doesn't handle the quote in the name of your homing file.

@aceycv8 I'd suggest you post a video showing a print just from just before the pause to just after the resume so folks can see what is happening.

@Alva the reason that the bit assignments are different between the datasheet and the status reported by RRF is that different Trinamic drivers use different status bit assignments. RRF uses the same bit assignments for all drivers so that you can interpret them without knowing what driver type is used. Also it has a few status bits that don't correspond to any Trinamic status bits, for example when using closed loop drivers.

The bit assignments RRF uses are mostly the same as for Trinamic TMC2209 drivers.

@qlqlo on the top board you have the PT100 sensor connected to the RTD2 terminals. So either move it to the RTD1 terminals or change the config to use spi.cs3 instead of spi.cs2.