Does M594/M951 work?

soccerpaul

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

soccerpaul

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

dc42

@soccerpaul by default the second motion queue is very short, just 3 moves AFAIR. You can lengthen it using the M595 command, https://duet3d.dozuki.com/Wiki/M595. Don't forget to include the Q1 parameter.

droftarts

@soccerpaul said in Does M594/M951 work?:

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.

Thanks, fixed by removing S as a parameter. https://duet3d.dozuki.com/Wiki/M951

Ian

soccerpaul

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

dc42

@soccerpaul it looks like DWC is not being informed that this part of the OM has changed. I'll fix that in RRF 3.4beta7. Meanwhile, if you press F5 to refresh the browser tab, you will see the updated value.

soccerpaul

@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?

soccerpaul

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

@soccerpaul said in Does M594/M951 work?:

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.

Which firmware version are you using? I just tested configuring a Linear Analog sensor using firmware 3.4.0beta7 and the reading remains the same when I switch between F0 and F1, but fluctuates more when I use F0. There was a bug in this area for a while, but it was fixed in October 2020.

soccerpaul

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

soccerpaul

@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?

soccerpaul

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

@soccerpaul said in Does M594/M951 work?:

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

OK, I tested on a Duet 2. I'll re-test on Duet 3.

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.

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.

dc42

@soccerpaul I've found the problem with using F1. Only the thermistor input ports have filters, and if you try to enable filtering when using some other input port then the computation goes wrong. I've updated the M308 documentation and changed the code to disable filtering and issue a warning in this case.

soccerpaul

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

dc42

@soccerpaul can you achieve what you want to do using the M221 command?

soccerpaul

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

soccerpaul

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

soccerpaul

@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?

soccerpaul

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.