search

hzeller / beagleg

G-code interpreter and stepmotor controller for crazy fast coordinated moves of up to 8 steppers. Uses the Programmable Realtime Unit (PRU) of the Beaglebone.
http://beagleg.org/
GNU General Public License v3.0
122 stars 51 forks source link

Added simple test that ensures accelerations constraints are met. #44

Closed lromor closed 2 years ago

hzeller commented 2 years ago

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 commented 2 years ago

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
spiral-cut-old spiral-cut-new

Slightly easier to see in this direct comparison

spiral-cut-compare

I think we need some unit test that test this with

hzeller commented 2 years ago

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

codecov-commenter commented 2 years ago

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%) :arrow_up:
src/machine-control-config.cc 77.46% <100.00%> (+0.32%) :arrow_up:

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 commented 2 years ago

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

hzeller commented 2 years ago

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

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

lromor commented 2 years ago

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

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

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

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 commented 1 year ago

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

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 GitHubhttps://github.com/hzeller/beagleg/pull/44#issuecomment-1086619853, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAMSUIN47QY2OTHHK7EPXMLVDAVM3ANCNFSM44BUV6QA. You are receiving this because you are subscribed to this thread.Message ID: @.**@.>>

hzeller commented 1 year ago

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.