Hello Guest it is October 15, 2019, 03:22:37 AM

### Author Topic: Tempest Planning - Preliminary information and testing  (Read 281559 times)

0 Members and 1 Guest are viewing this topic.

#### piv

• 91
##### Re: Tempest Planning - Preliminary information and testing
« Reply #110 on: February 04, 2010, 09:34:33 PM »
If I understand the planner correctly it plans the motion based on two segments, and it buffers about 2 seconds worth of motion to the plugin as 1ms points.  How does the 20 line look ahead affect things?

#### ART

• 1,698
• Tough as soggy paper.
##### Re: Tempest Planning - Preliminary information and testing
« Reply #111 on: February 04, 2010, 09:54:21 PM »
No You have it right. Its not the theory that wrong, its the practice. Hard to make an algorithm to do as I think you want.. you still need to
use every line.. so your problem comes in when current acceleration and velocity over the next 1ms takes you 10 lines ahead.. question is..what do you do with those
10 lines..ignore them? :-) , some do.. I take the position that no matter what, 1 waypoint must fall on every block.. that maintains as much accuracy as you can ask for,
but if you violate that rule, you can go very fast.. just not very accurately..

Art

#### ART

• 1,698
• Tough as soggy paper.
##### Re: Tempest Planning - Preliminary information and testing
« Reply #112 on: February 04, 2010, 10:02:47 PM »
Sorry, missed the second question..

>>If I understand the planner correctly it plans the motion based on two segments, and it buffers about 2 seconds worth of motion to the plugin as 1ms points.  How does the 20 line look ahead affect things

No, not really . Each and every move is added to the motion queue. everythign is calcuated on a 1ms pass in time. The planner is basically asked, given Im here..wher will I be in 1ms..

Then the planner looks to motion #1, if it woudl be completed in less than 1ms, it is run to completion and the next block in run as well for a 1ms increment. If it too runs out in 1ms, the next block is processed.. ect.. up to an arbitrary number .. 50 or so.. by then we should be 1ms further ahead..

Contraints are considered of coarse, over acceleration being the most important. Consider two motions from x = 0, g1x0.5 , g1x0 .. , this being worst case .. at speed this woudl produce acceleration that is infinite as it has to reverse. whiel g1x0.5,g1x1 woudl be fine to run simultaneously as they would add to a normal acceleration of  between the segment. But in the end, the planning is done by runnign simultaneously several blocks at once and adding them all up basically. LookAhead is just how many items are in the queue at once and so it limits the overplanning..

I suggest you look at EMC's planner, Mach3 is based on it, though heavily modified. Tempest is totally different so has different problems that the old planner.

Art

#### piv

• 91
##### Re: Tempest Planning - Preliminary information and testing
« Reply #113 on: February 04, 2010, 10:20:17 PM »
Art,

I just had a crazy thought.  Would it be possible to get (a test version) of Mach that has a special G code that just passes the 1ms waypoint values straight through to the plugin (DSPMC).  That way if the points are written at 1ms spacing then the whole trajectroy planning problem goes away.  Lets call it G5 as that looks available and some other controls use it for splines. Then the cam package or some other free standing G code interpreter can do the 1ms waypoint calculation.  An hour of motion is 3 600 000 lines and thats fine. Example is attached, basic format below.
G5   X0   Y0   Z0   B0   C0
X   0.000   Y   0.000   Z   0.000   B   0.000   C   0.000
X   0.010   Y   0.005   Z   0.000   B   0.000   C   0.000
X   0.030   Y   0.015   Z   0.000   B   0.000   C   0.000
X   0.060   Y   0.030   Z   0.000   B   0.000   C   0.000
X   0.100   Y   0.050   Z   0.000   B   0.000   C   0.000

#### piv

