Does M594/M951 work?

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.

soccerpaul

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?

dc42

@soccerpaul perhaps you have hit a resonance in your system around 50Hz? Or perhaps the acceleration that your system can support isn't high enough to support higher correction frequencies?

albertshao

I also have the similary question，it‘s luck to see you here

soccerpaul

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