@pzmurphy in the crash could VIN on the heater on the print head be fed into the tem sensor or other IO on the Duex5? How sudden was the crash and how fast was the axes moving when it happened?

Ah, bother, there is an error in one of my formulae and akismet won't let me correct it. The third bullet point should have "This expands to..." with 2 * revs * motionBackEmfPerRevSec * voltageDrop in the middle of the equation (where revs is not squared).

@TLAS like a tool distribution board, but for the motors? yes thats planned but not scheduled.

re, daisy chaining not directly on the motors.

Hi Tony, I have tried another probe with the same result (they are only cheap). If I insert a dress makers pin in beside the zprobe signal pin and short the diode, the voltage at the pin toggles between +0.7 volts and +24 volts with respect to Ground. With the diode in circuit, the signal voltage toggles between approx +1 and +2 volts. It never goes to zero. However, if I unplug the probe at the zprobe socket and jumper the signal pin to Ground (the adjacent pin), I get the same results running command M119 i.e. 'z probe at min stop'.
Late Extra: I just tried it after re-plugging the z probe plug on the Duet board and presto, it's working properly! I've wriggled all the connectors but can't make it fail now. Thanks for walking me through this mysterious problem. I can now proceed to the stepper motors. Cheers, Ralph

@e4d another possibility is that the large number of http clients is causing RRF to run out of output buffers. On the 6HC we have enough spare RAM to increase the number of buffers.

Thanks! @yasas has started a new thread about collecting some calibration data:

https://forum.duet3d.com/topic/31907/collecting-timelapses-need-your-help

We would appreciate input from people to assist with his Masters research project.

@Sophiechka thanks for confirming the issue. will marked this as resolved.

When and where did you purchase?
Can you send M122 before and after mounting with M21 and copy paste the results here?

@droftarts I read it but I didn't completely understand it. I knew after looking at the data that it was reading wrong. Thank you for the help.

@T3P3Tony Still wont let me edit it, but its not an issue for this thread. Thanks for the upvotes though!

@osli It only detects and alerts you when printing and not when you send G28 from console , I don't know why. I'm using a motor that I found in my trash.😑 It's probably a little bigger than yours

@900turbo as @jay_s_uk says, power it directly from the PSU. It can run on a different PSU from the one powering the 6HC, and at a different voltage if necessary. If you do this, there should be a common ground for both PSUs.

Don’t use OUT0; on the 6HC it is turned off by default at startup, and you need the toolboard to be powered at startup to make contact with the mainboard.

Ian

The easiest way is to upload the full zip file to the system tab in DWC.

https://github.com/Duet3D/RepRapFirmware/releases/download/3.4.5/Duet2and3Firmware-3.4.5.zip

If that still doesn't do it, you can to a more manual process here:

https://docs.duet3d.com/en/User_manual/RepRapFirmware/Updating_firmware

@T3P3Tony Yeah ofc, sorry I should have done that myself once we discovered it wasn't an isolated thing 🤦‍♂️

@Tricep-terry said in Discrepancy between speed limit between duet 2 and duet 3 mini:

Also after start up, sending a G91 G1 X10000 command does not move the axis at the max speed set in the config file, but sending for example G91 G1 X10000 F500000 will perform just fine (F500000) set as the max speed

RepRapFirmware doesn't use the max speed set by M203 for moves immediately after config.g has run at start up; it uses a default speed. I think the default speed is 3000mm/min / 50mm/s. The speed for the Machine movement buttons in DWC is specified on Settings > Machine-Specific.

Ian

@slabstations try a replacement SD card, sounds like its not reading the SD card on startup.

@e4d I can see that the M42 command might get held up if you are doing a G2 or G3 move, or a long linear move and you have segmentation enabled. I think I need to change the logic so that when M42 is executed by the daemon, and the daemon hasn't commanded any movement since it last waited for movement to stop, the command is executed immediately without any attempt to sync it to the movement commands already queued.

Meanwhile, you may be able to get this working by putting one of the parameters in { } for example M41 P{13} S1. This will make the parser think that there is an expression to be evaluated, and in current firmware it will not attempt to sync the command with motion.

@RandyL00123 see the reply here:
https://forum.duet3d.com/topic/31798/monitor-extruder-stepper-voltage-to-detect-filament-errors?_=1679398375558