• 91
##### Re: Tempest Planning - Preliminary information and testing
« Reply #114 on: February 04, 2010, 10:33:51 PM »
Hi Art,
I think the problem comes from the 1ms waypoints having to be on the Gcode block coordinates.  That makes sense for tight corners but not for smooth contours.  The normal CAM G code is output pretty randomly, certainly not at hard 1ms intervals. I think on contours the planner should say ok the next 1ms point is on this segment, the next one ms point is past it, lets find where on the next segment the next 1ms point is and put it there. If you draw this out it actually has a smoothing effect (unless one of the 1ms points actually happened to be on the vertex or actual G code point, then its exactly right).  I am sure this is Ok because with proper look ahead any sharp corner with big angle will have slow motion right near it, meaning that even if the ms point is not on the vertex, then it will be very close.  It also means some segments might not have any 1ms points on them (say if G code segments are too short for actual feed rate) but that doesn't matter because the planner would have taken them into account when calculating velocity and acceleration, and if they were far off being in a straight line would have had to decelerate and then would be going slow so then the 1ms points would be near the G code vertex anyway.  It all becomes self correcting once you ditch the idea that a G code control point must have a 1ms interpolation point on it.  The reality is if the points are nearly in a straight line then there is no need to have 1ms points coinciding with G code, and if the points are not on a straight line, then the 1ms points will be close enough to them anyway.  CV ditches the idea of the path going through G code points anyway. Also the method Im trying to encourage will exact stop at endpoints and on sharp corners with no corner rounding, although segments almost aligned will have corners cut and migh even be skipped (if they are traversed in less than 1ms).

Clear as mud!

#### piv

• 91
##### Re: Tempest Planning - Preliminary information and testing
« Reply #115 on: February 04, 2010, 10:41:26 PM »
Hi Art,

Just to clarify, Im not saying to ditch CV or Tempest.  They work for lots of things but not close spaced high speed points.  If the type of planner is available as a configuration or G code or selectable in the G code then people have the option and the best outcome. Maybe call it HSM (High Speed Mach)

#### ART

• 1,698
• Tough as soggy paper.
##### Re: Tempest Planning - Preliminary information and testing
« Reply #116 on: February 05, 2010, 09:18:14 AM »
piv:

>>CV ditches the idea of the path going through G code points anyway.

Not really. The idea isnt that the planner has to touch waypoints, it has to touch a either the point or a spot between them. Thats usually the rule, it was reported
to me recently that thats the view of the EMC planner as well. Mach3 doesnt realy have that rule, it can skip over blocks to some extent but the effect is almost the same.

Ive actually tried a planner once as you suggest. Its effect is not what youd expect. Your right that it smooths.. way too much in fact. Consider a square 3" on a side.
Fairly common operation.. If I specify 1ms waypoints that dont have to "much touch line " rule,
what happens is that at low feedrate you get what looks like a square. The corners do tend to be rounded..as you increase the feerate, the square begins to look
like a circle, surprisingly it doesnt take much speed to get there. From the circle, it degenerates to a squiggly line that goes forward and then back..

Its argueable then ,that one could just set a feedrate and the feedrate itself would then determine accuracy. But accuracy would come at the expense of running
slower. Entirely true. What you find though when you try it is that the feedrate must be constrained pretty much to the point Mach3 contrains it in its current
planning methodology before signifigant detail is lost.

Yes, in some situations, like a flowing curve, it works out OK as the data is compliant with the way a servo corrects position anyway, and the output is fine, but in CNC thats a rare situation.I once made MAch3 run the Roadrunner example in such a way for example, normally it runs at something like 500mm/sec .. and I had it so I coudl make it run any speed. At the normal speed it looked like a roadrunner, from the time I got abotu 25% faster it started to look like a rooster and running full out it looked like a triangle. ( but took only 4 seconds to run.)

Its not easy to add such a thing as youve suggested, though it could be done.I havent the time to do it at this point, but Ill consider it in future so you can play with the numbers. Of course you could do that now. Write a program that takes a small block program and rewrites it as the distance along the path at 1ms intervals. Since each line is now longer Mach3 will run it much faster. What youll notice though
is it doesnt take much speed before the cut looks nothing like the input. If you do this, you can see the cut file immediatly upon loading it in mach3, I mean youd see exactly on the screen what such a file would cut like. It typically isnt pretty..

Art

#### BobWarfield

• 97
##### Re: Tempest Planning - Preliminary information and testing
« Reply #117 on: February 05, 2010, 12:17:02 PM »
This is a fascinating topic.  Art, thanks for telling us about the “guts”.

Acceleration seems to be “where it’s at” in terms of machine performance.  Consider this fascinating thread from PM, for example:

http://www.practicalmachinist.com/vb/cnc-machining/rapid-speed-test-193201/index2.html

Low correlation of elapsed time with rapids speeds, it was all about acceleration.

I hear what you’re saying about the detriments of acceleration on machines, their lifespans, and their accuracy.  But, perhaps this is something users should be able to tune more rather than just having the trajectory planner decide on our behalf.  After all, a big ole rickety gantry router might be light even it could accelerate fast but wind up killing itself while a heavy mill might take more acceleration just fine.

I note with interest from that PM thread that other controllers often have tuning parameters related to this.  For exmaple, the Brother’s have a reputation for being incredibly fast little machines.  They have a parameter referenced in this article for “table load”.  IF you’ve loaded up the table, you have to set it to run at lower accelerations.

