MotionControlType for Duet and RRF?

[JW]

Currently setting up OpenPnP ready to run my new machine.

My motion controller is a Duet 3 Mini 5+, which in the config.g file supports setting maximum feed rate, maximum acceleration, and maximum jerk limits.

Presumably then, this means I need to use the EuclidianAxisLimits MotionControlType in OpenPnP, given this option states "Apply axis feed-rate, acceleration and jerk limits multiplied by the proper speed factors."

[mark maker]

Hi JW

Duet is a Constant Acceleration controller. It cannot control Jerk. Accelerations are allowed to change abruptly = "infinite" Jerk. See also specifically:

https://en.wikipedia.org/wiki/Jerk_(physics)#In_motion_control

On super stiff machines  (expensive, and/or made by mechanics wizards) this does not matter much. On everybody else's machines it might cause vibrations/swinging, which might affect computer vision and pick/place precision (sideways-swinging nozzle). This is especially bad for affordable DIY-designs like Liteplacer.

If your machine is super stiff, you can use ConstantAcceleration, i.e.. OpenPnP sending the predicted attainable feed-rate maximum (ramp peak), given the distance. Or, as you proposed, you can set EuclideanAxisLimits, i.e., OpenPnP sending the theoretical maximum allowed by the Speed % set. The end result should not actually differ between the two, i.e., with EuclideanAxisLimits the controller should come to the same conclusion when calculating the maximum attainable feed-rate given the distance. The only difference is that you don't see the attainable feed-rate in the G-code/log.

If your machine does suffer from vibrations/swinging to some degree, there are some means to try and remedy it. If it is relevant, it will become visible in Camera Settling. Watch the first part of this video:
https://youtu.be/Pxg6g3KI5_E

OpenPnP can also try and help against vibrations/swinging. Issues & Solutions will propose ModeratedConstantAcceleration, and then you can find suitable Jerk limits. Quoting the Wiki:

Apply motion planning assuming a controller with constant acceleration motion control but moderate the acceleration and velocity to resemble those of 3rd order control, resulting in a move that takes the same amount of time and has similar average acceleration.

This will reduce vibrations to a degree.

Why? The moderation means that short moves accelerate more gently, as the acceleration is quickly followed by deceleration, which seems to agitate the machine more. Long moves are allowed to accelerate and decelerate much harder, but as they do so longer, this seems to induce less vibrations. If you think of the acceleration/deceleration ramp as a "half wave", the long move has a longer wave-length i.e. lower frequency and therefore seems to resonate less with the machine frame. Well, it helps on my machine.

On some better controllers (this should include newer Duet models), you can also use Simulated3rdOrderControl. Again you can then find suitable Jerk limits. That's what you see in the above-linked video. Quoting the Wiki:

Apply motion planning assuming a controller with constant acceleration motion control but simulating 3rd order control with time step interpolation. Watch a video to see the effect of Simulated3rdOrderControl on oscillations/vibrations. You also need to setup the Interpolation.

Wiki:
https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#motion-control-type

Alternative:

Duet has controller based input shaping, but AFAIK it is mostly aimed at the rather slow and regulated feed-rates in 3D-printing, in order to fight so-called Ringing/Ghosting, I'm skeptical it can help with pick&place where we want the highest attainable speed (unregulated), i.e. shaping has nothing to "shape" or it would be costing us speed during the whole move, not just at the beginning/end as it does in 3D printing. On a machine like Lightplacer it would also have to support axis dependent frequencies (Y swings much slower than X) which AFAIK Duet does not yet do. Ask the Duet guys.

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/93eea5b5-8558-4ae2-b20c-c941a968fb5fn%40googlegroups.com.

[dc42]

Both input shaping and 3rd order motion control adjust how the acceleration changes. Input shaping does slow down the move a little if you keep the peak acceleration the same as without - but so does 3rd order motion control!

As to having different vibration frequencies on X and Y axes, RRF supports a range of input shapers, some of which cover frequency ranges as high as 3:1. The resonant frequency of a mass moved by an elastic motor and belt system depends on the square root of the moving mass. This means that if the X and Y motors are similar and the belts have equal length and equal tension, the ratio of the X and Y moving masses would need to exceed 9:1 for input shaping to be unable to cover both frequencies.

