Posts made by soccerpaul

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.

@dc42 I had initially discarded it since it doesn't act on moves currently in the buffer, but if I shorten the buffer sufficiently it may be a feasible option. The other limitation I'd come across was the maximum baudrate on my serial port (not on the Duet but on the 6-axis robot); I originally was sending multiple short extrusion commands that I was modulating based on the robot's current speed, but I was getting poor responsiveness at low baudrates and skipped moves at higher ones. That's why I was hoping to modify the firmware so that the Duet can deal with the speed changes internally based on my more responsive analog signal.

Is there a better way of doing this? I'd like to get as close as possible to real-time speed control (a constant, short delay is okay).

@dc42 thanks for the update. In my case I don't think I'll need filtering so it shouldn't be an issue, but it's good to know that's a limitation with the IO on the Duet 3.

That's because height following is supposed to react rapidly to changes in the sensor reading (subject to the PID configuration), so there isn't time to build up a sequence of moves in the lookahead queue.

Since I'm only planning on running one motor at a time for my application, would it then make sense for me to use the main DDA ring then instead? I'm thinking of sending my analog signal slightly ahead of time so that the buffer always has a move or two in it and controlling its speed that way.

I spent some more time on this, and after comparing DDA::InitStandardMove to DDA::InitAsyncMove in DDA.cpp, it looks like lookahead isn't implemented for the second move queue, which further explains the jerkiness when height following.

@dc42 I spent some time looking at the code and I think the reason motion is jerky is because the buffer never fills up, so there's no time for lookahead: height following probes the sensor and launches a move which is completed by the time height following probes the sensor again.

Does this make sense? If so, what would be the best way to fix this?

@dc42 I just tried firmware 3.4.0beta7 and still had the same issue. To make sure we're on the same page, I'm configuring the sensor using the following command:

M308 S0 P"io4.in" Y"linear-analog" A"Analog Input" F0 B0 C1000.

Changing F0 to F1 gives me readings between 0-250 instead of 0-1000.

Has anyone been able to take a look at these commands to see what would need to be fixed for them to work correctly? I've messed around with all the settings but nothing works: z-axis motion is jerky and unreliable no matter what I change.

Given that my end goal is to simply spin an extruder at a speed proportional to an analog input, is there a more appropriate/reliable way to implement this than modifying the height control files?

@dc42 I tested a few things and still haven't been able to get fluid motion, especially when the error between the setpoint and current sensor value is small. When it's large, moves seem to be linked together okay (but not perfectly, still deceleration between moves). When it's small, the axis stops between each move. At high sampling frequencies (see point 4 below), this makes the axis vibrate a ton as it's adjusting its position.

Things I've noticed:

• Noise on the analog signal is very low, so I don't think that's linked to the jerky motion. I have M308 set to between 0 and 1000°C and get less than 1° variation when I set it to a specific voltage. I'm using a variable power supply hooked up to a resistor as my analog input.

• Using F1 with the M308 command causes the sensor reading to be divided by 4. This means you usually have to redefine your setpoint for height control. There's an S parameter for the M594 command (in the code but not in the documentation @droftarts ) that allows you to redefine the setpoint, default is 1. F1 had no effect on jerkiness, which seems expected given the low signal noise already.

• Buffer length has no effect on jerkiness. I don't think the buffer gets filled up much, but I'm not sure how to check that.

• As you'd expect, the frequency parameter in M951 changes the frequency of the stop and go motion of the axis. At 1Hz, the axis ticks like a clock. The "ticking" speed increases as you increase the M951 frequency up until about 50 Hz. I thought this might be because the axis was quickly moving to it's next position before it was able to sample the sensor again, but beyond 50Hz, behavior doesn't change at all. It does still seem odd to me that acceleration and feed rate are always set to the max possible value in the code rather than depending on the frequency you set.

Any ideas as to what might be causing these issues?

@dc42 I tried doing that over the weekend but it didn't make a difference in the jerkiness. I noticed changing the buffer length didn't have any effect on the object model parameter (don't remember the exact name of it), although querrying M595 showed the updated queue length. Not sure if that's normal behavior. I'll give it another try sometime tonight or tomorrow, maybe changing the default queue length in the code to be sure it's actually changing.

@t3p3tony Follow up about the last post now that I've spent some time modifying the height control module to vary speed rather than position:

• regarding previous point 2, the S parameter isn't in the code, only H. I thought it worked after using H once, but it's just that once the sensor number has been implemented using H, further 951 commands don't need to specify it, so the S parameter does nothing. Should be an easy documentation fix.

• is motion lookahead somehow not implemented for the second dda ring? The axis doesn't link moves together, so it stops after every aux move commanded by the height controller and makes motion very jerky. I'd imagine this isn't a massive problem for real-time height control if you're not moving much, but it's particularly problematic now that I'm trying to control speed.

@t3p3tony I started testing out the commands today to see how they work (I'm running firmware version 3.3 on a Duet 3 6HC). I created a basic setup where turning a knob on a variable power supply changes the analog signal into pin io4.in. I've noticed a few problems with the commands:

1- When I create a linear analog sensor (M308 S0 P"io4.in" Y"linear-analog" A"Analog Input" F0 B0 C5), F1 doesn't work correctly, the sensor ends up being mapped from 0-1.2°C instead of the 0-5°C I want. F0 works fine. (Note that °C aren't my actual units, just what's displayed by DWC in the sensor section, I didn't see a spot to change the units. IO4.in seems to take an input from 0-3.3V which I remapped to 0-5°C). I tried the command out first on firmware 3.1.1 and I don't remember having the same problem, F1 and F0 worked the same.

2- The first time I launch M951, the S parameter to indicate which sensor to look at doesn't work, only H does (according to the documentation, both should work). If I try to use S, it accepts the command but doesn't actually configure height following. Once I've configured it once using H (M951 H0 P100 I0 D0 Z0:5), I can then reconfigure it using either H or S and it works correctly.

3- In the code (HeightController.cpp, function HeightController::StartHeightFollowing) I noticed that M594 can take additional parameters that aren't in the documentation. The first is setPoint (configured using the S parameter) which defaults at 1. This value is used when calculating how much to move the axis (error between the current sensor value and the setpoint is the PID input). When it's set at 1, turning the knob past 1°C makes the motor spin one way, and vice versa. Launching M594 P1 SX changes the setpoint to X°C as I expected. The other parameter is Z which sets the limits of height control in the same way as M951. Launching M594 P1 Z0:2.5 reset the limits I had set in M951.

4- When setting the z limits using M951 or M594, it seemed to get confused around 0: sometimes it creates the limits in one direction, and other times in the other. I didn't test this out much to figure out why.

None of these things seem like showstoppers, but thought I would mention them. I think I have what I need to start modifying the code to make it applicable to other axes and then do velocity control instead of position control. The only thing I'm worried about is smooth motion on the extruder; will send an update when I get that far.