143177Mach3 trajectory testing (from a linuxcnc guy)
- Feb 11, 2014Linuxcnc trajectory planner currently has some short falls.. (there - I said it). It, in effect, has a read ahead of 1 segment. This works great for the most part - but when you get into programs with really short segments - that limitation show itself.. That being said - there is some work going on right now to improve the planner (read ahead depth). I have been testing it and it is showing a lot of promise.. (engraving programs taking 1/2 the time of the current linuxcnc planner)
Why am is still talking?
In the process of testing the new TP and some mesa Ethernet hardware I thought I could read in the steps/dir from one linuxcnc to another and plot the path, velocity and acceleration. So the workflow was like this. Linuxcnc -> step/dir -> printer port -> mesa 7i80 encoder counter set to read step/dir -> ethernet -> linuxcnc. yes - that is a rube Goldberg device...
Linuxcnc has a neat thing called halscope which is like a digital oscilloscope. After playing with it for a bit - I figured out I had to measure acc over a longer time period to take into account small spikes in step signal velocity. (measuring acceleration is harder than I thought it would be..) but still - the velocity slope still doesn't lie...
Now there is a gcode program in linuxcnc called tort.ngc. This literally stands for torture. It was made to test the trajectory planner of linuxcnc. It is made up of short/long line segments and short/long arcs in all 3 planes. (diabolical..) It also happens to fit under the mach demo 500 line limit.
Now the machine is setup with 1500 step/inch, 30in/sec^2 acc and 500ipm.
here is a short video of it running and linuxcnc displaying the path (you can see the averaged over 36ms acc peak also)..
Now I can run the program over and over in mach - it follows the program path in linuxcnc perfectly. No lost or gained steps. What I am seeing is pretty large acceleration constraint violations
Here is an image of a simple jog in mach plotted.
You see it peaks a bit over 8in/sec (set to 500ipm) and the slope works out to about 30in/sec^2. Now pay attention to the slope. (there is acceleration trace - it is quite stair stepped because I am sampling it every 36ms) but it also hovers around 30in/sec.
here is one section of the tort program.
G0 X0 Y0 Z20
G0 X5.394910 Y13.495489 Z20.332291
G19 G2 F12700 (225 29) J5.656854 K5.656854 X10.394910 Y26.080547 Z29.989145
G19 G2 (75 14) J-0.258819 K-0.965926 X6.894910 Y26.787653 Z29.282038
G17 G2 (329 285) I-4.330127 J2.500000 X3.858878 Y24.458024 Z31.282038
G0 X0 Y0 Z20
(did I mention that it is diabolical..)
This section of code seems to consitantly (every time - so I don't think it could be a computer setup issue) violate acceleration by quite a bit
The velocity slope of that trace is approaching over 90in/sec^2. Looking at the backplot - it seems to follow the path too close..
Here is an example of linuxcnc's path for the same segments..
When tort.ngc is run in mach ( http://pastebin.ca/2638724 ) there are a lot of violations (and I was only paying attention to the x axis). Could it be I am doing something wrong? It is the current downloaded version from the website. Only thing changed was setting each axis to 500ipm, 30in/sec^2 and 1500 steps per inch. Is there a way to test this within mach?
This is linuxcnc running with the same settings over multible runs. (not reseting the peak acc readings and over the same 36ms period.)
- Next post in topic >>