BR549; just to comment on your statement, I also dislike the idea of monitoring MACH for the purpose of controlling a lock, and for the reasons you cited.

However, I did fairly extensive testing of the servo error induced by using a Macro embedded in g-code and most of the time there was no increase. In order to get even a measurable increase in following error (obviously we are talking servo here), the acceleration had to be set up to a rather ridiculous degree which would not be used in 'real life', so by any measure, the additional following error introduced by the embedded macro method was zero in actual practice. I posted the results somewhere in this forum.

The reason I believe there was no significant error introduced in *my* case, was the combination of two factors. 1) Mach was automatically prevented from starting the next coordinated move until the M code was processed and 2) the total amount of time required to release the disk brake either occurred within the time it took mach to start execution of the subsequent move . . -or- . . . . the time to release the brake occurred somewhere within the early part of the acceleration and therefor had a negligible effect.  

In a 'transparent' arrangement, the drive itself (at least the one I am playing with) changes the pin state within in a few milliseconds of new steps coming in and the instant the air valve is closed, the disk brake begins to release as the air pressure bleeds out of the cylinder. I do not have equipment to quantify this effect, but it stands to reason that whatever residual drag the lock may momentarily impart would be handled no differently by the drive than any other variable force. In practical terms the rapidly diminishing drag that might be present from the brake at the start of a move would not be different than the additional drag imposed by a heavier workpiece. These types of load are automatically accommodated by the PID scheme utilized by the servo drive.  



 

(;-) Where you have a built in wait state then that is not really a problem. BUT when you are trying to run the gcode transparently there is no way to avoid the time lag of the mechanism in relation to the flow of moves coming out of the buffer.

Try running your setup without the wait states, I bet you will randomly trip from positional errors with a servo OR miss steps from a stepper

The only way I have seen it done without problem was from a realtime system that incorperated the I/O sensing into the motion data control point so the movements could NOT occur until conditions were met.

Try running your setup without the wait states, I bet you will randomly trip from positional errors with a servo OR miss steps from a stepper

There are no wait states other than a sleep(10) in the macro that is there to make MACH execute reliably. 'Hard' delays seem to be needed in many cases or MACH gets ahead of itself. For example, Mach does not update the var monitor reliably without a G4 in the code where the update should occur. This is an anomaly in the software that has nothing to do with an axis lock or any other specific application.

In my testing, I was watching DROs that show both real time following error and record the max following error, so there is no need to speculate on how close it was to faulting. Theorizing is only meaningful prior to quantification. Why bet on a race that is already run. 

(;-) That was not theory, but the results from testing.

The sleep(100) is a wait state. running in VB/Gcode code IS  a wait state as well.  Running directly from the buffer there are NO wait states.

Let me know how it goes when you go LIVE with the tranparent version.

Both the swapaxis function and the spindle lock function are already transparent to Mach.

For those unable to accomplish a task, it is comforting to believe it impossible.

http://www.ucsofa.com/famousquotes.htm