Welcome! Log In Create A New Profile

Advanced

Polar GCode compiler progress

Posted by BeagleFury 
Polar GCode compiler progress
April 04, 2010 11:48PM
The latest bits of code I've worked on include a GCode compiler, to compile cartesian oriented GCode into motions the RepolaRap configuration would be able to use.

I'm still working on porting the acceleration limited motions to this code -- jerk limits still elude me -- but I thought the velocity limited curves look interesting for the simple GCode test I've been using -- it simulates a few layers of a 3cm-4cm-5cm right triangle outline:

G20           ; use metric
G90           ; use absolute coordinates

G1 Z0
G1 Z1
G1 X10
G1 Y10
G92 X0 Y0 Z0

G91           ; use relative

G1 Z0.5

G1 X30 E30
G1 Y40 E40
G1 X-30 Y-40 E50
G1 Z0.5

G1 X30 E30
G1 Y40 E40
G1 X-30 Y-40 E50
G1 Z0.5

G1 X30 E30
G1 Y40 E40
G1 X-30 Y-40 E50
G1 Z0.5

G1 X30 E30
G1 Y40 E40
G1 X-30 Y-40 E50
G1 Z0.5

This produces the image I've attached for motion on the build platform angle (red), radial arm angle (green), z axis (blue), and extruder motor (black).
Attachments:
open | download - Polar345GcodePath.jpg (185.2 KB)
Re: Polar GCode compiler progress
April 05, 2010 05:32AM
I am not sure jerk has any meaning on a CNC machine. You can change acceleration as fast as you want as long as you don't exceed the acceleration limits.


[www.hydraraptor.blogspot.com]
Re: Polar GCode compiler progress
April 05, 2010 07:48AM
nophead Wrote:
-------------------------------------------------------
> I am not sure jerk has any meaning on a CNC
> machine. You can change acceleration as fast as
> you want as long as you don't exceed the
> acceleration limits.

I sort of hoped this would be the case. Does this mean that the RepRap type structures are mostly immune to the high frequency noise and vibration induced when you use punctuated extreme jerk (I.E, change acceleration from 0 to maximum in a single step?)

Edited 1 time(s). Last edit at 04/05/2010 08:04AM by BeagleFury.
Re: Polar GCode compiler progress
April 05, 2010 09:03AM
Well I limit the acceleration of my machines, but not the rate of change of acceleration. You get forces proportional to acceleration. Forces create displacement of the structure. I am not sure you get any less displacement if you ramp up the force as opposed to applying it instantaneously.

The thing that makes big differences is hitting the resonant frequency of the structure. With say a zigzag motion on a Cartesian machine the excitation force would be a square wave. If you limit the rate of change of acceleration it would be a triangle wave, but the frame will resonate with SHM in both cases. Maybe it would have a smaller amplitude but unless the machine was moving slower, if you ramp up the acceleration you have to have a higher value at the end of the ramp to get to the same speed. I.e. the triangle wave would be bigger amplitude than the square wave. So I think you would have more energy in the lower harmonics and less in the higher.

The other thing to consider is the stepper motors. They have a maximum acceleration due to inertia, but there is no limit of rate of change of acceleration. Torque falls off with velocity so for maximum performance you would start with high acceleration and ramp it down as speed increases. Oddly most systems, including mine, use linear acceleration.


[www.hydraraptor.blogspot.com]
Re: Polar GCode compiler progress
April 05, 2010 03:39PM
nophead Wrote:
-------------------------------------------------------
> The thing that makes big differences is hitting
> the resonant frequency of the structure. With say
> a zigzag motion on a Cartesian machine the
> excitation force would be a square wave.

Would you agree that, given a square wave, and a number of 'zigzag' frequences, that the chance of hitting a resonant frequency is much greater than if you apply a low pass filter?

The 'square wave' vs 'triangle' wave visualization you present should reenforce this (except replace 'triangle' with 'trapazoidal'). If you perform a fourier analysis on the waves, you'll see an aweful lot of frequencies on the square wave, just waiting to induce resonance. The trapazoid form will almost entirely consist of the fundamental frequency, with only miniscule secondary frequencies... I.E, it acts as a low band pass filter. Maybe that's the key to solving the problem I've been working on.. rather than trying to limit jerk or acceleration, I just have to pass it thru a few fourier transforms and smooth everything out. ;-) (Kidding.. well.. hmm.. okay.. that sounds fun.. half kidding! smiling smiley )
Re: Polar GCode compiler progress
April 05, 2010 05:15PM
I think square and triangle waves have all the same harmonics, just the triangle wave has more of the fundamental and falls off faster, so if that is where the resonance is it would be worse, but if it is a resonance at a harmonics it could be better.

I don't think my machine resonates much at harmonics. The faster the zigzag, the more it shakes and things start to fall of the desk. I haven't seen a faster one that shakes less or a slow one that hits a resonance.


[www.hydraraptor.blogspot.com]
Re: Polar GCode compiler progress
April 05, 2010 09:47PM
nophead Wrote:

> The faster the zigzag, the more it
> shakes and things start to fall of the desk. I
> haven't seen a faster one that shakes less or a
> slow one that hits a resonance.

I believe that if you limit jerk, you won't be able to create the vibrations -- the tighter and 'faster' the zig-zag, jerk limits won't allow acceration to even approach the maximum --- overall force (and print speed) will be reduced. I'm not sure for the numbers I envision, this makes any difference -- I think when I was doing jerk limitations at the 50000 steps/sec^3, and 5000 steps/sec^2 acceleration limits, the acceleration ramps would .1 seconds each thru 8 steps. This jerk limit seems a little low to me though.


In ASCII art terms, if it does make a difference for the RepRap, here's an illustration why vibration could be significantly reduced:

Extreme 'zig-zag' motion, no jerk limits:
  
   
  ||||||
__|||||| _   (high frequency, high force/acceleration, high print speed)
   ||||||
   ||||||

Extreme 'zig-zag' motion, jerk limits:
   
__/\  /\  /\  ___  (lower frequency, lower force/acceleration, lower print speed)
    \/  \/  \/

In any case, I'm not going to try to limit jerk at this point because it gets a bit tricky running the math. I'll be happy with acceleration limited profiles for the time being -- I can always revisit limiting jerk later.
Re: Polar GCode compiler progress
April 10, 2010 11:35PM
I've made a little bit of progress adding limits to acceleration, and also somewhat to jerk, by simply brute forcing and iterating thru the steps, and warping time iteratively by adjusting delays at every step that exceeds at least one limit.

The algorithm is slow, and I don't think it generates optimal paths, but it is getting a lot closer to the goals I have. Here is a 30 iteration process to smooth of the original velocity limited graph I attached to the first post. With velocity limits only, it executes the curve in about 2.5 seconds (moving at 1000 steps per second -- obviously not a reasonable expectation). Once smoothed, it executes in about 12.5 seconds; both acceleration and jerk limits had a role in smoothing the motion.
Attachments:
open | download - Polar345GcodeSmootherPath.jpg (159.6 KB)
Sorry, only registered users may post in this forum.

Click here to login