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

143179Re: [mach1mach2cnc] Mach3 trajectory testing (from a linuxcnc guy)

Expand Messages
  • art2
    Feb 11, 2014
    • 0 Attachment
      
      Hi Sam:
       
         I cant speak as to why the segment concatenation seems to work differently as you show, (Im assuming vel and acc are set identically?). I know
      theres quite a few changes since Ive been gone, the dislocation seems extreme though, is it possible that the CV options in Mach are setup differently
      from normal.  One of the differences Mach3 had to linuxCNC was that the CV had mixing options like CV distance. (To be honest its been awhile since
      Ive played in that area, I still tend to use my own version of Quantum. ( I wonder what that would have showed up in graphing.. :) )
          When CV options are turned off there really shouldnt be any difference between the two ( at least last time I saw the release code anway.).
       
         So what changes are they planning to the linux planner? I wrote a multiaxis 6th order planner a few years back (Tempest) , it used quintics as the main time generator and  Hermite curves to join individual segements together for a c2 continuous path. I wrote a scope for it back then that showed it was as smooth as Ive ever seen planned motion, but its complexity codewise was pretty severe.  Im curious what path the linux guys may have decided to go down.  If you get a chance, try Quantum in your scope, its basically Mach3 running a tempest planner..
       
      Thanks,
      Art
      www.gearotic.com
       
       
       
       
      ----- Original Message -----
      Sent: Tuesday, February 11, 2014 5:14 PM
      Subject: [mach1mach2cnc] Mach3 trajectory testing (from a linuxcnc guy)

       

      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)..
      http://youtu.be/HfU4uyGgLZw

      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.
      http://imagebin.org/292777

      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.
      g21
      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
      m30

      (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
      http://imagebin.org/292790

      The velocity slope of that trace is approaching over 90in/sec^2.  Looking at the backplot - it seems to follow the path too close..
      http://imagebin.org/292791

      Here is an example of linuxcnc's path for the same segments..
      http://imagebin.org/292801

      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.)
      http://imagebin.org/292810

      sam

    • Show all 14 messages in this topic