Quick update on this topic: I was able to modify the height following code to control the speed of any axis based on analog inputs. I was able to use it to print with our six-axis robot and initial results seem promising.

If ever this might be useful to someone, the code is here: https://github.com/soccerpaul/RepRapFirmware/tree/3.3-dev-analog_extrusion. I've currently just replaced the height-following files with mine instead, but it would be pretty easy to modify them to make them compatible with the main reprap firmware branch. I may try to do this in the coming months.

One last question: I was never able to use the height following code at more than 50Hz, despite the code indicating it should work up to 200Hz. For standard height following, motion becomes very erratic beyond 50Hz and the z-axis won't hold its position correctly. Using my modified code, motion becomes extremely jerky beyond 50Hz. Is there something that somehow limits the frequency of the aux move queue?

@fcwilt That's what I was thinking as well, but I was hoping I had missed a simpler way of doing things. Thanks for your help.

After thinking about this a bit more, it seems like the only existing solution to this issue is cutting open the USB cable and removing the 5V input to the Duet; this would ensure the board turns off when I turn the printer off.

Hi,

For a while now I've noticed that the Z axis on my printer occasionally moves in the wrong direction on startup, which has led to the printhead smashing into the bed a few times. I'm running a Duet MB6HC with a 1XD board controlling an external stepper. The mainboard controls the X and Y axes while the 1XD controls the Z axis. After a bit of debugging I've found that this issue happens when my board is connected to the computer over USB.

Disconnecting power to the printer ends up turning off the 1XD, but not the 6HC, which still receives 5V over USB. If I then reconnect power, the default direction for the external stepper is incorrect. Because the 6HC has not been powered off, it doesn't rerun the config file. Manually sending the appropriate M569 command restores the correct Z-axis direction.

How can I solve this issue? I think the right way to do this would be for the 6HC to send the appropriate commands to the 1XD when it first connects to it, but this doesn't seem to be the default behavior.

@fcwilt That's what I was thinking as well, but I was hoping I had missed a simpler way of doing things. Thanks for your help.

@fcwilt The issue isn't so much the emergency stop part, but using the z-probe's analog signal to trigger, for two potential reasons:

• The M581 command seems to only support digital inputs, not analog. I found this firmware request for an analog trigger from 2019 (https://forum.duet3d.com/topic/11549/analog-threshold-for-m581-trigger) but don't know if this has been implemented.

• Using a specific pin name for M581 seems to no longer be supported. You first have to define the IO to use with the M950 command. I'm not sure if it's possible to use M950 with the same pin as the Z-probe or if this causes problems. I tried and didn't see the sensor appear in the object model.

Hi, I'm using a load cell as a Z-probe on my system. I would like to configure an external trigger such that if the load cell value reaches a certain analog value, it triggers an e-stop. This is mostly for safety to avoid damaging the load cell if something goes wrong.

Is this possible? Thanks.

@dc42 I noticed this while plugging nothing but a couple of Nema 17 motors to a Duet 3 6HC board and testing the feature out at my desk. There seems to be some sort of limitation beyond 50 Hz (it's actually something like 51 or 52, not sure if that matters), but it doesn't seem hardware related.

Quick update on this topic: I was able to modify the height following code to control the speed of any axis based on analog inputs. I was able to use it to print with our six-axis robot and initial results seem promising.

If ever this might be useful to someone, the code is here: https://github.com/soccerpaul/RepRapFirmware/tree/3.3-dev-analog_extrusion. I've currently just replaced the height-following files with mine instead, but it would be pretty easy to modify them to make them compatible with the main reprap firmware branch. I may try to do this in the coming months.

One last question: I was never able to use the height following code at more than 50Hz, despite the code indicating it should work up to 200Hz. For standard height following, motion becomes very erratic beyond 50Hz and the z-axis won't hold its position correctly. Using my modified code, motion becomes extremely jerky beyond 50Hz. Is there something that somehow limits the frequency of the aux move queue?

Are deceleration-only moves somehow handled differently in the code? I've been debugging using M111 with the Move and DDA modules active and noticed that even if I specify an endSpeed lower than my startSpeed, it registers the topSpeed as being my endSpeed and the decelDistance is always zero. I think this may be why I've been having trouble getting deceleration to work as reliably as acceleration and constant-speed moves.

EDIT: I think I may have found the issue. In DDA::RecalculateMove, if the requestedSpeed and endSpeed are identical, the logic in the if-loops breaks down and you end up with a decelDistance of zero and a topSpeed that's equal to the endSpeed as I had observed with M111. I guess the way I implemented speed control is incompatible with the way the RecalculateMove function works right now. I'll see if I can make it work tomorrow.

@dc42 are there any good tools for debugging changes you make to the firmware? I rewrote the height control code to modify speed instead of height based on the sensor value and it works reasonably well, but I'm limited to a max frequency of about 50 Hz (beyond that the motor begins to act strangely) and I had to make my moves' max deceleration smaller than my max acceleration for reasons I don't really understand.

So far I've just been testing modifications by recompiling the code and seeing how it runs based on how my motor responds to me turning a potentiometer, but this takes quite a bit of time without knowing what is actually happening. Is there any way to know how much the buffer is being filled for example?

@dc42 I noticed another bug with the M595 command: it only lets you increase the number of DAs, trying to reduce them does nothing and it doesn't warn you.

Edit: looking in the code, this seems to be the intended functionality, but it isn't clear in the documentation.