Does M594/M951 work?

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