Another kind of parameter would be allowable deviation.  This thread hints at things like “chordal deviation”:

http://www.practicalmachinist.com/vb/cnc-machining/feedrate-versus-true-position-190775/

When I simulate an arc with line segments in my graphics programming, I often allow a “chordal deviation” parameter.  Seems like some sort of “allowable error from perfect” parameter might be helpful for higher speeds.  This would go to your idea of how close the waypoints have to be to maintain some level of accuracy.  The Haas has a “max corner rounding” parameter as well that the poster on PM had set to 0.050”.  He is advised to set it to 0.0005 if he is unhappy with his accuracy.
In fact, they speak directly to that corner rounding parameter when changing direction sharoly.  G187 on these controls even let’s the g-code program change the tolerance.

You’ve also got things like a G61 “exact stop” available to consider.

My point  is, you can certainly make an increasingly sophisticated and better trajectory planner, but don’t ignore the ability of the user to provide you with some useful information too.  Certainly the other controls have taken advantage of that.

http://www.cnccookbook.com/CCGWizard.html

#### ART

• 1,698
• Tough as soggy paper.
##### Re: Tempest Planning - Preliminary information and testing
« Reply #118 on: February 05, 2010, 01:19:42 PM »
Hi:

Yes,planners can be facinating to work on, but incredibly complex when you take everything into account. The truth I suspect is there is no perfect planner for every situation. You need multiple ways of planning. By the way, Tempest sets an allowable devation, and as well allows the user to set Jerk, this matches it to any machine. The problem comes in with small block segmentation, just like in EMC and MAch3. Tempests trouble is math, its incredibly complex to use S-Curves in a planner, so its limited by how much it can compute on the fly as segments are added. Tempest is just a first test though.. to teach myslef the weaknesses of the process. That having been said it DOES cut very well in standard type code so Im heartened that a general solution exists. I keep it on a warm burner so I can play in that area as I get time.
I just today got a Windows timing subsystem working so I can actually run C++ routines in User mode at up to kernal speed. In theory this means I can now have a Real-Time version of Windows just like EMC runs real-time in Linux. Im considering rewriting the printer port driver as a normal mode C++ program routine. That means I could finally use floating point in the driver if time allows for it, which woudl mean greatly ehanced capability.   Its taken a long time to figure out just hopw to do that without Windows complaining. But today I had a C++ routine being called in Mach3 every 20us reliably and very stable. The possabilities are huge for what "could " be done now. I dont know of any inexpensive realtime extender for Windows that could be used similarly. Im psyched as this also means I could easily breakpoint into the actual workign section of the code which puts out steps and such.. It doesnt get better than that. (if it all works as I go.. :-)

Art

#### piv

• 91
##### Re: Tempest Planning - Preliminary information and testing
« Reply #119 on: February 05, 2010, 06:29:14 PM »
Well done on the real time for Windows.

I agree that high acceleration and ability of the machine to handle high jerk is the key to fast contouring.  But you also have to have an interpreter that lets the machine run at the limits of the machine physics.

From an end users point of view, one of the biggest problems is I try to do something and then a trajectory planner gets in the way and second gusesses what I am trying to do and changes it. If I can just pass 1ms points through to my DSPMC (orother plugin) then everything is in my control and my fault if it doesnt work.

That way the Gcode programmer (me, or anyone else) has exact control of the motion path and can put in whatever acceleration and S curve and jerk and 5 axis kinematics and machining on tilted planes he wants, all just by spacing the points appropriately. Yes the G code is a bit more complicated but what I envisage is a "pre interpreter" or macro or plugin that processes the first g code file that is written "normally" and turns it into a second g code program that has a 1ms spaced trajectory. That way what you will see on the preview in Mach when you load the second G code file is the actual waypoints.  I also imagine that this "pre interpreter" can be used to analyse exactly what the motion will be and give you an exact runtime before the program is run.  It also means really complex look ahead and motion planning happens off line and is not real time and removes the need to get the planning done in 1ms. This will make trajectory planning "open source" in a way that cant stuff up anything else in the CNC system.  If there are any problems, they have to be" in the G code". At the moment if i space points at 1ms, mach tries to do either CV and corner rounding or exact stop which wrecks the idea.  If I increase the acceleration in motor tuning parameters then jog, MDI and rapids trip.

Is it possible to get a G code function that passes points (already spaced at 1ms) straight through to the plugin (with no medling by mach)?