Added simple test that ensures accelerations constraints are met.

[lromor]

No description provided.

[hzeller]

Looks like there is a conflict in one of the files; the last change in the file was in #47 - maybe things got messed up in working in two branches ?

[hzeller]

Very nice, the hard deceleration now is completely gone just looking at the make test-html output.

It does seem to accumulate some slight rounding errors along the way, most noticeable in this spiral cut example, in which the new machine path (colored) slightly deviates from the gcode path (solid thin line) at the end of the travel.

Old	New

Slightly easier to see in this direct comparison

I think we need some unit test that test this with

• Very small segments (1 step long). Possibly also intermixed with 0 steps (which should not throw off the planner)
• switching defining axis between segments. So say given (Axis-X, Axis-Y) we have a segment sequence of (2,1), (1,2), (2,1), (1,2)... and possibly also a test with just one step like in the previous test case (1,0), (0,1), (1,0), (0,1)...

[hzeller]

You might now need to re-base this pull request to incorporate the planner test changes.

[codecov-commenter]

Codecov Report

Merging #44 (9485d25) into master (6b2d27a) will increase coverage by 0.86%.
The diff coverage is 98.24%.

@@            Coverage Diff             @@
##           master      #44      +/-   ##
==========================================
+ Coverage   44.34%   45.20%   +0.86%     
==========================================
  Files          38       38              
  Lines        4122     4174      +52     
==========================================
+ Hits         1828     1887      +59     
+ Misses       2294     2287       -7     

Impacted Files	Coverage Δ
src/planner.cc	81.87% <98.23%> (+5.80%)	⬆️
src/machine-control-config.cc	77.46% <100.00%> (+0.32%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6b2d27a...9485d25. Read the comment docs.

[lromor]

Has you suggested, let's add another test checking the behavior for different planning buffer capacities.

[hzeller]

This looks very good!
Here a first round of comments.

[hzeller]

With this change, the test with the square that is compared with single-segment lines vs. multi segment lint

• One-segment lines square-moves-direct.gcode
• Multi segment lines square-moves-small-segments.gcode

Is now properly accelerating and starting to decelerate in the middle. However, wouldn't we expect the speed profile now be exactly the same ? From the visualization it looks like that the small-segment version accelerates and decelerates quicker, leaving a longer stretch of fast movement ("yellow") in the middle. It looks like the postscript output has the same color/speed legend, so what is different ?

[lromor]

With this change, the test with the square that is compared with single-segment lines vs. multi segment lint

• One-segment lines square-moves-direct.gcode
• Multi segment lines square-moves-small-segments.gcode

Is now properly accelerating and starting to decelerate in the middle. However, wouldn't we expect the speed profile now be exactly the same ? From the visualization it looks like that the small-segment version accelerates and decelerates quicker, leaving a longer stretch of fast movement ("yellow") in the middle. It looks like the postscript output has the same color/speed legend, so what is different ?

I made a small python utility to compare the speed/steps plots of two gcode strings, these are the results for the two ways of doing a straight line:

They seem to nicely overlap. I guess gcode2ps doesn't really interpolate the colors based on the speed. It must be doing some linear interpolation if a single segment is provided (instead of using the sqrt function). This is not true for the simulation backend.

[bigguiness]

Hi Leonardo, I have been busy redesigning our larger motion control system and have not been able to actively follow your acceleration stuff. Is this ready for testing on actual hardware or are you still working on the test code? I can give it a spin on my hardware when it’s ready and give you feedback on how it physically looks. Regards, Hartley From: Leonardo Romor ***@***.***> Sent: Saturday, April 2, 2022 4:28 AM To: hzeller/beagleg ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [hzeller/beagleg] Added simple test that ensures accelerations constraints are met. (#44) CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. With this change, the test with the square that is compared with single-segment lines vs. multi segment lint * One-segment lines square-moves-direct.gcode<https://github.com/hzeller/beagleg/blob/master/src/testdata/square-moves-direct.gcode> * Multi segment lines square-moves-small-segments.gcode<https://github.com/hzeller/beagleg/blob/master/src/testdata/square-moves-small-segments.gcode> Is now properly accelerating and starting to decelerate in the middle. However, wouldn't we expect the speed profile now be exactly the same ? From the visualization it looks like that the small-segment version accelerates and decelerates quicker, leaving a longer stretch of fast movement ("yellow") in the middle. It looks like the postscript output has the same color/speed legend, so what is different ? [square-moves]<https://user-images.githubusercontent.com/140937/155919856-bd69dbe5-71b8-475f-8ce8-84e362b1cd50.gif> I made a small python utility to compare the speed/steps plots of two gcode strings, these are the results for the two ways of doing a straight line: [image]<https://user-images.githubusercontent.com/1597330/161380891-eb960636-6ab0-49bd-aefa-d5e4a46d8eb9.png> They seem to nicely overlap. I'll try to dig deeper. — Reply to this email directly, view it on GitHub<#44 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAMSUIN47QY2OTHHK7EPXMLVDAVM3ANCNFSM44BUV6QA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>

[hzeller]

Is this ready for testing on actual hardware or are you still working on the test code?
I can give it a spin on my hardware when it’s ready and give you feedback on how it physically looks.

Yes, the improved acceleration/deceleration code should be ready now.

Lines with many small segments (such as circles or arcs) that previously would result in an abrupt deceleration at the last segment, are now starting to decelerate early enough to meet deceleration constraints. I've run it on an actual machine and its moves and deceleration are smooth.

Code is slightly slower than before because of more calculations, but that only really shows in direct performance comparisons without a physical machine attached and shouldn't impact real-world speed (though we have it on the TODO list to see what can be improved).

The install document also has been updated to describe how to install BeagleG on a current Beaglebone Debian image.