On Fri, 20 Apr 2012 09:47:44 +0100, you wrote: >On 20 April 2012 06:42, Scott Hasse <[email protected]> wrote: >> Rather than trying to solve this problem in a million places not under our >> control, doesn't it make sense to try and solve it properly in one place >> and look more closely at using more than one line for look ahead? > >As I said earlier, I don't think this is a "Lookahead" problem, it is >a "must be able to stop inside the next code block" problem. >And I am not convinced that being able to stop the machine within the >next code block is necessarily a sensible requirement.
One line look ahead seems to cause a problem in LinuxCNC, the trajectory planner is not optimal. Mach seems to be able to feed hold without having to run out the whole look ahead buffer. The look ahead is user selectable, but I've never ran any code that in practice needed more than 10 lines. Some code is crap, no getting away from that but for the same code, same velocity and acceleration settings etc LinuxCNC is much more jerky, and slower than Mach on the same job using steppers via parallel port. It's particularly worse on arc to arc or arc to line transitions. Short straight line type 3D code is also poor. To get it to behave similar to Mach the following tolerance needs to be 10 times worse! This is how it's done with Mach. (Quote from Art Fenerty) Mach3 is a bang-bang accelerative trapezoidal velocity planner, and a very good one for almost all code types. Its CV is created by the simple rule of beginning the acceleration of the next motion when the acceleration of the current move goes negative. ( deceleration phase). This means you are literally adding one move to the next , allowing for the speed to increase. I'm sure many have read this before and can picture it in the context of two motions where the second is added to the first , thus making the deceleration phase virtually invisible ( thus constant velocity ), but what I , or Brian, rarely mention is that it operates in full look ahead, this means that in tiny segment code, the code of a line may be passed over by the time sequence of the planner as it progresses, but that motions speed must still be added in to the total of the motions distance. This means its an iterative process, where up to 100 lines or more may be actively added together in terms of their deceleration phases being added to the next motions acceleration phase. This can be hard to wrap the head around. Each Gcode line has to be considered fully in the iterative calculations involved. Imagine tiny segment code where the angle of the next motion is constantly shifting ( typical 3d work ), and the processor is trying to keep track of the real speed that's possible. Since the consistency of the speed is a function of the additive properties of each motions deceleration phase, it means the max speed an individual motion can do is important in the functions total speed accumulation. Steve Blackmore -- ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