It would be interesting to put an accelerometer on the pickup head of a Lightplacer or similar machine and use the RRF Input shaping Plugin to measure the vibration frequencies , and then see the effect of applying separately simulated 3rd order motion control and input shaping.

[JW]

Ah, I stand corrected. This thread led me to believe S-curve acceleration was now implemented as it states it was on the list for RFF 2.01, and I had failed the realise the jerk limit in the config.g file is not mm/sec^3. The same thread I linked to suggests the 'jerk' limit in the config file rather controls "I'm not exactly sure how jerk is implemented in firmware (DC42 please step in here) but I assume that "normal" deceleration will take place unless the velocity is below the jerk setting threshold, at which point no further deceleration will take place and the head will change direction at whatever the jerk velocity is set to."

I see S-curve accel is in Marlin, but not Duet?

So, my machine is hugely stiff in X (it's a high-lead ballscrew driven, all metal frame machine), and my speed and acceleration are both limited by available motor torque not stiffness, but it's not at all stiff in Y, as it's driven by a single ballscrew one side, with a gantry on linear rails with a single carriage either end, so I can currently only achieve only ~1/3rd of the acceleration in Y without horrible machine vibration. This machine is a conversion of a manual pick and place I built some time ago, so it was always a known limitation of this version that I plan to fix in the future, so a 3rd order motion profile would help me enormously at the moment for the Y motion.

The part I was struggling to get my head around initially with using Duet as a constant accel controller, how does OpenPnP 'shape' the acceleration profiles is the acceleration is controlled by Duet? Watching your video it looks like M204 is being rapidly issued to reset the acceleration limit.

The only way I can see this works, is if the accel set by M204 can be set on the fly, i.e. mid-move? Presumably this is how the system works?

[JW]

I should add that last comment stands from being totally unfamiliar with the Duet and OpenPnP architecture still, I don't know for example how OpenPnP plans multi-move motions, or does it queue them up in the Duet and RFF takes care of executing sequential moves etc, so far I've only got motion going through Duet DWC only.

[JW]

Ok, now I see what's going on after a bunch more reading. You've split the up into lots of small moves, which get added to Duet's 'command queue', and for each of those moves you're increasing or decreasing the acceleration, to achieve 3rd order motion control!

[mark maker]

> Watching your video it looks like M204 is being rapidly issued to reset the acceleration limit.

> The only way I can see this works, is if the accel set by M204 can be set on the fly, i.e. mid-move? Presumably this is how the system works?

That's exactly how it works, see the fainter red steps trying to mimic the bold red curve in the diagnostic graph (you can enable diagnostics on the OpenPnP Motion Planner tab on the Machine):

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#interpolation

On my Liteplacer (with Smoothieware controller) it helped tons. 

Note 1, the original Liteplacer comes with TinyG which has native S-Curves. I don't understand how these work, so I reserve comments.

Note 2, the Marlin S-Curves are not 7-segment 3rd order, only 5-segment (no constant acceleration segments), which makes long moves slow, which may be okay for 3D-printing, but sucks for PnP.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/574284f3-8efe-4272-8475-146af7e24785n%40googlegroups.com.

[JW]

Thanks Mark,

This is one of those "the more I learn the more questions I have" moments.

The Duet manual says "RepRapFirmware applies the M204 accelerations to the move as a whole", which seems to contradict the ability to constantly update acceleration mid-move, as does the fact that in your video there are lots of G1s being issued which seem to be a broken up movement.

When you say that's exactly how it works, is that in response to my latest post about breaking the move up into lots of small G1 moves, each with their own acceleration value?

[Wayne Black]

When you say that's exactly how it works, is that in response to my latest post about breaking the move up into lots of small G1 moves, each with their own acceleration value?

Thats how Ive come to understand it, but dont know how accurate that is. It's the only way my head can wrap around it. 

One weird Duet phenomenon that occurs about 1 in 10 is when I park the head at the maxima XY 400mm and then attempt to return to home, the head accelerates as usual, but hits a slow motion wall the middle 3rd of travel between Park (400,400) and visual home (75,75). This is not repeatable and has only happened a couple times. I don't know if its the Duet or openpnp sender or what, but the occurrence does not trip the CL drivers and the job executes just fine at norm speed. Ive only noticed this happen 2-3 times.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/53b7b3cd-bebb-4199-a51c-673115491558n%40googlegroups.com.

--

Wayne Black

Owner

Black Box Embedded, LLC

black...@blackboxembedded.com

1.831.682.4964

[mark maker]

> The Duet manual says "RepRapFirmware applies the M204 accelerations to the move as a whole", which seems to contradict the ability to constantly update acceleration mid-move, as does the fact that in your video there are lots of G1s being issued which seem to be a broken up movement.

Duet provided me with a free controller so I could optimize it for OpenPnP and vice versa. Aside from working closely together with dc42 for him to make it more standards compliant, I contributed a PR to the RepRap firmware:

https://github.com/openpnp/openpnp/wiki/Motion-Controller-Firmwares#duet3d

I remember that at a time I tested the firmware and recorded/printed some timing values. The move with the shaped acceleration took exactly (down to the MCU timer resolution!) as long as predicted in OpenPnP. This would not have been the case if acceleration was only applied as a constant.

> One weird Duet phenomenon that occurs about 1 in 10 is when I park the head at the maxima XY 400mm and then attempt to return to home, the head accelerates as usual, but hits a slow motion wall the middle 3rd of travel between Park (400,400) and visual home (75,75). This is not repeatable and has only happened a couple times.

That PR I mentioned above, adds a configurable grace period to wait for the whole interpolation command sequence to be received (over serial) before starting into the move. It it does not wait long enough, it might rush into premature deceleration, as it does not know yet, that the move will continue into the same direction. Unfortunately, Duet's USB serial implementation was not the fastest at the time, don't know how it is today. So you need a certain grace period (the much older Smoothie had much, much faster USB serial then).

What you're observing might be because of your grace period not being configured high enough. Or there was a regression on the firmware...

Note the grace period can be configured to be quite long without ill effect, as it is immediately forfeited when an M400 is received, or when the motion queue is full. Plus this wait is also only relevant for the first leg in a move segment after the machine stood still.

Speaking of the motion queue: make sure yours is configured large enough.

Also: don't overdo it on interpolation steps. There is a point when it takes longer to receive all that chatter over serial than what is saved by optimizing the motion speed.

I don't know if the example here...

https://github.com/openpnp/openpnp/wiki/Duet3D-Openpnp-Example

...includes all this, i.e. I don't know if the user contributing this ever used Simulated3rdOrder. If you figure it out, please help improve it.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/53b7b3cd-bebb-4199-a51c-673115491558n%40googlegroups.com.

[dc42]

I think I should point out that S-curve acceleration fell out of favour in 3D printing firmware because it isn't effective at reducing the low frequency resonances that cause ghosting in 3D prints. Analysis shows that S-curve acceleration reduces high frequency ringing but may actually make low frequency ringing slightly worse if peak acceleration is increased to keep the movement time constant. Whereas input shaping is very effective at reducing ringing over the band of frequencies that it targets.

I doubt that ringing in PnP machines such as Lightplacer would be at much higher frequencies than it is on 3D printers, but we really need to do accelerometer tests to find out. Mark, do you have a Duet-controlled PnP machine that you could add an accelerometer to? We can provide either a standalone accelerometer that plugs into the main board (max cable length 1m) or our scanning sensor board (that also has an accelerometer) that connects to any Duet 3 main board via CAN bus and power.

[mark maker]

My machine is not Duet driven (the Duet board is only on my test rig). 

But there are other users out there. I hope this call reaches them too!

The Liteplacer swinging is very low frequency. It is somewhat visible in video scenes here (see how the nozzle swings):

https://youtu.be/5QcJ2ziIJ14?feature=shared&t=167

Also somewhat  visible in Camera Settling:

https://youtu.be/Pxg6g3KI5_E?feature=shared&t=31

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/55e4ede6-5593-47ae-976f-bdc490b978f7n%40googlegroups.com.

[JW]

I can grab some acceleration data from my machine today in X and Y using just simple constant accel, I have access to a range of high resolution/high speed accels.

I suspect it'll show high (relatively speaking) frequency, low amplitude ringing in X, as I'm currently at around 20,000mm/sec^2 in X, but low frequency, high amplitude in Y where the machine is currently far less stiff. Though that depends where along the X gantry the head is, right next to the Y screw it'll be much lower amplitude.

So, Mark, just to finalise my understanding of this - M204 does indeed only to each move in general, but that is referring to each moment command, which may be only a portion of a complete machine movement.

So, given the move (machine movement) is broken up into many smaller movement commands, M204 allows you to control each step of the machine movements accel profile?

[Wayne Black]

That PR I mentioned above, adds a configurable grace period to wait for the whole interpolation command sequence to be received (over serial) before starting into the move. It it does not wait long enough, it might rush into premature deceleration, as it does not know yet, that the move will continue into the same direction. Unfortunately, Duet's USB serial implementation was not the fastest at the time, don't know how it is today. So you need a certain grace period (the much older Smoothie had much, much faster USB serial then).

What you're observing might be because of your grace period not being configured high enough. Or there was a regression on the firmware...

Thanks Mark! Great insight and makes a lot of sense. Honestly not sure what duet FW Im running at the moment. One thing when configuring Duet CAN expansion boards the FW rev needs to be the same between the main and dtr boards. Or at least that's how I remember it. I'll take a look at things and see what I'm actually running in terms of Duet RRF FW.

Re accelerometer testing, I'd be happy to do this in future when the machine is back together, currently it is not.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/10b28b83-492a-4623-8c47-b0f289960307n%40googlegroups.com.

[JW]

Just grabbed some data now, sampled at 0.4mg resolution, 1kHz rate with accel bandwidth configured for 218Hz, digitally filtered in post to ISO 6487 CFC60.

This is from X axis, the machine accelerates and decelerates rapidly with no visible vibration and low noise. The X gantry is typical of industrial machines; linear rails, ballscrew, tight spacing between rail and screw etc. This is at ~20,000mm/sec^2 acceleration,

There is a 250Hz vibration overlaid on the profile, but this is visible in the all three channels of the accel so I assume this is linear ball carriage vibration, and there is no oscillation when coming to a stop.

This is:

G91

G1 X150 F40000

G1 X-150 F40000

Y on the other hand is terrible in comparison, this is a single Y ballscrew, dual Y rails but with single carriages, and thus the end of the gantry that spans X is free to oscillate on the end without the ballscrew. It's easy to flex by hand too. Similar sizes and distances involved as the Liteplacer in Y. This is at 4000mm/sec^2.

I can only really run Y up to around 2000mm/sec^2 in it's current design, which is an order of magnitude less than X.

Frequency of gantry oscillation is ~12.5Hz.

David, what frequency ranges are you referring to when talking high/low?

[dc42]

I would class 12.5Hz as very low. In 3D printing I rarely see less than 30Hz reported, and 40-45Hz is more typical. Modern designs such as Voron with low-mass direct drive extruders are typically higher. Maybe someone should adapt the Voron mechanical design for PnP?

In practical terms, a mechanical resonance frequency is 'low' if half its period is comparable to or lower than the duration of an acceleration or deceleration segment, and 'high' if its period is much shorter than the duration of an acceleration or deceleration segment.

[dc42]

..that should have read " if half its period is comparable to or longer than the duration of an acceleration or deceleration segment".

[Zdenko Stanec]

Hi,

"Mark, do you have a Duet-controlled PnP machine that you could add an accelerometer to? We can provide either a standalone accelerometer that plugs into the main board (max cable length 1m) or our scanning sensor board (that also has an accelerometer) that connects to any Duet 3 main board via CAN bus and power."

@dc42 I can run some tests but unfortunately in around 2-3W, maybe you remember from the Duet Forum I run:

1x Duet3 Main Board 6XD
1x Duet3 Mini 5+ with Duet3 Mini2+
2x Duet 3 Expansion Board 3HC in the "Head" of the machine

On this machine, https://www.youtube.com/watch?v=uBc2w4u0snk

I am currently focusing on the feeders and other work but in a few weeks I can give it a try, it would be interesting to see the data.

Zdenko,

[dc42]

Thanks @zdenko. Please send me a private message a week or two before you are ready, with your address, and I will arrange from an accelerometer to be sent to you. It sounds to me that you already have CAN-FD bus going to the pickup heads assembly, so we'll send you one that needs just CAN and 5V power connections. You can get 5V power from one of the IO connectors of one of the 3HC boards.

[gong yi (K-Pax)]

Hello, I want to ask, why does my RRF board not support the simulated3rdordercontrol? But the simplest curve, and full3rdordercontroller was supported?

[Jan]

You need the GCodeAsyncDriver and populate (keep populated) all fields
in the Interpolation section on the Advanced Settings tab. (All fields
are preset to reasonable values).
Please keep in mind that Simulated3dOrderControl requires a lot of
bandwidth and might require a grace period in the controller to start
join segments as expected.

Jan

On 04.01.2026 16:34, gong yi (K-Pax) wrote:
> Hello, I want to ask, why does my RRF board not support the
> simulated3rdordercontrol? But the simplest curve, and

> full3rdordercontroller was supported?Snipaste_2026-01-04_23-31-38.png

>
> 在2024年5月10日星期五 UTC+8 17:39:57<dc42> 写道：
>
> Thanks @zdenko. Please send me a private message a week or two
> before you are ready, with your address, and I will arrange from an
> accelerometer to be sent to you. It sounds to me that you already
> have CAN-FD bus going to the pickup heads assembly, so we'll send
> you one that needs just CAN and 5V power connections. You can get 5V
> power from one of the IO connectors of one of the 3HC boards.
>
> On Thursday 9 May 2024 at 07:59:43 UTC+1 zdenko...@gmail.com wrote:
>
> Hi,
>

> /"Mark, do you have a Duet-controlled PnP machine that you could

> add an accelerometer to? We can provide either a standalone
> accelerometer that plugs into the main board (max cable length
> 1m) or our scanning sensor board (that also has an
> accelerometer) that connects to any Duet 3 main board via CAN

> bus and power."/

>
> @dc42 I can run some tests but unfortunately in around 2-3W,
> maybe you remember from the Duet Forum I run:
>
> 1x Duet3 Main Board 6XD
> 1x Duet3 Mini 5+ with Duet3 Mini2+
> 2x Duet 3 Expansion Board 3HC in the "Head" of the machine
>
> On this machine, https://www.youtube.com/watch?v=uBc2w4u0snk
> <https://www.youtube.com/watch?v=uBc2w4u0snk>
>
> I am currently focusing on the feeders and other work but in a
> few weeks I can give it a try, it would be interesting to see
> the data.
>
> Zdenko,
>
> On Wednesday 8 May 2024 at 11:09:18 UTC+2 dc42 wrote:
>
> ..that should have read " if half its period is comparable

> to or *longer *than the duration of an acceleration or

> deceleration segment".
>
> On Wednesday 8 May 2024 at 09:57:26 UTC+1 dc42 wrote:
>

> I would class 12.5Hz as *very *low. In 3D printing I

> X.PNG
>
> Y on the other hand is terrible in comparison, this
> is a single Y ballscrew, dual Y rails but with

> *single carriages*, and thus the end of the gantry

> that spans X is free to oscillate on the end without
> the ballscrew. It's easy to flex by hand too.
> Similar sizes and distances involved as the
> Liteplacer in Y. This is at 4000mm/sec^2.
>
> I can only really run Y up to around 2000mm/sec^2 in
> it's current design, which is an order of magnitude
> less than X.
>
> Frequency of gantry oscillation is ~12.5Hz.
>
>
>

> Y.PNG
>
> David, what frequency ranges are you referring to
> when talking high/low?
> On Tuesday, May 7, 2024 at 4:00:16 PM UTC+1
> black...@blackboxembedded.com wrote:
>

> /That PR I mentioned above, adds a configurable

> grace period to wait for the whole interpolation
> command sequence to be received (over serial)
> before starting into the move. It it does not
> wait long enough, it might rush into premature
> deceleration, as it does not know yet, that the
> move will continue into the same direction.
> Unfortunately, Duet's USB serial implementation
> was not the fastest at the time, don't know how
> it is today. So you need a certain grace period
> (the much older Smoothie had much, much faster

> USB serial then)./
>
> /What you're observing might be because of your

> grace period not being configured high enough.

> Or there was a regression on the firmware.../

> __

>
> My machine is not Duet driven (the Duet
> board is only on my test rig).
>
> But there are other users out there. I
> hope this call reaches them too!
>
> The Liteplacer swinging is very low
> frequency. It is somewhat visible in
> video scenes here (see how the nozzle
> swings):
>
> https://youtu.be/5QcJ2ziIJ14?

> feature=shared&t=167 <https://
> youtu.be/5QcJ2ziIJ14?feature=shared&t=167>

>
> Also somewhat  visible in Camera Settling:
>
> https://youtu.be/Pxg6g3KI5_E?

> feature=shared&t=31 <https://youtu.be/
> Pxg6g3KI5_E?feature=shared&t=31>

>> /> The Duet manual says

>> "RepRapFirmware applies the M204
>> accelerations to the move as a
>> whole", which seems to contradict
>> the ability to constantly update
>> acceleration mid-move, as does the
>> fact that in your video there are
>> lots of G1s being issued which

>> seem to be a broken up movement./

>>
>> Duet provided me with a free
>> controller so I could optimize it
>> for OpenPnP and vice versa. Aside
>> from working closely together with
>> dc42 for him to make it more
>> standards compliant, I contributed
>> a PR to the RepRap firmware:
>>
>> https://github.com/openpnp/
>> openpnp/wiki/Motion-Controller-

>> Firmwares#duet3d <https://
>> github.com/openpnp/openpnp/wiki/
>> Motion-Controller-Firmwares#duet3d>

>>
>> I remember that at a time I tested
>> the firmware and recorded/printed
>> some timing values. The move with
>> the shaped acceleration took
>> exactly (down to the MCU timer
>> resolution!) as long as predicted
>> in OpenPnP. This would not have
>> been the case if acceleration was
>> only applied as a constant.
>>

>> /> One weird Duet phenomenon that

>> occurs about 1 in 10 is when I
>> park the head at the maxima XY
>> 400mm and then attempt to return
>> to home, the head accelerates as
>> usual, but hits a slow motion wall
>> the middle 3rd of travel between
>> Park (400,400) and visual home
>> (75,75). This is not repeatable

>> and has only happened a couple times./

>> Example <https://github.com/
>> openpnp/openpnp/wiki/Duet3D-
>> Openpnp-Example>

>>
>> ...includes all this, i.e. I don't
>> know if the user contributing this

>> ever used *Simulated3rdOrder*. If

>>> /> Watching your video it

>>> looks like M204 is being
>>> rapidly issued to reset the

>>> acceleration limit./
>>>
>>> /> The only way I can see

>>> this works, is if the accel
>>> set by M204 can be set on the
>>> fly, i.e. mid-move?
>>> Presumably this is how the

>>> system works?/

>>>
>>> That's exactly how it works,
>>> see the fainter red steps
>>> trying to mimic the bold red
>>> curve in the diagnostic graph
>>> (you can enable diagnostics
>>> on the OpenPnP Motion Planner
>>> tab on the Machine):
>>>

>>> Simulated Jerk Control
>>>
>>> https://github.com/openpnp/
>>> openpnp/wiki/
>>> GcodeAsyncDriver#interpolation <https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#interpolation>

>>>
>>> On my Liteplacer (with
>>> Smoothieware controller) it
>>> helped tons.
>>>
>>> Note 1, the original
>>> Liteplacer comes with TinyG
>>> which has native S-Curves. I
>>> don't understand how these
>>> work, so I reserve comments.
>>>
>>> Note 2, the Marlin S-Curves
>>> are not 7-segment 3rd order,
>>> only 5-segment (no constant
>>> acceleration segments), which
>>> makes long moves slow, which
>>> may be okay for 3D-printing,
>>> but sucks for PnP.
>>>
>>> _Mark
>>>
>>> On 06.05.2024 00:37, JW wrote:
>>>> Ah, I stand corrected. This

>>>> <https://reprap.org/forum/
>>>> read.php?
>>>> 1,747235,824213,quote=1#REPLY> thread led me to believe S-curve acceleration was now implemented as it states it was on the list for RFF 2.01, and I had failed the realise the jerk limit in the config.g file is not mm/sec^3. The same thread I linked to suggests the 'jerk' limit in the config file rather controls /"I'm not exactly sure how jerk is implemented in firmware (DC42 please step in here) but I assume that "normal" deceleration will take place unless the velocity is below the jerk setting threshold, at which point no further deceleration will take place and the head will change direction at whatever the jerk velocity is set to."/

>>>> <https://
>>>> en.wikipedia.org/
>>>> wiki/
>>>> Jerk_(physics)>.

>>>> Accelerations are
>>>> allowed to change
>>>> abruptly =
>>>> "infinite" Jerk. See
>>>> also specifically:
>>>>
>>>> https://
>>>> en.wikipedia.org/
>>>> wiki/

>>>> Jerk_(physics)#In_motion_control <https://en.wikipedia.org/wiki/Jerk_(physics)#In_motion_control>

>>>>
>>>> On super stiff
>>>> machines
>>>> (expensive, and/or
>>>> made by mechanics
>>>> wizards) this does
>>>> not matter much. On
>>>> everybody else's
>>>> machines it might
>>>> cause vibrations/
>>>> swinging, which
>>>> might affect
>>>> computer vision and
>>>> pick/place precision
>>>> (sideways-swinging
>>>> nozzle). This is
>>>> especially bad for
>>>> affordable DIY-
>>>> designs like Liteplacer.
>>>>
>>>> If your machine is
>>>> super stiff, you can
>>>> use

>>>> *ConstantAcceleration*, i.e.. OpenPnP sending the predicted attainable feed-rate maximum (ramp peak), given the distance. Or, as you proposed, you can set *EuclideanAxisLimits*, i.e., OpenPnP sending the theoretical maximum allowed by the Speed % set. The end result should not actually differ between the two, i.e., with *EuclideanAxisLimits* the controller should come to the same conclusion when calculating the maximum /attainable/ feed-rate given the distance. The only difference is that you don't see the /attainable/ feed-rate in the G-code/log.

>>>>
>>>> If your machine does
>>>> suffer from
>>>> vibrations/swinging
>>>> to some degree,
>>>> there are some means
>>>> to try and remedy
>>>> it. If it is
>>>> relevant, it will
>>>> become visible in
>>>> Camera Settling.
>>>> Watch the first part
>>>> of this video:
>>>> https://youtu.be/
>>>> Pxg6g3KI5_E

>>>> <https://youtu.be/
>>>> Pxg6g3KI5_E>

>>>>
>>>> OpenPnP can also try
>>>> and help against
>>>> vibrations/swinging.
>>>> Issues & Solutions
>>>> will propose

>>>> *ModeratedConstantAcceleration*, and then you can find suitable Jerk limits. Quoting the Wiki:
>>>>
>>>> /Apply motion

>>>> planning
>>>> assuming a
>>>> controller with
>>>> constant
>>>> acceleration
>>>> motion control
>>>> but moderate the
>>>> acceleration and
>>>> velocity to
>>>> resemble those
>>>> of 3rd order
>>>> control,
>>>> resulting in a
>>>> move that takes
>>>> the same amount
>>>> of time and has
>>>> similar average

>>>> acceleration./
>>>>
>>>> /This will
>>>> reduce
>>>> vibrations to a
>>>> degree./
>>>>
>>>> /Why? The

>>>> <https://
>>>> en.wikipedia.org/wiki/Resonance> less with the machine frame. Well, it helps on my machine./

>>>>
>>>> On some better
>>>> controllers (this
>>>> should include newer
>>>> Duet models), you
>>>> can also use

>>>> *Simulated3rdOrderControl*. Again you can then find suitable Jerk limits. That's what you see in the above-linked video <https://youtu.be/Pxg6g3KI5_E>. Quoting the Wiki:
>>>>
>>>> /Apply motion

>>>> planning
>>>> assuming a
>>>> controller with
>>>> constant
>>>> acceleration
>>>> motion control
>>>> but simulating
>>>> 3rd order
>>>> control with
>>>> time step
>>>> interpolation.
>>>> Watch a video

>>>> <https://
>>>> youtu.be/
>>>> cH0SF2D6FhM> to
>>>> see the effect
>>>> of
>>>> *Simulated3rdOrderControl* on oscillations/vibrations. You also need to setup the Interpolation <https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#interpolation>./
>>>>
>>>> Wiki:
>>>> https://github.com/
>>>> openpnp/openpnp/
>>>> wiki/
>>>> GcodeAsyncDriver#motion-control-type <https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#motion-control-type>

>>>>> openpnp/93eea5b5-8558-4ae2-b20c-c941a968fb5fn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/93eea5b5-8558-4ae2-b20c-c941a968fb5fn%40googlegroups.com?utm_medium=email&utm_source=footer>.

>>>>
>>>> --
>>>> You received this message
>>>> because you are subscribed
>>>> to the Google Groups
>>>> "OpenPnP" group.
>>>> To unsubscribe from this
>>>> group and stop receiving
>>>> emails from it, send an
>>>> email to
>>>> openpnp+u...@googlegroups.com.
>>>> To view this discussion on
>>>> the web visit https://
>>>> groups.google.com/d/msgid/

>>>> openpnp/574284f3-8efe-4272-8475-146af7e24785n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/574284f3-8efe-4272-8475-146af7e24785n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>>>
>>> --
>>> You received this message because
>>> you are subscribed to the Google
>>> Groups "OpenPnP" group.
>>> To unsubscribe from this group
>>> and stop receiving emails from
>>> it, send an email to
>>> openpnp+u...@googlegroups.com.
>>> To view this discussion on the
>>> web visit https://
>>> groups.google.com/d/msgid/

>>> openpnp/53b7b3cd-bebb-4199-
>>> a51c-673115491558n%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/53b7b3cd-bebb-4199-a51c-673115491558n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>>
>> --
>> You received this message because you
>> are subscribed to the Google Groups
>> "OpenPnP" group.
>> To unsubscribe from this group and
>> stop receiving emails from it, send an
>> email to openpnp+u...@googlegroups.com.
>> To view this discussion on the web
>> visit https://groups.google.com/d/

>> msgid/openpnp/55e4ede6-5593-47ae-976f-
>> bdc490b978f7n%40googlegroups.com
>> <https://groups.google.com/d/msgid/
>> openpnp/55e4ede6-5593-47ae-976f-
>> bdc490b978f7n%40googlegroups.com?
>> utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are
> subscribed to the Google Groups "OpenPnP" group.
> To unsubscribe from this group and stop
> receiving emails from it, send an email to
> openpnp+u...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/

> openpnp/10b28b83-492a-4623-8c47-
> b0f289960307n%40googlegroups.com <https://
> groups.google.com/d/msgid/
> openpnp/10b28b83-492a-4623-8c47-
> b0f289960307n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

>
>
>
> --
> Wayne Black
> Owner
> Black Box Embedded, LLC
> black...@blackboxembedded.com

> 1.831.682.4964 <tel:(831)%20682-4964>

>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenPnP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openpnp+u...@googlegroups.com

> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> openpnp/80283a77-c86a-49d9-a0e7-609f5195a645n%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/80283a77-c86a-49d9-
> a0e7-609f5195a645n%40googlegroups.com?utm_medium=email&utm_source=footer>.