Hello Guest it is March 29, 2024, 10:46:54 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ART

751
>>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


752
>>>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
 

753
LazyTurn / Re: LazyTurn
« on: February 03, 2010, 09:15:41 AM »
Hi Guys:

  I tested on my Win7 box a few minutes ago.. no errors seen. I too think its an opengl issue. ( they can be a bugger ).

Id suggest a video card driver update if you can find one..

Art

754
  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
 

755
>>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

756
VB and the development of wizards / Re: Using the COM API in VB .NET
« on: February 02, 2010, 01:21:52 PM »
Hi:

 The design is to have it connect once and MAch3 cleans up after closing.. It wasnt meant for multiple disconnect and reconnects. Thats probably why the error..

Art

757
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

758
LazyTurn / Re: LazyTurn
« on: February 02, 2010, 10:16:10 AM »
Hi Mike:

  Point taken, I run a Win7 computer next to my development computer ( XP), Ill run some tests on Win7..

Thx
Art

759
LazyTurn / Re: LazyTurn
« on: February 01, 2010, 02:40:05 PM »
Rich:

  yup, youve pretty much identified what I see as the troubles remaining. Though I also see one rough pass seems to end early for some reason in the right center half way in the X dimension..

 Undercuts are a bitch as they make a decision tough on when to pull out ( or left or right) and how much.. Im working on a more detailed algorithm to identify those tough points for special processing..

 Thx for the detailed results.. Ill yell soon when I have a new version for testing to see if I can better eliminate those sticky points..

Art

760
LazyTurn / Re: LazyTurn
« on: January 30, 2010, 08:26:50 AM »
An under means the tool is cutting UNDER a lip. I guess you could define it as when a stright line in the X from the outter edge of the screen  to the tooltip has to pass thorugh material of the profile. Thats refered to as a undercut area.. The only way to cut such a thing is for the tool to reverse Z direction after entering in order to get out of that area..

Art