Loading ...
Sorry, an error occurred while loading the content.

143177Mach3 trajectory testing (from a linuxcnc guy)

Expand Messages
  • samcoinc2001
    Feb 11, 2014
      Linuxcnc 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.)

    • Show all 14 messages in this topic