Machsupport Forum
Third party software and hardware support forums. => Tempest Trajectory Planner => Topic started by: ART on July 12, 2009, 11:34:04 PM
-
Hello All:
This board, when open to public use, will be used to allow members to discuss , test , and provide feedback on the "Tempest" planning system.
Snapshots, explainations, and test evaluations will be topics of this group to allow the development of the planner to proceed into testing phases
as the theoretical models and algorithms are being completed.
The Tempest planner is a proposal for the next generation of planning module. Its code is nearing completion and testing phases and builds
will be posted here for evaluation. Its specifications are as follows.
Tempest is a 9 axis, 5th order planner with optimised segment blending and velocity control. It uses 6th order blending between lines of any length,
and 3rd order blending between arc/line junctions. Orientation axis include a,b,c and u,v,w. In its end form it will allow task space or joint space control
and will include kinematic control extensions for a wide variety of configuration capabilities. It's planning order while set only by a jerk limitation factor, will
control both Jerk and snap through most of its trajectory with the exceptions of blends involving arc's. All blends ( or CV moves ) are set by the user
as a spherical tolerance where-in the blend will occur in an isoscelese triangle of the entrace and exit to the user defined sphere. This means a setting of
CV to 10mm will result in blending arcs of no more than 10mm at corners. Speeds are limited by the calculated acceleration constants involved with arc's
of various radii or in blends of various polynomial lengths. Arc involved blends are tangental matched for c2 continuity, joined with Hermite curves , while
line/line blends are joined with 6th order polynomial additions of 1st order linear equations.
It is hoped the Tempest model will eliminate the problems involved in the Quantum experimental SCurve generator, and Tempest will reach speeds
orders of magnitudes higher than Quantum in small segement control and concatenation. Algorithmic modeling is near completion and this board will
be opened as soon as the first preliminary test builds are available to achive motion for user feedback testing. I will use this board for posting notes and
explainations of various features and options as well as to document its usage and any limitatiosn found in testing. This is a highly experimental module,
and while the math and graphing functions show high promise, only true machine testing and time evaluations of CPU usage in the calculation of the
real time motion waypoints will tell us if this may yet be used by cpu's of today or if more optimisation is required to the central calculation routines.
So if your reading this, please feel free to download any test programs, and report any findings or opinions you may have. hopefully "Tempest" will
be the start of the next generation of CNC control. In theory, almost any machien will benifit from the incredibly smoothed motion and acceleration
control it offers.
Good luck, Thank you for testing.
Art
-
Preliminary tests:
Posted here are the first mixing tests of Tempest. The first photo shows a line from 0,0,0 to 50,0,0, this blends to an arc ending at 100,0,0 with radius 25, the motiosn then continues with a line to 50,0,0, and ends with a last line to 0,100,0.
The first photo shows the resultand blend in positions. These are blended with the CV set to 5mm.
The second photo shows the velocities involed. Red is the Y axis, Blue is the X axis, and the Green is the tool speed as the combined velocities of both X and Y.
The Third photo shows acceleration. Looking carefully, one can see the 3rd order blends from line to arc, and in the final segment, a 6th order blend from line to line.
Z axis was left out only for the sake of clarity but is fully functional as well.
Thx
Art
-
Hi, Art
Was wondering where you were hiding out.
Chip ;D
-
Hi All:
Enclosed with this post is a versionof the analysis program , I post it to further any discussions on the properties of such a planner.
As of now, all 9 axis are responding, and Id liek to post some diiscussion posts on tradeoffs of such planners and how they operate.
This encosed program will facilitate the user understanding the issues discussed as you can try various situtations yourselves.
Basically, you enter the x,y,z, and a coordinates of any motion group. You should note that the feedrate shown and selected is
in units/second, not units per minute. I defaulted it to 200 so thats ( 200 x 60 ) units per minute.. 12000 inches per minute. Very
high indeed, but using such high values allows one to better disect the operations of such a planner. Try the enclosed program and select
either velocity, acceleration, or position to see the various results of motions, feedrates, CV settings and how they affect accel and velocity.
Next postings will be on tradeoffs and singularity handling and how they may affect users of such a planner.
Thanks
Art
-
Hi Guys:
Now that a test program is released for visualising velocities ( see previous topic ), we can discuss
the limitations or tradeoff's involved in planning strategies.
When you run the tempest velocity analyser, youll see its preset for a square. Playing with CV , you can see the effect
( on the position screen) of various CV's and motions. Youll note how the velocity in the corners slows or speeds up
dependend on how much cv there is, and the angle of the next line.
First, lets talk about how Mach3, EMC and most other planners do their job. With the standard preset conditions, ( the square)
select accel and note how the acceleration looks with a jerk of 1000. This is probablky the smoothest of all planners in this example.
TO see how MAch3 or EMC woudl look, select a jerk limit of 100,000. Note the square waves, thats typical bang-bang acelleration.
The curvy parts are the only difference from Mach3's typical planning. They represent a complex blend and are unaffected by jerk selection.
Tradeoff #1. - Speed.
This example then shows Mach3 with better . more controllable CV blends. Note the time of the 4 moves. ( the last move to 0,0,0,0 is automatic.).
Its about 3.7 seconds. That woudl be close to Mach3's time to do this square. Now set to 1000 jerk and note the time. Youll see its now
7.4 seconds. SO we can see that SCurves take longer. This figures as it takes longer to drive somewhere if you dont hammer the gas pedal.
With a jerk of 1000, its about 40% longer. Set for 10,000, the time is now 3.94 seconds. Thats probably about where most woudl use such a planner.
Its about 7-10% longer. Thats Tradeoff #1, smoothness takes longer. On the other hand, the corners are better defined, and much more controllable.
Not bad for a 3% loss in iverall velocity. ( in this example anyway..).
Tradeoff #2 - Angular accuracy.
Change the second waypoint move ( set back jerk to 1000 for visual clarity ), so it has an A of 50. Notice how the A starts in the middle of the blend from
motion 1 to motion 2. This is because the rotary motion is commaned to match up with motion #2, but #2 is blended with #1. Orientation motion accuracy will depend
on a few things. In this case, the rotary motion WILL start as the motion #2 starts, ( in the middle of the blend) and end as motion #2 stops. However, for accuracy sake
the planner decided not to blend the next motion, but to stop and allow the rotary motion to catch up. The difference in speeds will produce a non-accuracy in the
lineup of the cartesion motion and the rotary motion. How much depends on speed, and time of motion. Changing to a 10,000 jerk will make it line up better.
In terms of accuracy, an Scurve planner will be slightly less acccurate, and speeds must be taken into account. This is a tradeoff. Speed, smoothness, and complexity combine to
make rotary motion more difficult, but better at not being disjointed. Foir example, you needednt consider slowing the feedrate request for such a motion, they automatically are
fit into the main cartesian motion. Now try changin the waypoint #2 move from 100,100,0,50 to 100, 5, 0, 50. In this case the rotary just cannot fit in the short time it takes to move from
100,0,0 to 100,5,0. Notice what happens, the line is no longer blended to the first, ther eis no time, so the motion is now dead accurate, and the A move will match the Y move to 5, but blending
is prohibbited during this move. Again, this is automatic and done because the math processor decided the motion is so complex that the solution is intractable mathmatically except to
simply do the motion by itself. This is tradeoff #2, the fact that you must consider such impossibel motions, and how they are handled. I call this a CNC singularity, and one should
understand how a planner handles such things. Only real-time experience will tell how how this impacts CNC cutting in a general sense. ( SO far, this is all entirely math based theory. )
Getting late, more later. This at least has given you something to play with and consider in terms of how a future planner may do its job. And hopefully, has increased your
understanding of motion math, velocity, jerk, acceleration, and rotary blending in moves.
Thanks,
Art
-
Hey Art,
I have a cheezy shoptask, ( a semi wobbly machine), I am willing to try it on, let me ask a stupid question, do I just drop this EXE in the mach directory of my current Mach3, and replace the existing mach3.exe? Or do I need some other special thing to set it up.
The shoptask has a "Lathe" on it too, so is this testable with lathe, or just mill?
scott
-
Should work on anything..
Art
-
Just a quick question. Will it be possible to set up Tempest to follow a path exactly, stopping on sharp corners and maintaining velocity on tangent moves? So if using G41/G42 on an outside profile, you'd get CV while maintaining 100% accuracy? Thanks.
-
As yet,no. ITs like mach3 in that its either cv or it isnt.. Though that doesnt sound hard to do..
Art
-
Repost.. Sorry, wrong file was attached to original..
Well, interesting results so far. I havent run many small segment files, but numbers so far look pretty good.
Im using a special version of Mach3 that has dual planner capability. One can select Tempest from the config/planner selection menu
and test various files in the two planners ( tempest and mach3's normal planner ) very easily.
Few notes,
.. config/select planner selects the current planner. If tempest is checked, your using tempest, if not, mach3's traditional planner.
Jerk and CV radius are the only other two entries. Jerk for most will be in the range of 1000 ( very shakey machine ) to 5000, very tight machine to perhaps
1,000,000 ( run close to mach3 levels of jerk allowance ).
CV is simply the maximum allowed radisl curve blend around corners..
Note:
1)DRO's for FRO are not working in this version.
2) do not use feedhold, its not yet written, you may only stop when using tempest.
3) No reverse or other fancy stuff, this is just a run time test of tempests motion
4) Do not transmit this program to anyone, its all just test code, its likely it will never be released into MAch3, but may appear in some other incarnation of controller.
this is simply my research and how its going.
I recommend trying a box a few inches on a side at various speeds, jerks and cv's to compare motion between the two planners.
Please report what you see in terms of motion, but again, dont expect all aspects of MAch3 to work.. ( though an amazing amount do..)
If you try very small segement code, let me know how it does..
Id prefer no open discussion of this planner, only those permitted on this topic, which I will add to as I wish someone to test it.
Thanks
Art
-
Art,
On axis 7,8,9 are they another rotary primarily axis that also rotate around x,y,z (with option on making them linear)?
What are you going to call them in G code will they have a primary letter, and then an "alias" letter as well, like the current 6 axis do?
scott
-
As attached in MAch3, you have no connection to the 7,8 or 9th axis.
They will be separated to U,V,W in the end. At the moment they are all
simply linear interpolations until such time as kinematics are added.
Preliminary tests show that Tempest is pretty smooth, does great blending , but
suffers from lower speeds than desired as the segment size gets smaller. Thats whats
currently being worked on, when and if I can speed it up to relative mach3 levels of speed
with small segement concatentation speeds, then Ill be investigating rotational kinemtaics
to make the A,B,C and the U,V,W axis as set rotation vecotr components to the cartesion axis
based on setting tranformational matrix'sfor each rotational axis.
Art
-
Well, Preliminary testing shows that version of the tempest test is very smooth, but slower than mach3 by too much in small segment code. THis is because with SCurve planners a lookahead strategy is necessary to see how much speed we can add up to in the stream of gcode.
This version is Quantum on steroids. It looks ahead and back and precompiles the speed capabilities. On my stress test, which Ill post as well, MAch3 takes 51 seconds on my setup, Tempest takes 56 seconds, not too bad a difference to respect physical motion laws and limit the jerking of the machine, not to mention make the CV blending more controllable by the user.
You only need to unzip this to a mach3 folder to test, and then select "config/set planner type" to turn on the tempest planner , you can swap back and forth between planners as long as your not currently running code. Setting higher Jerk limits will speed up the end result and a number like 12000 or so shoudl work for most of you, lower if your machine is crappy, higher if its a stout solid unit.
Id be interested in any observations.
Thx
Art
-
Hi:
Well, testing on that version shows a few errors in small segement code. This version test very well even in small segement code. I still havent done much
testing with Arcs in the code, but speed is very high with even very tight and small segement testing. This version seems so far to eliminate the errors of Quantum
and is now testing well on any file Ive tried. Work continues on FeedHold actions now to allow it to integrate into a full CNC program.
Thx
Art
-
Hi Art,
I have been away for quite some time but I am about to begin on a new project and I am trying to do some ketch up reading.
I am planning a cnc laser cutter. 100w co2 rf-pumped, yaskawa sigma 5 servos, I am leaning towards smooth-stepper or something else that Brian has on the back burner.
I am planning on flying optics, super rigid really light. But I have been concerned about cv with the laser. I would also like to be able to vary the laser power with velocity. My goal is REALLY smooth motion for a nice cut edge but I would also like to have decent speed.
Down the road I would also like to do raster engraving.
This is planned for sale and It is not just a hobby machine. I Think I am going to start ordering parts next week and begin the proto.
DO you see any advantages with this type of planner with laser?
chad
-
Chad:
Im not so sure the S-Curving will help if everything is rigid, but the blending may be helpfull.
This planneris very god at blending since you set the maximum radial blend. The blend radius is automatically
calculated on each segemnt with the user set value as the maximum amount.
You have to remember though that this planner is not projected to be used in Mach3, ( or in any program as yet ),
and is really just research on a next generation planner. It may well appear , or it may not depending on testing and
limitations found. Im pretty impressed by recent testing, but theres lots of testing to go before Ill know if this
method of planning is really suited to full cnc work. So far its impressive, but I havent run the hundreds of types
of files necessary to say its a very robust planning methodology.
Art
-
Hi All:
Ive opened this thread to public consumption as the testing has reached the viable stage. Latest testing shows a marked improvement in operation with a great reduction in
Jerk on our test systems. FeedHold is not operative in this version, so once you start a job, only a stop will kill it.
The switch to turn on or switch between Mach3's conventional planner and the new Tempest planner is in config/select planner , and all you really need to do is set the blend radius and the Jerk limitation for your system. If you find its too slow, increase the jerk limitation setting. The blend radius is simply the maximum bland radius, the actual radii will depend on segment length but the planner
will attemp to give you as good a CV as it can. Please post any files that seem to create trouble for you. Reverse run is not available either, and the feedrate selection DRO's will display stange numbers at atimes, but will not affect operation.
Comments are appreciated as to hwo things work.
The file name in this download is Mach3Tempest.exe, so to test you simply need to unzip this to the Mach3 folder, and run that program instead of the normal Mach3 executable. So this test will not affect your norm,al usage of the Mach3 program.
Thanks
Art
-
You mentioned kinematics!? Does that have anything to do with full 4-5 axis support possibly in the future?! BTW I really had a good laugh out of "Snap, Crackle, and Pop"...I went to engineering school and never even heard of those!!!
-
It may.. Theres still a lot of research I need to do , but my hope is to make the a,b,c,u,v,w axis work as kinematic translations of the commanded x,y,z target from the code. It woudl be a special mode
but thats a ways off, Im more concerned with simple 3 axis curving at this point.
Art
-
Hi Art,
I tried this file on the new planner, see what you think
Graham
-
Hi Graham:
Thx for the test file. The arc interpolation was wrong on a couple fronts. I suspect some helical trouble when joining helix's , but this version fixes the general arc trouble you had.
Art
-
I am probably testing the wrong sort of code. Short segment 3D vee carving. About 1200 lines.
Ordinary Mach, it runs in 13 seconds.
Tempest planner, the best I can get is 27 seconds and that is with jerk set to 1,000,000
Down around 20,000 it is snail pace.
S'pose this is not much interest to you. What sort of code is best to test?
Greg
-
Greg:
Actually, any type of code will do. Small segement 3d will be the hardest on it in reality. Im just fixing arcs and helix's, probably fix by tommorrow. In the meantime 3d code isnt bad,Id stay away from code with arcs in it till then. Raise the Jerk limit to 5000000 and see if it approaches mach3's speed. IF it runs OK, but a bit slower than Mach Id be happy.. the blending woudl still be effective. But for small segement 3d code, there isnt much way to remove jerk without slowing it down by jerk limitation. I guess its god's way of saying "3D code is jerky..no matter what."
thx
Art
-
Pushed it up to 5,000,000 and got it down to 24 seconds.
So I also pushed the acceleration up from 1200 to 2000 and now it is down to 20 seconds
Greg
-
Art,
Just tried it with my Emco F1. I put a round bar on the table to "monitor" the jerk. Played with the jerk number from 1 up to 100,000 and was jogging the table from side to side. There was no difference at all that I could tell of. Looked the same with any jerk value, as well as with the normal Mach3 mode.
I guess this information doesn't help you much.
Daniel
-
Daniel:
Select Config/Select planner to turn it on.. Jogging isnt differenet..only GCode...
Art
-
Hi Art
Attach is a file you could test which I get weird stuff happing try it see if it runs alrihkt on your machine if I do circles or arch the Z axis moves up and down when runing G code Thank you
-
Hi:
>>So I also pushed the acceleration up from 1200 to 2000 and now it is down to 20 seconds
It goes to show that the file , when proper physical limits are enforced on the blends has a 20 second time minimum. Mach3 does push the envelope quite a bit so Id expect longer file times on many file types.
Testing continues, good results so far other than the small bugs showing up.. :)
Art
-
Daniel:
Select Config/Select planner to turn it on.. Jogging isnt differenet..only GCode...
Art
Art,
I did select it, but I didn't realize that jogging wasn't different. I thought that the acceleration profile was changed ??? If so there should have been difference in the jogging as well...
Daniel
-
Hi Guys:
Sorry about that, it was indeed doing circles on arcs. Fixed in this version.
Art
-
Hi Art
First I am probable doing it wrough When I go to Config- Select planner type- and check mark use tempest planner that is when the problems show up and the machine dose do the circle instead of just the arch
-
Hi Guys:
Just to make sure you arent testing in the dark, I went to the shop and downloaded the 25-1 version and cut Grahams Boat hull program posted earlier.
It cut perfect.. ( REAL nice boat hull Graham..). I scaled it to .5 on all 3 axis to stress it some more by making it a shorter segment program. It cut very well,
so you should be OK to cut tests without too much worry, though Id suggest in the air first till your comfortable with that programs responce.
Ill try to post a photo of the cut piece later on. It turns out a very niuce smooth ( in this case spruce wood) sailboat hull.
Thx for the testing and the tap files. :)
Art
-
Hi Art,
this looks like an interesting project - you never could resist a challenge !
anyway, I tried it on my router;
first thing I did to check everything was still operational was to jog the x and z axes away from zero, then pressed GoTo Zero.
This caused squealing motors, but strangely the DROS showed X,Z at zero but the AAxis at approx 30, I tried it a couple more times with similar results, just different values of A....
regards,
Rab
CNC Toolkit - Free, Open-Source 5-axis CAM
http://www.cnc-toolkit.com/ (http://www.cnc-toolkit.com/)
-
Hi Art
Just tryed 25-1 it seems to work pretty good my Z axis just dose not work the way it should I don't know if it's the software or settings on the machine running the same g code switch back to ruagler Mach it runs alllright Thank you
-
Hi Art,
Very interested in this development being a past user and lover of Quantum. However, for serious work I have been using the regular Mach to great effect. Having just come across this thread I thought I would give it a try on some of the 3D stuff I do. Unfortunately it fell over on the first attempt. The download , installation and startup all went well and I selected the Tempest planner, loaded a file and tried to simulate it but it came up with an error on the 6th line. The error said "An invalid argument was encountered"
I changed back to the normal planner and everything was OK. I tried this on two computers and both reported the same error. I have attached the file.
Mike
-
Thx Mike:
Ill try it out and let you know what I find. I know theres still some bugs in there..
thxx
Art
-
Rab:
Thx for the test. Ill try some angular tests tomorrow as well.
Cant understand why the squealing.. seems to repond to goto zero fine here, but it may be something to do with angualr motion,
I hadnt done much with the other 6 axis as yet, though I did verify operation a few times..
Art
-
Hi Guys:
Thx for the testing and the files. Ive identified several bugs in the Z and arc/helix operations.
Also, I added Smoothstepper and other controllers to the output. Let me know how it goes,
all files submitted seem to cut fine..
Art
-
Hi Art,
Just downloaded the update and I still have the error "An invalid argument was encountered" on the seventh line of the Nose Cone file posted in post #34. These are the first 9 lines: The line in red is where the error is reported.
%(70MM NOSE CONE MOULD)
G90G40 G49
(DEFINE OPERATION : ROUGHING OPERATION)
T01 M06(6mm End Mill)
G0X69.991Y35.925
G17G3X69.991Z3.332Y35.925I-0.075J2.994F600.0
X69.991Z1.764Y35.925I-0.075J2.994
X69.991Z0.195Y35.925I-0.075J2.994
X69.705Z-0.6Y41.907I-0.075J2.994
Thanks,
Mike
-
Mike:
Interesting... I get no error there, runs fine. Can you send me your xml that your using?
Thx
Art
-
Hi Art,
XML is attached but maybe not needed. I did some more testing and the file does in fact run but will not simulate. The error only appears when I use the 'Simulate Program Run' button on the 'Toolpath' screen. I have not actually tried it on my machine yet but will report back as soon as I can get some time.
Thanks,
Mike
-
Mike:
Thx, that probably explains it. I havent done anything to support simulation. Tempest is tied into Mach3 because M3 is a great
test platform, but since its written a sa standalone planner, its really just tacked in there where I could. Some functions like
estimate and simulate may or may not work.
thx
Art
-
Hi Art,
Thanks for the response - I can now get on with some machine testing :)
Mike
-
Hi Art,
I have been trying to run the 'Nose Cone' program on my machine but the Z axis keeps faulting at line 6 - G17G3X69.991Z3.332Y35.925I-0.075J2.994F600.0 - I am only doing air cuts and zeroed all the axes before hitting 'Cycle Start'. The tool moves to position then faults when trying to move the Z axis. I have tried reducing the acceleration on Z but this has no effect, the axis still faults at the same line.
Let me know if there is any more information you need.
Mike
-
Hi Mike:
And this is on the 27 version? Ill start tracing for less jerk allowance. That line 6 is the maximum theoretical jerk point as it has to cv a hermitic curve between two full circles.
It does cause a slight aberation, but in my version 27 I got that aberation low enough that it wont trigger any jerk alarm on my system. Ill trace deeper.
Thx
Art
-
Hi Art,
Big apologies - I was still using v25. Just loaded v27 and it works just fine. A few questions if I may.
What effect does the blend radius value have on small segment code?
With a very small value in blend radius does it negate the use of Tempest?
Will blend radius have a detrimental effect on 90 degree corners cut in the YZ plane?
I notice you have a default value of 10 units for blend radius - is this determined through testing or is it just an arbitrary value?
Thanks,
Mike
-
Hi Mike:
Actually, I just cut the nose cone in a block of spruce, it cut very well, and turned out perfect.
As to the blend radius. Think of it as the worst-case deviation from the path you have set. In reality, it follows a
"Ruile of 1/8th" . That is to say if two lines are joined to gether, the blend will be at most the setting in the dialog,
say..10mm as default, but will always be a maximum of either 1/8th the length of the shortest of the two lines, or the
set amount. SO two 100mm motions will have 10mm raidus by default, a 100mm line entering a 60mm line woudl have
60 * .125 = 7.5mm as its blend. In micro segment code, this means the blends will be very small to make it all very accurate,
if two lines are .1mm each, then the blend between them will be .0125mm radius.
In this way the accuracy increses as the line segment sizes shrinks. As blends shrink the max speed though them shrinks as well,
but the physical limits are generally high, so it isnt generally noticable. SO basically, a 10mm or in inch mode perhaps .5" would be good for all
program types as loong as a .5" radius is not too much for you. Set it as low as you like, its only a maximum.
I was very pleased at the running of the nose-cone, seemed to work well. Vary your jerk setting till you like the smoothness offered, and you should
be able to leave it there, though it can be handy to raise Jerk limits for very tight code to allow for faster motion overall.
Art
-
Hi Art,
Thanks for the very informative reply - I think I am beginning to understand :)
I'm glad the nose cone cut OK. I have already cut some aluminium ones using the standard Mach and I am very tempted to cut another using Tempest. I think I will play a little longer with some settings first, before committing to the aluminium.
Do I understand correctly that the trajectory planner appears to be a module within Mach that can be changed easily as and when developments take place? Being able to switch from one to another would imply it is.
Mike
-
Mike:
Yes, the planner IS a module, BUT the current planner in Mach3 is a very speciallly modified planner module that is hooked in many spots in special ways to allow for things such as partial motions due to feedhold, and reverse run and such. It is not planned to make those same connections but to make the new planner mathmatically pure, that is to say it will follow a real-world physics engine of calculations based on accelerations, velocities and tangental acceleration calculations. This means it will likely never appear as Mach3's standard planner, though if it does work as well as I hope, it may be offered as an upgrade module for those that need or want it. Its in early days, but my vision is one that woudl allow for graphically identfying the configuration of a system and allow the kinematics to
control the 9 axis to produce in the end a 3D coordinate from all 9 axis. It woudl allow for proper robotic control, or perhaps hexapod type running from normal 3d GCode.
Its a very long way from here to there, but the first most important step is to get the accuracy and jerk reduction under control. After running the nose cone Id say Im happy with both at this point.
Ill watch further testing and move on to proper math pure and jerk free feedhold code, then it will be on to kinematics matrix configurations. Youll likely have test versions available for awhile till it is at least a match for all spec'ed capability. We'll see where testing takes us. :) . Each error last week fixed up important sections to the point that other than feedhold im pretty happy ( very happy actually)
with the run time performance, while it is slower then Mach3 dependant on jerk limitation set ( as one woudl expect) , it offers higher accuracy at high speeds through most types of code.
Art
-
Hi Art,
This is all very interesting stuff and I envy your ability to get your head around the maths and physics. It's this kind of 'pushing the boundaries' that keeps us alive.
Another question - does the lookahead setting have an effect on Tempest?
Mike
-
Mike:
Youd think it would.. and Ive run many tests but I dont see huge differences. I wouldnt bother going above 50 or so, since Tempest is really queued on the blend speed calculations, the added lookahead seems to have diminishing returns after about 50 lines even in small segement code. It REALLY beats quantum in that small segment code will go almost as fast as Mach3 in many instances.
Art
-
Thanks Art - I have attached another, interesting, small part file that has loads of small segment code in it. I'll be interested to know if you can work out what it is. The code for all these moulds is done using EdgeCam and I am lucky enough to have been sponsored by them to the tune of one complete seat.
Mike
-
Hi Art,
I just tried air cutting the 'New Hub' file and at about line 25, my machine started making some loud thumping noises. I could not work out which axis it was coming from. The settings I tried were; 1000 for jerk and 1 for blend. I also tried a blend of 10 but this made no difference. I then tried jerk at 10000, 20000 and 50000, with blend at 10, but all settings produced the thumping. There is no way I can cut the mould with the present version of tempest.
Mike
-
Mike:
Yup, just noticed that myself. Its the G2 arcs on line 26, change to G3 and its fine. Im tracking it down now as to where I screwed up on the G2's..
Art
-
Glad to be of assistance - good luck in tracking it down.
Mike
-
My bad...
G2's have a reversed normal..
Heres a fix..
Thx for that bug..
Art
-
Hi Art,
It just boggles the mind to see how quickly things get taken care of and fixed. I have no fear when it comes to anything mechanical and have always wanted to learn some programing but the time issue comes into play.
That said, will Tempest work with my DSPMC. I am game to try it out and see how it goes but would like to be sure it will even run before spending any time on it.
That is of course if my testing it out would be helpful in any way.
Mike
-
Mike:
I believe it will work fine, it should work as well as the smoothstepper as they share the motion interface. Cant guarentee it, but they should both work.
You dont need to do much to try tempest anyway, just download and unzip to mach3 folder, and run mach3tempestsep29.exe instead of mach3.exe..
Id love to hear if it actually works OK on the dsp...
Art
-
Thanks for the info,
I will let you know how it works out.
Mike
-
Hi Art,
My servos love Art Fennerty ;D ;D
I did some more air cutting of the 'New Hub' file and it seems to be working just great. I ran the file a number of times and recorded the time it took to reach line 400. The standard Mach with acceleration set at 400 (the very safe limit for my machine) took 2 minutes and 15 seconds. I then switched to Tempest with settings of 1 for blend radius and 10000 for jerk, keeping the acceleration at 400. This time it took 2 minutes and 40 seconds. I then changed the motor acceleration to 1000, a setting that would continually trip the standard Mach. I was surprised that it only shaved 1 second off the time. I then tries acceleration at 2000 and 5000 and again the timing was pretty constant at 2 minutes 39 secs.
I then tried setting the acceleration on all axes to a paltry 50 just to get an idea of what was happening. This time it took 3 minutes and 16 seconds.
My conclusion seems to be that although Tempest will allow massive increases in acceleration, as did Quantum, there is a practical limit. I do not know if results would be any different with files without so much small segment code as the 'New Hub' has.
The major difference is how the machine sounds - it just purrs along even at high accelerations - my servos just love it. I am sure this will have a dramatic effect on servo life.
Most impressed,
Mike
-
Mike:
Thanks, great report.
The reason the time doesnt shave when you raise acceleration ( much anyway) is the Jerk Limit itself. No matter what acceleration you enter, the Jerk Limit will
stop the system from accelerating beyond a certain set point of Jerk. Raising Jerk to 100,000 would shave more time off.
As a comparison, on such a file, Mach3 would have many points at which Jerk woudl be well over 1 million units/sec^3 ..
So if you like, raise your accel, and raise the jerk limit a bit. The trouble is that the Jog is still linear, so you have to keep the accel down low enough your Jog works
well, and that will set the limit of the accel you can use. After that just experiment to find a good Jerk setting.
Sounds like your system is working as well as mine. Thanks for the bugs AND this report. Im pretty pleased with Tempest's performance. It really makes Quantum look bad. :)
Art
-
As a comparison, on such a file, Mach3 would have many points at which Jerk woudl be well over 1 million units/sec^3 ..
That's a staggering number - now I feel for those poor ballscrews and nuts as well as the servos :o
As this is such an improvement over the standard Mach, is there no way we can put pressure on Brian to incorporate it? I know you said it is early days and that maybe it could be released as an upgrade, much later, but with such a significant improvement, in terms of machine longevity, it seems crazy not to do it sooner. Development can still continue on the planner but there would be hundreds of machines out there purring your name - brilliant!!
Thanks again for all your efforts,
Mike
-
I ran a decorative 2D part the other day, and had to play with feedrates to get the detail I needed in a few places. Had to slow it down to 30ipm in a few spots, when the majority ran at 125ipm. Did a dry run with tempest at 150ipm and seems to do exactly what i want. Had a setting of .03. Basically get CV on tangent lines and arcs, and exact stop on corners. I'll do some more playing later with an even lower tolerance, but it looks really good.
I'm assuming the jog issue is just due to this being a test, correct? I can't really raise my accel on my stepper machine, as it'll stall when jogging.
-
Jogging is actually a hardware function of any of the devices.. In Printer port, the driver does it. In Smoothstepper or DspMC the devices do it.
All Mach3 does is send a jogon or jogoff command. SO I cant really attach Jog as it stands. Not tillmuch later if I attempt it at all.
As to going in Mach3, theres still a long way to go and it wont attach properly in all aspects, so you wont see it as a release in Mach3.. at leats not in the near future.
I will keep a tempest verison going though, so those that wish to use it can if they wish. Unfortunately, that means your stuck with this version of .028 until such time as testing is complete.
Good results so far though, Im pretty pleased.
Thx
Art
-
>>get CV on tangent lines and arcs, and exact stop on corners.
Thats a good point. If you set the CV blend down low.. .03 or so.. then the CV WILL only affect tangent lines and such. What happens is for each blend Tempest calculates how fast the system can progress though the blend, since .03 is too sharp at 90 degrees, it will slow way down..so very little cv, but in tangental motions, the small blend can be done at high speeds..so you get selective CV based on tengental nature of that connection. Tempest is pretty smart at doing that.
Thx
Art
-
As major bugs seem to be recovered, I am about to test this TempestPlanner. Tomorrow I give it a shot. At least we will see how it works with SS.
Today I was playing with 2D code, having both long and short segment parts.
It is done as engraving, I need to engrave both sharp corners for rectangles, and smooth curves for curved shapes.
CV OFF: Nice sharp edges, but at some parts the machine was bouncing. Result: Engraved rectangles are nice, but the curved shapes have wavy edges.
CV ON: Curved shapes have nicely connected edges, but the rectangles are rounded way too much.
At this point I examined what I could do with CV settings, and I realized, that there is no good solution, and I wanted to ask if there is a setting that might set blending in the function of joining segment length, and I just realized that Art was describing this in this Tempest thread at reply #46...
So I am really waiting for the moment to see what the result will be with tempest.
I already made some photos of CV ON and CV OFF problems, so I attach pictures. Green arrow OK, Red arrow NOK... (Shall I see the same differences on the toolpath display, too?)
-
Hi:
I assume the tests you were running were in normal Mach3?
>>Today I was playing with 2D code, having both long and short segment parts.
>>It is done as engraving, I need to engrave both sharp corners for rectangles, and smooth curves for curved shapes.
>>CV OFF: Nice sharp edges, but at some parts the machine was bouncing. Result: Engraved rectangles are nice, but the curved shapes have wavy edges.
If CV is off, AND your machine is bouncing, this is a sign of too high an acceleration setting for your machine. Its not stiff enough to do that kind of acceleration using a linear planner.
In Tempest, you may leave the acceleration setting alone, but youll want to find a setting of JERK that allows you to do the code with CV off that doesnt jerk. Thats the whole point
of tempest. Once you know that your 2d code with CV off doesnt jerk your machine about, then turn on CV..
>>>CV ON: Curved shapes have nicely connected edges, but the rectangles are rounded way too much.
Set a fairly low Blend radius. You say the rectangles are rounded too much, so set a blend radius your willing to live with.
If your table is set to cut without Jerking.. and Tempest will let you set that up.. then your CV will please you under all circumstances..or should.
Since the blends automatically shrink with the line length, you shouldnt see any blends that other you, certainly not in the micro code your running anyway.
This is the benefit of being mathmatically pure.. and why Im trying to keep it that way.
thx
Art
Let us know how it works, Id love to see the same photos under tempest as a comparison.
-
Hi:
On extra note.. You asked about toolpath display, Blending and CV changes to the output are never shown under the toolpath, they cannot be except as runtime information ( the green dots or line), this is because neither Mach3's traditional planner nor even Tempest really knows whats going to go out till it does. Its a very complex thing to calculate as it all depends on speeds,
blends and conditins at time of cut. Ive seen many errors reported as CV errors that aren't, they are a weak machine bending as it cuts due to acceleration forces , both motor acceleration
and tangental acceleration, Tempest however, knows abotu tangental acceleration and takes it into account, but a weak machien may bend more than you think.. setting low Jerk limit numbers
will stop the bending.. just a quetion of how much that slows you down really..
Thx
Art
-
Hi,
Just done a number of test runs to satisfy myself how Tempest is working on my machine. I did an air cut of the full 'New Hub' file and noted the times. I did this six times with a few different settings. here are the results:
Standard Mach as the benchmark; Acceleration 400 (optimum for my machine) time to cut = 25 minutes
Tempest 1 Acceleration 1000; Blend 1; Jerk 10000 time to cut = 44 minutes
Tempest 2 Acceleration 1000; blend 1; Jerk 25000 time to cut = 39 minutes
Tempest 3 Acceleration 1000; Blend 1; Jerk 50000 time to cut = 35 minutes
Tempest 4 Acceleration 750 (Safe to use jog at this setting) Blend 0.1; Jerk 25000 time to cut = 39 minutes
Tempest 5 Acceleration 750; Blend 0.01; Jerk 25000 time to cut = 39 minutes
The conclusion seems to be that the jerk setting has far more influence on the time taken to cut than the blend setting. There was not a big change in time between 25000 and 50000 yet the machine did not run quite as smoothly at 50000. As Art said earlier, the higher the jerk setting, the closer it resembles standard Mach. I did try a cut at a jerk of 1000 but stopped the run after a few lines of code as it was apparent it would take a long time. On my machine, 25000 for jerk seems about right.
I haven't quite got the hang of 'Blend' just yet but from what I can gather, it has very little effect on small segment code. What I would like to know is whether a value of zero can be used and if so, does this represent a 'virtual' exact stop setting but with jerk still operative i.e. there is still effective 'S' curve acceleration? Very small values of blend seems to suggest this but can there be zero blend for maximum accuracy?
What was abundantly clear was that my machine sounded much happier, and although there is a 50% increase in time, it is time I am quite happy to sacrifice for the improvement in operation - I am lucky enough to not have to use the machine for income :)
Mike
-
So as I tested, Tempest Runs well with SS, too :)
Attached pictures:
1. CV ON (Standard MACH planner, fast machining, smooth curve, but too much rounding at edges)
2. * CV ON With tempest (Tempest Planner curves are smooth, edges are nice, machining is somewhat slower of course due to Jerk limitation)
3. CV OFF with angles >45deg (Standard planner, just setting for CV angle is different, same result as above, with faster run, and a bit more hickup at direction changes)
* this has the nicest cut IMHO
Unexpected event:
WHen I played with jerk settings I experienced no bugs, but one part was damaged during the following process:
I started to cut a part, but I forgot the feedrate override at 5%, so after 10 seconds, I pressed reset for the FRO, and suddenly one of the axes wanted to go crazily fast, and it lost all of its steps... I have don this without tepmest before many times, but had not seen this happening... whatever.
Acceleration:
Before tempest, I had acc. settings at 250 for all axes. I tested max acc. for X and Y axes, it started to be unstable at 2000. at 1500 I could not make the machine loose any steps. (max vel currently is 200mm/sec with 0,0005mm microstep increment)
Jerk values:
The standard 5000 Jerk value brings noticable results, I made 2 tests: running with max. speed a 4x4 rectangle, and a 40x40 rectangle.
without tempest, the machine is fast, but jumps, with tepmest, based on jerk value it goes smoot enough below 10000 (machine is more or less solid, but the desk it stays on is far from that, so with a better base, a 20000 jerk value would be OK for its mechanics I suppose.)
Setting a jerk value of 200 makes the movements tender even on the floppy legs, but for small distances it is way too slow, I suppose such low jerk is applicable on machines with larger workspaces than mine.
Some questions:
WHen I use CV together with tempest, will tempest blend setting override CV settings? or how it is going to work?
Comment:
For the moment I decided to cut parts without tempest, but in the end it would be nice to have it always active, to protect the spindles. (I have another machine, solid as a rock, it can run at high accel. rates with 2kW servos, but that bang-bang is not good for the ballscrews)
Jerk on the small machine means it jumps, the large one "only" knocks... but I am more afraid of those knocks, if you know physics, you can guess why...
So the more Tempest is adopted to MACH, the happier I will be :)
About toolpath display:
I understand it has to calculate first to know the exact blends, accelerations, etc... but theoretically it should be possible that MACH "preprocesses" the Gcode file, and then it can draw what actually will be output for step pulses...
Of course if it is not written that way, it might be hard to reconfigure for this "simulation" mode...
I would see an advantage of it to know how much my real feed speed would deviate from my commanded feed... Benefit would be better chip load control.
e.g. I command F600 and I calculate that spindle should run at 10000 for proper chip load, but if there is a section where MACH can run at F100 only, then it will run at that low speed, but it won't touch spindle speed. with some materials it would lead to no chip formation, but friction only...
But this is another story I suppose, however, I would like to have some opinions about it :)
Or what I described above could be handled with software as MasterCam for instance? I have not that deep knowledge, but CAM software is aware of physical limitations of the machine tool, then it should be able to correct for those values...
-
Hi:
Thx for the pics.
I have to agree , photo #2 is the best cut. Even the verticals to the left look much better.
>>Unexpected event:WHen I played with jerk setting
Yes, Feedhold ans reset can act funny. Its what I meant when I said its not fully attached..
>>Some questions:
>>WHen I use CV together with tempest, will tempest blend setting override CV settings? or how it is going to work?
When CV is on, the blend radisu is used, when off it is zero. Same as exact stop but with Jerk limitation. Dont use zero.. Ill make it kill zero's in future.
The comments are pretty much bang on, Jerk will control the end time more than blend, specially in microsegment code. Blend will have a higher effect in longer segment code.
MicroCode is the hardest of all code to do high order planning with. The fact you get 25minutes vs 35 minutes doesnt surprise me at all, lesser differences woudl be seen in larger segment code.
Im pretty happy with results as posted so far. It allows me to digest and evealuate if indeed Tempest is worthwhile for people to have some day. Many will say its only for special circumstances, but since
Tempest can up the speed quite a bit and eliminate the knocks and jerks, Im thinking it has value for a larger number of peopel than I woudl have orignally though..
Thx
Testing continues.
Art
-
From the one test I did, it would seem to have a huge impact on regular 2.5D routing at high speeds, by eliminating the corner rounding.
-
Mike:
I believe it will work fine, it should work as well as the smoothstepper as they share the motion interface. Cant guarentee it, but they should both work.
You dont need to do much to try tempest anyway, just download and unzip to mach3 folder, and run mach3tempestsep29.exe instead of mach3.exe..
Id love to hear if it actually works OK on the dsp...
Art
Hi Art.
A couple of things,
1. I must pay attention to what Art actually types, it makes it go much easier.
2. When cutting large files like the sailboat hull, remember to have your license file in place. When I put the new computer in place, I forgot it. I was wondering why it kept stopping in the middle of the program.
3. It works with my DSPMC/IP and is working well. I am using version 028 with the 051 firmware and the matching plug in.
4. There is a very noticeable difference between Tempest and the traditional Mach 3 trajectory planner. The floor that the mill is on is not perfectly flat (I know, I know) and the machine when running the boat file would just shake and dance on the floor. With Tempest, the machine stays much more steady. I then jacked up the velocity to a point where it would cause servo encoder limit faults and to verify I ran it in Mach3 and sure enough it would fault out. Most likely because the accel was so bang bang it couldn't keep up.
I am now running tempest with the same setting and the machine is just as smooth as can be. I will cut some more air before I actually try a cut but so far so good.
5. Since I have the machine setup to run Keygrabber it doesn't work with tempest the way it is setup and since the velocity is set so high I can't jog anyway, I am not going to worry about it right now.
6. 6000 mm/min is 233 ipm, a lot faster than the machine normally cuts but it is going well at this time.
Keep up the good work.
7.It must be tough being retired and putting out something like this.
Mike
-
Hi Mike:
Thx for the report, its nice to hear.
Actually though, I suspect retirement is necessary to do this..lol ..
The code took a long time, and you had to go on faith that it woudl make a difference as I couldnt actually move a motor till now.
It does seem much smoother though..
Anyway. Ill let people test for a couepl months before I continue on it, Ill work on lathe code till then while this project steeps a bit.
Though if problems develop Ill fix each reported error till we know what we have so far is bulletproofed..
Thx
Art
-
Please don't work on the lathe code, I won't have any more excuses for not finishing the lathe!!!!!!!!!
I will try to work Tempest into the rotation as I do more machining over the next few weeks.
Updates as needed.
Mike
-
Theres ALWAYS an excuse.!! :D
Art
-
Art, has the Mach driver changed since 2.42? I have a Tormach mill, and tried using Tempest with that version (Tormach's current version)--I got a brief error message saying something about version <3.00, machine wouldn't move, and I had to uninstall and reinstall the software (including driver).
I'm prepared to install 3.042.029 and migrate the Tormach profile over if that's what it takes to test-drive Tempest. It sounds too promising, from reading this thread! :)
Thanks,
Randy
-
Hi Randy:
Yes, its likely the driver has changed. Here's a post of the driver required if you wish to test Tempest.
Just rename your mach3.sys in the mach3 folder to .old , then copy this one in. Remove the driver from the control panel
device manager, and then run drivertest.exe and it will install this one. Name th eold one back to .sys after deleting this one,
and repeat the proceedure to go back to you current Tormach version.
Take note, this is only required to test Tempest if your using a version older than 1.26 or so, or a special build like Tormachs.
Good luck, Id love to hear how it runs on the Tormach.
Art
-
Art, thank you for the speedy reply, and the driver and instructions. I'm running a 2.5D job right now (toolpaths carefully filleted so all is tangent :)) but I will be able to test Tempest before the weekend on a small contouring job I ran last week, and thus is fresh in my memory. I'll report my results then or early in the week.
Randy
-
Art, I ended up installing 3.042.029 and importing my Tormach XML file and screenset and macros. (It looks like the only problem with the "Tempest" Mach3.exe is that the pulse width somehow changed from 5 to 2 without me noticing it in my troubleshooting, but I've done some playing and can go back and forth between the Tormach release and 3.042.029 with just a parallel port driver uninstall and reinstall and a couple of reboots in between...
Anyway, it might be a while before I test Tempest. The CV performance of 3.042.029 is a night-and-day change itself from Tormach's 2.42 version. I am going to need to play with that for a few days to get a decent baseline from which to test Tempest. Wow! So far, I've just been "air cutting" but will put endmill to acrylic in the morning.
Randy
-
Randy:
Np problem. Have fun.
Art
-
Hi Art,
I used Tempest to great effect cutting the 'New Hub' file in aluminium, the finish was great despite it taking nearly twice as long but as I said earlier, for me time is not a major issue. However, I am about to cut a couple of temporary wing moulds from MDF and have attached one of the files here. When I use Tempest, the roughing cut, from the start to line 7398 cuts rather hesitantly. The accelerations are smooth but there is a massive difference in speed throughout the cut and the machine seems to almost stop at times. When compared to standard Mach, there is no comparison, standard Mach machines this far better. When it comes to the 'Parallel Lace' operation, line 9814, the reverse is true and Tempest performs far better than standard Mach.
I am using settings of 1 for smoothing and 25000 for jerk. The cutting speeds seem high but I am only taking small cuts from MDF.
Mike
-
Hi Mike:
Seems to run here OK..though I only ran to line 700 or so.. Averages about 2450 on the feedrate. I have mine set to 20 line lookahead, 1cv and 25000 jerk. Is thi sthe latest verison?
Art
-
Hi Art,
Yes, it is the latest version. I am finding that the machine slows down dramatically when it encounters the sharper corners and velocity drops to just over 300 compared with the 2500 demanded. I do not notice anywhere near the same effects when using the standard Mach where the speed fluctuations are only down to about 2000 when going round the tighter curves. Speed is certainly maintained when travelling along the very large radius curves, even though they are made up of fairly small segments, but speed drops dramatically round the sharp curves.
I have just run the file again to verify my findings and noticed the same performance running to just line 700. My lookahead was set at 10 and changing it to 20 made no difference.
I will try to make a short video tomorrow as that may give a better idea than words :) It may be that I am expecting too much.
Mike
-
Mike:
If its just sharp corners, then you mnay simply be fighting physics. When you specify a Jerk of 25000, youll telling it
to slow on corners to exactly 25000 units/sec^3 of jerk. So thats the speed. Raise your jerk limit to 100,000 and see
if it goes faster.
Art
-
I just found out about Tempest Planning this week. I have been playing around with it some. I have a large router with a fairly heavy gantry I like what I'm seeing so far. It seams to handle 2d type stuff really well and is very smooth.
I tried a 3d file (just air cutting) I wasn't really expecting it to run that well and .. it didnt'. It ran but was not as smooth for me as the regular mach planner is. On 2d stuff for a large heavy gantry though I am really impressed!
I have noticed sometimes at the start of a file I will get a "thunk" and my drives fault. Not sure what it is. Just thought I would pass that along.
Jeff T.
www.3dcarvestuiod.com (http://www.3dcarvestuiod.com)
-
Jeff:
Depending on the 3d file you may need to up the lookahead to 50 or so, and perhaps raise the jerk quite a bit.
Art
-
you read my mind. very nice update. can i use it normaly? nobody again me? ok. thanks :) how can i help you?
-
Art,
I have played some more with the 3d files. I had the look ahead already set to 200.
For my machine it works better to not use tempest planning for 3d files. Regular 2d files tempest works awesome.
I'm not sure if it is because my z axis is pretty fast with good acceleration and when doing 3d files the x or y axis
is pretty much just moving a steady speed. With tempest it definatly slows down the x or y axis and does not
appear as smooth.
It would be nice if Feed Hold and Feed Rate Overide worked ... hint hint :)
Jeff T.
www.3dcarvestudio.com (http://www.3dcarvestudio.com)
-
Ive been testing out Mach3 with a linear motor, DSPMC and short segment G code. Ive not tried Tempest yet but have read most of this thread. Ive got a few ideas for a high speed trajectory planner for servo systems. Basically is it possible to have a really simplified trajectory planner that can process about 1000 blocks per second? This is for ridgid machines with servos. I have a good idea of the what it should do and how it might work. Is it possible to get it tried out somehow? Or do I have to learn Linux and EMC to test it, which I would rather not, and anyway that would not be suitable for the Windows world in which we live. Not sure if this should be discussed here or in the DSPMC thread. It seems Mach has a lot of (trajectory) overhead to cope with stepper systems.
-
piv:
Its a very complex topic. Overhead really isnt that high , the problem of short section code is a well known on by almost all planners. Rules on angular deviation
and smoothing are variable between them and they all aim for a faster path, the question is always what do you wish to give up as its always a tradeoff. Detail your idea and Ill tell
you why it failed in testing when I attempted it. (Ive attempted a LOT of ways..) lol ..
Art
-
Hi Art:
First of all thanks for sorting out a great package. Im really impressed with how easy it is to set up and how well it works. What I am trying to do is possibly a bit higher end than what it was originally intended for, but it is almost there so I thought I would give it a go. Im on demo version at the moment but will change over to licensed soon I think. Only limited testing with 500 lines of code. What should run in 0.5 sec is taking about 3 to 4 seconds. Im an OEM/system integrator and this will go on more than one machine if it works out. FYI the end application is Foundry patterns from wood and foam. Upgrade to existing machines and for new machines.
Ive got my DSPMC hooked up to a linear motor and Mach3. It all looks pretty good. Ive run a few tests and it looks like Mach3 will process about 170 blocks per sec in CV mode with 50 to 200 lines of look ahead on my 3 year old single core 1.6GHz laptop. The good thing is it doesnt get "data starvation", it just slows the feedrate down so it feeds smoothly at whatever speed it can read the file at. Some other controllers just feed fast and then come to a dead stop when they run out of data and then go jerky jerky as they then read the code one line at a time (even if it is at 250 or 1000 blocks per sec), until they get to a slow part of the program and the look ahead can catch up again. So yes it is OK if the CAM output is good, but its not real good for working with bad CAM files at high speed.
Heres my 2c worth on how it might be made better for a servo system. Sounds like you might have already tried it, so lets find out! Basically simplify the trajectroy planner so it does less work and can process every block faster. If the overhead isnt in the trajectory planner, then simplify whatever else is slowing things down (eg "graphics mode off", or "feed overide off" or whatever it takes). Dont worry too much about the acceleration or jerk and corner blending, the servo tuning will look after that to a certain extent. Use the corner angle to decide if it should go to exact stop or stay in continuous feed. Only do linear interpolation on the segments with no corner blending. Check the accelerations (average acceleration as dumb as (Vfinal-Vstart)/period over a period (of say 10ms) and alter the feed rate if the average acceleration is above a certain value. Of course this method would be useless for stepper systems. But what I am talking about here is fast servo systems. Most servos have a time constant of at least 1 to 10ms so there is no point in getting too fussed about things in a shorter time frame. The problem is that its real hard with CAM systems and their lazy operators to get them to put out sensible code and the easiest way is to process the blocks fast.
In the ideal world Mach3 would feed the required axis accelerations into the DSPMC and then the DSPMC could use that as feed forward in its control. If it did this, it would be truly first class. But I guess I am dreaming.
Another idea I have had is to re process the G code file before it goes to the CNC controller and have it output position in 1ms increments, preferably with a feed value and an acceleration value at each point. Then the CNC doesnt have to do any real time trajectory planning, it basically just hands over the programmed points to whatever is doing the PID/servo control and that PID control has the input it needs to do proper feed forward. In this kind of high speed application there is no need to have real time feedrate overide. If the feed rate is wrong, the operator will never have time to correct it anyway.
I havent tried Tempest yet as I think (wild guess?) the issues are related to the complexity of the trajectory planning slowing things down. Or should I try it?
Is there any way at all to get the block processing speed up to around 1000 blocks per sec? It can be done, I have used one controller that runs at up to 10 000 blocks per second with full kinematics and everything going. But the cost is fairly high and it has other issues. Seems like everything has one issue or another.
Regardless of whether this high speed stuff works out, I will be putting Mach3 on a few flat bed routers that need a controller upgrade.
-
Art:
By the way, the CV mode is OK except for the block processing speed.
Regards
Mark
-
>>Another idea I have had is to re process the G code file before it goes to the CNC controller and have it output position in 1ms increments, preferably with a feed value and an acceleration value at each point. Then the CNC doesnt have
Actually, it kinda works that way now. The dspmc uses ( as all plugins) a 1ms trajectory point information stream. The only reason more blocks arent processed is that the buffer is kept 2048 entries long, and the 1ms incrments makes that 2 seconds worth of motion, processing more woudl be useless. It isnt the blocks per second, that is totally unimportant, the thing is how many blocks vs how much distance. The issue is one of the 1ms between blocks. This is calcuated based on the rules of motion in terms of accel and dece, distance and CV..
The problem being the small block sizes and the calcuated decel and accel between them, while it seems intuitive, once you start to program for it you find the mathmatics near impossible, whats necessary in most instances may not be necessary in all..ect..The type of job, the distance per move and all the rest need to be generalised or else youll get intermittant areas of fault that will even trip out a servo..depending on servo speed and capability. SO while it woudl be possibel to ignore many paramters to make a particular servo system work, it woudl work only for that system, and even then probably not in all circumstances.. and that woudl be very bad for reliable cutting.
Lookahead plays an importantpart, different in tempest as opposed to mach3, but lookahead is how it figures the max speed for a motion, it isnt enough in small block code to make the decision just on this move and the next, you need to know several moves ahead..so lookahead does that. Again, it needs to be general in nature..specifics is a nightmare and would only work on the target machine..
Ive tried a great many such methods and they usually turn out very badly..
:0
Art
-
Hi Art,
Yes I have come up against trajectory planners that almost work in most situations but then give me grief. Like I said, CV mode is good. How can I get it to handle blocks 1mm apart at 60m/min (contour cutting foam), or about 1ms travel time per block?
The best result I have had is from a controller I set up that can read spline input. I wrote a bit of software that does the tool offsets and makes a G code program (kind of a dumb CAM system) that takes a mesh as a 3D DXF file and then generates widely spaced points that lie on the spline. The motion is beautiful and the contours smooth, it shapes surfboards, a cut across the deck of the surfboard in five axis mode only has about 10 or 20 control points over 300mm. It runs at about 30m/min. But the problem is its not a general solution. I have tried to set up UG NX with spline output and it kind of works. But it took a lot of head banging with the guy writing the post to cover most of the situations and even now its not "production" ready for every possibility.
Your approach to tempest and normal CV is very good I think. Could it be made to preprocess the data to make the 1ms point stream so that it can run at full speed at run time with short segments. The only issue I see at the moment is that Mach for me is only processing about 170 blocks per second, which means if the stupid CAM system is putting out blocks at spacing closer than 5.88mm (60m/min = 1000mm/sec. 1000/170 = 5.88mm at 170 blocks per sec), even if the curve is very slight and the physics says it doesn't need much acceleration, then the motion will slow down because the G code isnt being read fast enough.
Here is another example. Running aluminium with a three flute cutter at 24000 rpm and 0.1mmpt chip load, feed is 24000*0.1*3=7200mm/min = 0.12m/sec = 122mm/sec. On a machine that can have 1g acceleration, at a feed rate of 7.2m/min, it should be able to go around a radius of R = (v^2)/a = 0.12^2 / 10 = 0.00144m = 1.44mm at full speed. So any smooth contour with a local radius greater than 1.44mm should be traversed at full speed. At 122mm/sec, and 170 blocks per sec, the point spacing has to be 122/170 = 0.7mm or greater, which will not properly define any curve of say less than 10mm radius. But at 1000 blocks per sec the spacing is 122/1000 = 0.12mm. which will nicely define even the 1.44mm radius that can be traversed at full speed.
Have you got an old planner that didnt work on steppers but might work on highly dynamic servos?
-
Hi Art,
I just wanted to clarify, I understand DSPMC takes points on 1ms interval.
CAM package puts out closely spaced points at say 1mm spacing so to feed at 30m/min needs G code blocks to be processed at 500 blocks per second. Mach3 should turn this into a point stream at 1ms interval or about 0.5mm spacing if its a straightish path. But it doesnt, it reads G code at 170 blocks per second and so travels 170mm per second at a feed rate of about 10m/min and DSPMC point stream spacing of 0.17mm instead of 0.5mm.
Ive been testing points on a straight line, so physics shouldnt come into it (except at the ends where it has to start or stop).
My wish is to somehow get Mach to do it at full speed. Do I just need a computer 3 times faster? I am willing to help out with this.
-
Piv:
I do understand what you face.The problem you describe is really caused by the way Mach3 ( and emc) compute the path capability.
Its really a generalization problem. Ill see if I can explain, though its a hard one to fully explain.
Take a straight line of 1ms motions which add up to 3 feet. You have an acceleration that allows a 1 foot move to hit 30m/min at about 6mm in. ( thats considering the time necessary to accelerate, and the time to decelerate... ( just an example ).
SO then we queue up a bunch of 1ms motions but each motion is only 4mm. Each motion is first planned separately so the full speed of the 4mm move is not 30m/min, but it only reached 20M/min due to the move being too short to simply push at full accel, it must instead plan an accel,cruise and decel motion. ( in this case there is no cruise).
So we end up with say 1000 moves, each one individually having a top speed of 20m/sec not 30m/sec as one woudl desire for the full motion. The planner ( same as emc by the way ), uses an additive property where as the first decel's , the next move accell's.. this makes them smoothly join togeher BUT the top speed is 20m/min ..not 30 even though the distance total would allow 30m/sec in real world physics. In the end the planner will allow for 2 seconds of motion to be put out at a time.
Block processing speed has nothing to do with it typically, the slowdown is because the individual motions dont allow for full speed. Straight lines are a separate issue as the system determines they are in a straight line and joins them as one line. BUT in the case of any other situation, angular devationos, corners etc.. the top speed will be the top speed of one 1ms motion, when observin the accel ( and decel of that one move.
So the real problem is that all moves, even short ones have a accel, cruise and decel time calulated into them, it is that which slows the feedrate, not the block processing speed. Since each short motion can only move as fast as it could move if it had to stop after the 1ms, the end speed is reduced. The cv simply adds the decel of one to the accel of the next. ( causing the top speed to be the 1ms obtainable speed.)
This is what I think you face, its not block processing speed, its the way CV works, the addition of the accel/decell zones is limited to the 1ms calculated top speed. In the case of Mach3's planner, when it goes to output the steps or 1ms points of the entire trajectory, it iteratively runs each block at the same time.. so if we have 10 blocks in the queue, it may run all 10 before it figures where it shoudl be after 1ms, BUT the accel/decel time of each block inherantly limits the end speed to be much lower than if the system had a longer time to accelerate and decelerate.
SO in a few ways your right, if the accel was modified to be a calulation based on total distance instead of the 1ms distance youd go much faster. The block processing speed you see is simply the result of not being able to go faster than the 1ms accel rate for such a short motion. Concatenation doesnt remove the limitation, it just makes a smooth transition from one motion to the next.
In Tempest this doesnt work that way. In tempest, the lookahead determines the accel and decel. For example, if two 1ms waypoints bend aroudn a corner, tempest joins them mathmatically into a bezier type curve, and calculates the true jerk of that curve, then allows any accel up to the jerk limitation desired. Because of this it runs faster in many situations, ( slower in others.). If email wasnt so bad at drawing I could show you graphically why each planner is limited in one way or the other. But it isnt block processding speed, I could process thousands of blocks per second, but it wouldnt speed anythign up, the block speed of processing is limited to the feedrate of the motion, since at any time, only 2 seconds of motion is queued.
In tempest youd be closer to the truth on slowdown. IF using a lookahead of 100 for example, and you have 100 1ms motions, tempest will basically attempt to make one motion 100ms long, and set a decel and accel profile for that motion, it too is limited though. The fastest speed one 1ms motion can achived is the most the speed can increase per 1ms waypoint. Each motion can be made to go faster than the motion before it unlike MAch3 and emc, as long as the following motions added up can allow enogh time to decelerate.
This is all a generalization of course, many circumstances are taken into account and create limitations of their own. Try tempest and see if it helps, I suspect youll hit some other limitation in speed as a result, but may find it faster in a surf baord type of application.
Youd just need to set the jerk very high as opposed to limitin it to a low value. Setting Jerk limit to 1million or so will make it as fast as it can be..
SO in essence, MAch3 and EMC suffer from having to calculate the decel of even a move which doesnt or shouldnt decel as its goign into the next motion, thus the top speed is limited to some degree, where tempest modifies the first motion calulated to increase its speed as it adds the next motion in. This ups the top speed of short segments, but again not always. Angualr devaitions of short moves are more sensitive to the math as a sharp angle at .001mm of motion can look acute where it realy isnt due to segment length.
The problem with planners is they integrate tighty to a system, so changing them isnt easy... it leads to a whole lot of error throughout
the system. Its why Tempest exists only as a test program, with some limitations as it isnt fully developed or attached. ( though I cut with it frequently as it produces a smoother finish.
Art
-
Hi Art,
Thanks for such a good detailed reply. Ive got the surfboard thing nailed, no need to consider that because it works great with the spline contouring (G5 in www.Eckelmann.de ENC55 controller if you are curious). But there are other issues with it that are tricky to resolve for some applications and important for me. It does however have a very good trajectory planner that works well until it runs through its buffer and then it reads one line at a time and goes jerky jerky until it gets to a slow part of the program like a corner and gets to fill its buffer up again, thats because my version interprets 250 blocks per sec (can get a newer ENC66 that does 1000 blocks per sec), but if the block throughput is lower or you use splines then it will run short segment code at the programmed feed rate and observe acceleration limits. Its got adjustable filters in its setup.
Anyway, I think you can do better based on what I have seen you do so far.
Im not sure I understand the limited speed that occurs in each motion segment but to my way of thinking (which is probably a bit weird) for a servo system it is the average acceleration over a short time period (like 10ms) that is important, since any jerk or pulse type acceleration on a shorter time period is masked by the servo response (and also by the 1ms waypoints). Of course this is bad for a stepper system, but then hey, who is ever going to run short segment code in exact stop, it horses for courses and the choice would be great. Have to change a CNC program so will reply again.
-
Hi Art,
Ive read your post again (and again) and I think I now understand the issue. To clarify, In Mach3/emc, Each segment is "planned" with accel and decel, but then the decel portion of segment n, has the accel value of segment n+1 added to it so that the segments join together smoothly. I guess there is more detail to it but I think that is the essence and it also explains why programs run faster as the segment length increases. OK, so what we are dealing with is the physics of a single segment rather than the overall physics of the path.
Tempest however fits a curve to it and has a jerk limitation. In theorey then a "smooth" path should be able to run at "full speed". I will do some tests. In theorey a 90 degree corner should be slower in tempest than in Mach3 CV mode for a given acceleration because in CV mode it "cuts the corner" and starts to accelerate into the new segment before it gets there, in tempest it will "exact stop" on the corner. This sounds real good. Its exactly how it should be. If I want round corners I will get my cam package to do them. This also means if you are cutting say a square with sharp external corners, the toolpath can have a corner radius smaller than the tool radius so it cuts the corner sharp but then tempest will follow the toolpath arc "exactly". Very Nice! Now if we can get Tempest to feed the path acceleration at each waypoint into the DSPMC then we can have proper "pre control" feed forward! Its a dream but the way of the future.
Now to find the speed limit.
-
Hi Art,
Just ot clarify , I think you can do better than the competition.
-
>>>Ive read your post again (and again) and I think I now understand the issue. ..Each segment is "planned" with accel and decel, but then the decel portion of segment n, has the accel value of segment n+1 added to it so that the segments join together smoothly. I guess there is more detail to it but I think that is the essence and it also explains why programs run faster as the segment length increases. ..we are dealing with is the physics of a single segment rather than the overall physics of the path.
Exactly so. Its really the small individual motion that causes the slowdown.. not the totality of motion or the blocks/second.
>>Tempest however fits a curve to it and has a jerk limitation. In theorey then a "smooth" path should be able to run at "full speed". I will do some tests. In theorey a 90 degree corner should be slower in tempest than in Mach3 CV mode for a given acceleration because in CV mode it "cuts the corner" and starts to accelerate into the new segment before it gets there, in tempest it will "exact stop" on the corner.
Not really. Picture 5 motions in have to be done. Say they are 1mm each. The accel and max velocity is such that a 1mm move can only go 100m/min because it then needs to slow down. Mach3 will be quite smooth at joinging them but the speed will be only 100 through the move. ( Segment n decel + n+1accel will cancel to 100m/min, the planned rate of each 1mm move.).
What happens in Tempest is that motion #1 comes in and is planned at 100m/min, the fastest it can go and decel in 1mm. When motion #2 comes in , a hermite curve is put between the two points at a tolerance specified by the user. Say its .2mm. This means an arc will be produced to join the two motions. Then, the entire motion is replanned from 0 - 2mm.. so the end speed is higher, Jerk equations are used to determine what the maximum physical speed is that the arc blend can be run at, the preceeding and end portions of the two lines are then planned to join with the arc at a matched speed. This means the overall speed can be higher than Mach3's. As each segment is added, the entire line is replanned except where its partially put out already in which case its planned from a known start speed to a desired end speed, taking jerk into accoutn through all arc blend join points.
This means in Tempest there are no corners, all lines round at the blend point to the radii set by the user as a blend radius. Any planer that has sharp corners has to stop, physics demands it. If it doesnt properly do that, you get as you describe, your surfboard runs well, other code is problematic.. ( likely servo faults or cutoff areas where undesired.). If you specify zero as the blend radius, you get a sharp corner..but Jerk equations tell us that any sharp corner MUST come to a complete stop. SO the end speed will be faster as the blend radii get larger. The Jerk equations allow for this. However, in short segment, the users blend radius is lowered to be a maximum of 30% of the line length, so very short blcoks end up with tigth radial belends, and the Jerk Equations thus lower the speed to constrain tangental jerk on the blend arcs.
No way aroudn it.. short code is a bitch.. :)
Art
-
I am watching with interest and I guess the real solution is a better CAM program instead of beating up the planner.
Mike
-
Hi Art,
I just tried out tempest and its not suitable for short segment code. As you say, it never gets up to full speed. Have you ever seen a Makino machining centre work? They only run G01 and short segments. Moulds are programmed with short segments. They run at the programmed feed rate. I dont know how they do it, but I suspect they just feed the G01 to the machine and have some kind of of feedoveride/accel/decel thing going on when the segement angle is like a corner or when there is a G00.
If the real physics indicates that a motion can be done, then it is the way it is being interpreted that is the problem, not the short segments. What is needed is a simple robust way that works.
The dynamics of the machine I am working with at the moment would get a better result (than tempest or Mach3 CV) up to 6000mm/min by just sending the 1ms points to the DSPMC, points worked out as if they had infinite acceleration (ie jump straight to feed velocity, no acceleration). It will get up to 6000mm/min in 0.5mm, provided the following error is set above say 1mm, no problem. Of course rapids would have to see acceleration, but that is G00 not G01.
Of course it would be better to look at the average acceleration and reduce the feedrate when required. Maybe some minor changes to the existing trajectory planner can achieve that. The motion has to be planned as accel, cruise and braking over the whole buffer, not for each segment. To do this it might have to start at the begining of the buffer and keep accelerating until it gets to maximum feedrate. It also has to look at the end of the buffer working backwards from the end where it is stopped, and decelerating as it moves backwards until it is at maximum feed rate, or it meets the acceleration phase. Following that logic the planner would fill its buffer, the limit being say time of motion or end of feed (say encountering G00) or number of blocks or whatever you feel like really. Then it plans the accelleration, accelerating over each block and subsequent block or 1ms waypoint until it is up to full speed. It also plans its deceleration, working from the end of the buffer backwards until they meet in the middle. Then as the buffer is used and new waypoints are added, the first part of the buffer has already been planned, so the new plan just works backwards until it meets the old plan, somewhere near the middle. There are some tricks that could be done to simplify the maths and make it robust. Yes it is a bit itterative, but it doesnt have to have many entries in the buffer. If there are few entries, then it will limit the speed when the accel and decel meet in the middle. The required number of waypoints can be worked out based on feedrate and allowable acceleration. As the motion across a 1ms waypoint segment is "fictional" motion, we can use a theoretical SpeedStepChange = accel*0.001sec, say for 1g acceleration its SpeedStepChange = 10000/0.001 = 10mm/sec/msec. The speed of each axis can increase by a maximum of that amount for each waypoint. Now the trajectory planning is done with simple step changes in speed.
I dont think any curve fitting needs to be done. Just assume a constant velocity across each 1ms waypoint segment, with velocity greater or less than last waypoint by the deltaV=acceleration*0.001seconds, unless the vector speed is at the programmed feed rate.
There will be an issue to be dealt with in that the ramp up and ramp down may not meet exactly according to 1ms waypoints. This doesnt matter if the buffer is just normally full, it becomes a special condition when the buffer is terminally full because it has run out of code or hit a stopping condition (like G00 or M30), then the ramp down has to be replanned from the meeting point to the end of the buffer so it is continuous. Id say start the deceleration from the true waypoint on the ramp up (or coast), before it met the ramp down, then ramp down at maximum deceleration, this will get to the second last waypoint, then move to the last waypoint at slightly less decceleration so it matches up properly.
I know Ive left out heaps of detail. Maybe it wont work, but I dont see why not yet. If I can help in any way, let me know. If this is implemented it will give exact stop in corners and blend all motion at full acceleration and at maximum speed. There will be jerk but that could be limited by more complex planning if need be. I dont know if the iterative nature will let it get done in time, if that is the problem, then I would be happy to pre process before run time and give up feed rate overide. But really it shouldnt be much more difficult than the current planner. Does it need a drawing to clarify my ramblings?
-
Totally RC, Yes i agree, a better CAM package is (almost) thel answer. But have you ever tried to get one of the high end CAM packages to do something for you or get something changed? At least we can talk to Art!!!
Anyway if the CAM package is doing its job properly, in G01 mode (and Mach3 doesnt support G5 splines) then its not that simple. If the machinist wants to achieve a 0.001mm (Ok hes dreaming or lazy) or 0.01mm tolerance, even 0.1mm tolerance, then tight radii will have very close points, then even though theoretically the dynamics of the machine would allow it go around the radius at full speed (eg 7000mm/min feedrate goes around a 1.4mm radius at 1g), the Tempest and Mach3 and EMC planners would limit the speed savagely because its the segment length that is limiting feed rate, not block processing speed or physics of the true toolpath. 3D continuously changing contours arent practical with G02/G03 and splines can have issues as well. G01 is the general robust solution.
What I am trying to get across is that trajectory planning might be better if it happens according to physics (taking account of the discreet 1ms cyclic nature of our data transfer and the real time response of motors) across the full motion path rather than across adjacent segments. Jerk and acceleration over a 0.5ms period mean nothing because the motion controller is only getting points to use in its PID at 1ms. The response of the serovs results in Following error that smoothes out anything that happens in a period of a few ms. Think about what happens in the PID. It compares actual position with command position to get an error value that is used to command torque on the motors. That happens cyclically (this is a digital not an analogue world) so every 1ms (or 02ms for the DSPMC) the drive is getting an entirely new torque value which implies an instantaneous infinite jerk. Of course the response of the drive and any filters in it then the inductance of the motors and everything smoothes it out over a few ms. So what I am saying is, use that imperfection in everything else to make the trajectory planning easier.
If you crack this planning properly then you open the door to a whole new world.
FYI I have a customers machine running a step controlled servo drive and a parrallel port based motion control (wont mention any names here, its not Mach or EMC). It is programmed with short segment g code and will run over contours at 16m/min quite smoothly. The problem is it ques the motion up before hand and takes a while to load the buffer. The buffer has a size limit and thats a problem for big programs and long motion. Also there are limitations as to what can be interfaced with it and it wont do what I want to do in the future. So what we want done as a planner can be done in a non real time way, the question is can it be done real time?
-
>>Have you ever seen a Makino machining centre work?
Hmm, lets see if I can create a way to explain this the way I see it.
Lets say you get in your car for a drive around the block. You have a very fast car.. ferarri say..
To a ferarri, you have a very short run on each street as you go around the block..
Now we all realize that you will accelerate , then brake as you hiut the cvorners.. if you dont youll skid out and lose
position as you try to do the corner. The skid is created by the math expression "Jerk". One can calculate jerk as a function of velocity
and acceleration as the vectoral direction changes. This is refered to as tangental jerk. How much tangental jerk you can accept before
skidding is a function of your tires and how well they grip. Lets say we remove the tires and put a set of rails around the block with
very small arcs at the corners to allow for a directional change without stopping. ( CV)..
Because the car is now locked to the rails with top and bottom clamps, you can now make the same car go very fast around the corners.
A Makino is such a device. Its designed that it can accept a Jerk of very high magnitude before losing position of straining mechanics.
There are time in such machines if you listen that they clunk quite a bit..doesnt hurt them at all , but that clunck is the inflection
point of the highest jerk experienced.
Now CNC in general, certainly in Mach3 users generally, have machines on tires..no rails. They will lose stspe or fault servo's if forces
go too high, its why MAch3 doesnt allow infinite acceleration. I highly suspect if that restriction alone was raised you'd go much faster indeed. I just happened to pick a limit that was lower perhaps than what woudl be optimal for someone like yourself that wants higher speed
through small blocks. Might be interesting to raise that substantially to see in a test version for you.
All things in CNC are tradeoffs. If you go for high speed ou sacrifice stability or position, there is by the laws of physics no way
around this limitation, positional accuracy requires lower speed OR high Jerk capability. High speed requires the desire to go out of
position ( rounded corners) , or very tight mechanics and very high power. A Makino has both very powerfull servo's, and very tight mechanical connection and slides. The software for it knows that and uses VERY high acceleration, and unique ways of joining
line commands to create fast motion.
Tempest KNOWS the jerk at vectoral changes, its why in small blocks it still wont go too fast , in fact in a lot of code its slower
than MAch3, testers report a finer finish but slower completion, this is because tempest is also a SCurve genrator, makign it slower by 30% in accelerated takeoffs, but much less jerky to the mechanics, again, all a tradeoff on performance. When I watch tempest do a 3d mould, it almost never clunks, where MAch3 clunks a lot. My machien can take either but the difference is audible, which tells me somethign about
how Im treating my linear ways and such.
You idea's on simply taking 1ms waypoints is a bit off the mark, its not waypoints you want, their already there. Its very very high acceleration that you need. Decisions on when to apply that as opposed to normal accelration are difficult to generalize to specific
situations. Thats what you find when you try to do it.
Ill see if I can generate a very high accel version to test with. Im not sure the math of the planner will allow such high accel, but in theory it should..so it may. :) Again, generalities dont allow me to say for sure it will do what your looking for. Planner technology is very difficult to do, and theres a lot of discussion on how to do it. Tempest was written from idea's in a doctoral thesis from a Canadian university. But agin, was heavily modified to meet the general nature of peoples machines.. No-one writes anythig for a speciic machien execpt its manufacturer.
Art
-
Hi Art,
Firstly, I hope you understand that I really like Mach, for lots of applications its fantastic. I also think the work you are doing is fantastic. Im just putting in my $2 worth (bit more than 2c now), and offering to help in any way I can. There are lots of us who are building more advanced machines, its like a drug or arms race, once you start to do CNC,you just want to do it better and better. Control of chip load, contouring and speed of running are all relevant to lots of people. The planner I am discussing should be general for all machines, not specific ones. Its just that the machines and applications I am working on make it easy to see the effects and cost savings of good trajectory planning.
I dont think Tempest is taking advantage of the laws of physics. I have one axis set up with a linear motor. The test setup is highly dynamic, it can go to 8g since it had no extra mass on it. It could handle very high Jerk. I have it set to 1g in the motor tuning so it limits it to a realistic acceleration. Thats not the point, Ive got other machines that have acceleration capability of only 0.01g so understand what you are saying.
Here is what I did on my Tempest test. I will send the code when I get into work so you can try it. I set up just X moves, all 0.1mm segment length for a total distance of 50mm. If I do just one G01 move over 50mm Say G01 X50 F50000 the motor accelerates fery fast (1g) and very smooth and goes straight to the endpoint. With the lots of short moves it goes much slower and and with varying speed along the way, as in faster slower, faster slower... Worse at jerk 50 000, ok at jerk 1000 000 (but still with visible speed changes) and worse at Jerk 10 000 000.
I know jerk affects the dynamic response of a machine. The acceleration sets the size of the force while the jerk is the rate of onset of that force. Acceleration depends on the force of the servos while Jerk can be higher as the mass and stiffness and natural frequency of the machine increase. A planner needs to control position, velocity, acceleration and jerk.
Using the road and rails analogy, what I have is a straight road with a lot of lines across it. The car should just drive over the lines and go from start to stop as if they arent there. But is doesnt, it is likethe driver is trying to brake and start at each line, with Tempest and CV just helping the driver roll over each line. If the Trajectory planner looked over the whole straight road and kept accelerating then there would only be a jerk at the start and stop of the acceleration as constant acceleration gives zero jerk.
A cnc program is like dots or witches hats along the edge of the road. Mach is trying to drive between each marker, thats fine if the markers are 100 yards apart. But CAm packages are like road workers paid per marker and drop the markers 1 foot apart. So long as the makers follow a smooth path around the race track, you can drive your Ferrari at 200mph within an inch of every marker, the markers are a blur and the driver doesnt really see each marker, he sees the overal path. mach would be doing it at a walking pace as it tries to drive a straight line between each marker with just a bit of coasting and a turn at each marker. Its not what everyone wants. Mach is doing a good job at proper corners but it is doing a pretty slow job of points on a smooth trajectory.
I dont want infinite average acceleration. What i want is constant acceleration or as high acceleration as possible within machine and overal trajectroy limits. If you can add in a jerk limit then that is great.
Art, is there someway for me to get into DSPMC a premade list of points (say the 2048 points in the buffer) at 1ms separation so I can take a video of various plans and then compare them against Mach and Tempest. With my Elmo servo drive I can get it to log the actual position,velocity, motor current etc and send a picture. But only for about a second or so. This might be an easier way of looking at trajectory methods rather than going through the pain of writing and integrating an entire planner. I can just construct whatever physics we want to look at with a spreadsheet or bit of stand alone code.
It was a long way of saying the planner needs to look at the whole buffer (path) and go to as high a speed as possible within the constraints of acceleration (and jerk if your machine is wobbly). What can I do to help?
-
piv:
>>Im just putting in my $2 worth (bit more than 2c now), and offering to help
No problem there, I never take offense and it allows me to rethink many things when I have these discussions,
its sometimes a long time betwen code sessions so even I forget how things work.
When you say 1ms points..using what acceleration? 1ms presupposses that there is an acceleration as well
as a feedrate. If you mean can it send you points not separated by such things as slowdowns for junctions and such..not easily.
Its basically trying to defeat the way it works. It wasnt designed to look ahead that way. Closest you could get woudl be to have
as close as infinte acceleration as possibel and accelerate the data yourself.
Im heavily bogged in code at th moment, so its not a project I could take on, but perhaps in the near future I coudl allow such high accels
in a test version.
Your rigth about tempest. Its drawback is that it cannot add one line to another, its designed to always put an arc to join lines, that arc stop sacceleration
during its run and its 20% of the line length, so the accel is jerkier to apply so the speed is kept down. Tempest is far from finihsed though, its just sleepinmg till
summer sometime.. :)
Art
-
Hi Art,
Thanks for your time. I think I can get up and running with Mach on some of the existing machines so there is no immediate urgency. Im looking ahead to see if it can be improved for the future.
>>When you say 1ms points..using what acceleration? 1ms presupposses that there is an acceleration as well
as a feedrate. If you mean can it send you points not separated by such things as slowdowns for junctions and such..not easily.
Its basically trying to defeat the way it works. It wasnt designed to look ahead that way. Closest you could get would be to have
as close as infinte acceleration as possibel and accelerate the data yourself.
When I say 1ms points I mean points on the motion path, spaced 1ms apart, with the path acceleration (vector acceleration, sum of tangent and normal accel) limited to the motor tuning value (in my case 1g, 10 000mm/s/s) (or a programmed value). Because it is piece wise discontinuous (in the control loops), this effectively means the acceleration is just an allowable step change in velocity (v=u+a*t) for each 1ms waypoint. Its way easier to sort out than the way Mach does it at the moment I guess.
If it has infinite acceleration, then it might be feasible to accelerate the motion by putting a feed rate with each segment, but thats not the general solution for most CAM packages. But, it would have to be a mode of operation (or special G code) since G00 and G02 etc would still need an acceleration value like they do now.
-
>>When I say 1ms points I mean points on the motion path, spaced 1ms apart, with the path acceleration (vector acceleration, sum of tangent and normal accel) limited to the motor tuning value (in my case 1g, 10 000mm/s/s) (or a programmed value).
Hmm, but thats exactly what MAch3 does now.. gives 1ms waypoints limited ot the motor tuning acceleration.. Thats the Mach3 planner in a nutshell really.
I think Im not grasping something maybe.. But that describes exactly what Mach3 puts out.. possible shortcoming that each segment is limited by mototr tuning to its max speed, but that cant be changed without simply using a different planning theory algorithm altogether..
Art
-
Yes art, it might need an entirely different planning algorithm because the current Mach planner speed is limited to what can be done on the G code segment and its next G code segment. Or Im not understanding how the Mach planner works. Certainly its not getting up to the physics limited speed over a long path (made of short segments).
-
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 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
-
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
-
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
-
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!
-
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)
-
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
-
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.
-
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
-
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)?
-
>>There'd be no need to, the plugin author coudl just a load a file of points..
Art
-
Thats what I thought might be possible, loading a file of points straight to the device. Even better if can happen from inside the G code file somehow as the machine has to work like a normal machine, for tool changes, set up, jogging, MDI, fixture offset etc. DSPMC plugin was written by Vital Systems. Im going to see if they can do anything or help out. I asked the question yesterday but havent got an answer from Rufi yet.
Id be willing to have a go at the plugin. Can you give me a bit of architectural guidance or point me to a document that says whats possible, or how it could happen as Ive never written a plugin. Im not sure on how I could get it to work with the DSPMC, Ive got no documentation on the communication to it.
-
piv:
Theres a few docs around on plugins.. check the plugins download sdk for the example, but you migth ask rufi if he'd give you a copy of
his current one..
Art
-
Rufi from Vital Systems, DSPMC is going to help me out with this. Thanks Art.
-
I have a couple of questions about Tempest. I have read the thread up to this point and I am not fully clear on the reasons for Tempest. As a physicist, I do understand jerk and snap. I also appreciate the fact that what you are doing will make the Mach3 machines run "more smoothly". But what are the specific ends you are trying to achieve? Better looking results on the workpiece? Less wear on the machine? More axes? Less error in the cut path? I ask because it is helpful to fully understand the objectives when testing. It will help me select test parts from parts I am making.
My second question relates to processors. Is this module designed to take advantage of multiple processors? My desktop now has 4 cpu's (8 if you count hyperthreads). More will come in the future.
-
Hi:
>>But what are the specific ends you are trying to achieve?
All of the things you mention really. The problem lies in the way planners typically plan a motion. When acceleration is applied, its applied fully
until the motors get up to speed, when decelerating, the decel is applied at full rate to slow down. This causes "Jerk", the immediate slowing down of mass
which causes a jerk on the motors and mechanics.
Tempest applies the accel is a sine wave template, so its much smoother. Its an attempt to make motion in cnc more like driving a car where the accelerator
is pressed in an analogue motion dependingh on requirement.
As the thread says though, this makes most motion take up to 30% longer.. the guy with the binary accelerator pedal DOES get to his destination faster,
but its harder on the vehicle and brakes. The challenge usually is the small segement code, where its hard to concatenate small segments to move quickly.
Tempest is an experiment producing 5th order waveforms instead of 3rd order as is typical. It does achive less error in the pah, smoother motion and defined
limits in mechanical stress, but at the expense of speed. MOre work willlikely be done this summer to see what can be done to address the time compnents.
Art
-
I think you could recover some of the lost time Tempest "costs" in the following way. Mach3 presently does the acceleration setup from a standing start. I believe you can, for most machines, achieve greater acceleration from a moving start due to higher static than dynamic friction. Since Tempest will limit jerk, the starting acceleration will be smaller than the peak acceleration. Allowing for margin in both cases, my guess is that a machine set up to take advantage of this fact could make a substantial improvement in Tempest mode over standard setup in standard mode.
-
I noticed the wording in my last sentence was not what I intended. What I meant was that with the alternate setup I proposed, Tempest would be better than Tempest without the alternate setup. I don't think you could reach the performance of Mach3 with its infinite jerk. You could, however, recover some of the loss relative to stock Mach3.
-
>>Mach3 presently does the acceleration setup from a standing start. I believe you can, for most machines, achieve greater acceleration from a moving start due to higher static than dynamic friction.
I may not be understanding your intent. Its true that MAch3 applies accel from a standing start, it goes from 0 accel to max accel instantly...
Tempest applies it gradually. But both tempest and mach3 apply accel from moving start on every block as its in motion.. tempest gradually, mach3 instantly..
Its mostly a tradeoff with any scheme, but Tempest is a test of the tradeoffs..
Art
-
The setup of acceleration in M3 is done starting at rest. The user tunes the acceleration based on how the machine performs in this test - with no control of jerk (pretty high at end points) as I understand the test. As it says in the docs - the limit is set mostly done by sound and pushing to failure and them backing off. I believe that if the setup were done with a jerk limit, the peak acceleration that the user would end up with would be higher than the acceleration you end up with in the standard test. This is because higher peak accelerations would be possible since they would occur (in the test) when the machine was already moving. This of course implies a different acceleration setup for Tempest M3 than stock M3. Is that clear?
-
Art,
I know that the notion I had as I awoke this morning is an over simplification but since the 2axis motion of tempest is so smooth, I thought I'd throw it out there. 2 axis motion in g17, 18 or 19 is very good when the third axis is thrown in it starts to have a problem. I was wondering if it would be possible to use your algorithm to control the two primary axies and pulse the third proportionally to the move with the other two, using the assumption that the third is usually going to be within the jerk parameters of the other two. since the 4th is usually a rotary, I wonder if it could be done the same way?
-
REally, 2 axis is good and 3rd axis is rough? Or do you mean your using x,y an dA for example?
Its true that using rotart is not perfect as yet in tempest, Ive focused primarily on cartesian...
but using x,y and Z should be fine?
Art
-
Art-
I am curious about your thoughts on my reply #129.
-
Bruce:
>>The setup of acceleration in M3 is done starting at rest. The user tunes the acceleration based on how the machine performs in this test - with no control of jerk (pretty high at end points) as I understand the test. As it says in the docs - the limit is set mostly done by sound and pushing to failure and them backing off. I believe that if the setup were done with a jerk limit, the peak acceleration that the user would end up with would be higher than the acceleration you end up with in the standard test. This is because higher peak accelerations would be possible since they would occur (in the test) when the machine was already moving. This of course implies a different acceleration setup for Tempest M3 than stock M3. Is that clear?
If I understant you , thats only true in non-linear acceleration. In Mach3 ( linear accel), setting it to a jerk limit woudl reduce the end accel and speed as its that that causes the jerk in the first place, in Tempest ( sinusoidal accel), its very true that the accel shoudl be set with a jerk limit. It uses MAch3's simply because tempest is mach3 with sin accel, so I didnt rewrite the motor tuning. In fact in Tempest one shoudl set the accel normally, then increase it by about 30% as tempests use of sinusoidal accels will allow the motors typically to do about 30% better accel.
However, since sine based accel uses about 30% more time than linear ( on average ), the end speed is then simplyequalized, not increased ( on average) by havingthe accel set higher.
The problem in tempest is that while Gcode motions use sine accel, jog doesnt, so you have to be carefullnot to make jog too jerky when tuning. If Jog was sinusoidal as well, then simple
motor tuning by sound woudl be fine.
I advise simply tuningmotors in jog as high as you can without losing steps.. Tempest can usually handle that high an accel..
Art
-
Ah - the point that Tempest can handle higher acceleration is what I was after. How it is set up probably does not matter. Tnx.
-
Bruce:
Yes, since its 5th order, it can handle Gobs more...
So feel free to turn it up.. till jog starts to fumble, then back off a bit..
Art
-
I'd like to see Tempest as it is right now as an option in Mach3. For normal 2.5D routing, it blows away Mach3's planner.
-
Bruce:
Yes, since its 5th order, it can handle Gobs more...
So feel free to turn it up.. till jog starts to fumble, then back off a bit..
Art
Hi Guys,
On my DSPMC powered mill the motor tuning was able to be set much higher in Tempest than with the standard planner. I think as much as 30% higher. Since the DSPMC support S-curve acceleration "natively" I asked Rufi if he could add S-curve jogging and he said he could. Unfortunately it is not high on his to do list. When I get back to running my mill more I will see (Bug him) if he can get this done.
As I told Art during one of my posts I have never seen my mill move that fast and that smooth at the same time as when running Tempest.
Here is to more Tempest work.
Art, not sure it it would be applicable but can tempest be used in turn? Would turn benefit from the motion planner?
I am entering the wonderful world of round parts and was just wondering.
Mike
-
Hi Mike:
It woudl give a smoother finish..
By the way, the DSPmc supports SCurve natively because Tempest sends the data in 1ms trajectories, so
when running tempest, any device, printer port, G100, SS etc.. are all supporting SCurve, since its Tempest
that is supplying the information on position.
Art
-
Hi Art,
I guess what I should have said is that the DSPMC has s-curve built in so to speak. When using the axis work software to set it up you get the option of trapezoidal or s-curve motion. This would mean that all the ground work for s-curve jogging has been laid and that it shouldn't be that tough for Rufi to implement.
-
REally, 2 axis is good and 3rd axis is rough? Or do you mean your using x,y an dA for example?
Its true that using rotart is not perfect as yet in tempest, Ive focused primarily on cartesian...
but using x,y and Z should be fine?
Art,
I went back to the machine to look at what was going on with the tool paths I was testing on my machine and realized the issue might have been short segment code vs longer segment code, so I squashed my drawing and made a flat short segment code of the same surface. I set the jerk to 10000 and the bend to 50 units. I set the feed rate at 4000 mm/min the flat program ran at about 2000 mm/ min and the 3d at about 300 mm / min. I guess the issue was more the speed of the cut possible with smooth motion, hence my thought about applying the algorithm to the two flat axies and proportionally pulsing the third as it usually moves at lower rates relative to the other two. I am running a smooth stepper to alleviate my difficulties with windows interrupts. so I would think that calculation speed shouldn't be a problem, I haven't built my 4th axis on this machine yet, so my comment on that was just assuming that if the 3 axis motion was a lot slower, than 4 would add to the problem.
-
Art,
I used the Tempest on a large machine and it is amazing. We have some questions about Tempest and really need to talk to you. Can you please call 800-310-2887 and ask for Bill or Carl.
Bill
-
Bill:
Sorry, but tempest is simply a technology demo that isnt any longer worked on. IF you have questions I can probably answer them. Contact me at fenerty@artofcnc.ca
Art