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