I see 2 problems to overcome.

1. Mach is a buffered system all moves are planned adn then sent to the buffer for output. Once in the buffer there is little interaction back to mach as to when a Aaxis move is being sent out.

2. Latency of the mechnanism. You will need to be able to "start" to deactivate the brake long BEFORE mach makes the actual move.

There is a signal mach has "current hi/low" that can trigger a relay on axis movement, we use it to drive the timer for the lube pumps,  BUT by the time the Brake reacts it it will be too late. Servo error or lost steps would be the results

We worked on this for a while a long time ago. Even Art suggested it would not work without driver level intervention.

NOW what we did get to work fairly well was rewriting the CAM post to enclude the Brake function before and after the index move that worked well for CAMed situations. BUT it could not do interpolated 4th axis moves well. Abig mess actually.

BUT you never know, maybe ?

Presumably you just want to look at the step/dir train incoming, unlock when it starts, and lock again when it stops.

The logic is pretty easy, but I'll bet the issue will be the time it takes to lock and unlock (that latency) and whether that creates a problem for your g-code programs or for the electronics.  The electronics are just a matter of buffering the pulses until locked/unlocked and then resuming playback.

Issues with the g-code program would arise from trying to do coordinated moves between the axes.  I don't see how to fix that without going to macros.

I guess what I would do is use an M-Code to close a relay that turns "indexing mode" on and off.  When its on, the locking is enabled and the lock synchronizer will function whenever it sees step pulses.  When off, the 4th axis stays unlocked for continuous machining.

That's my off the cuff.  I'm sure I missed a lot.  Will be interesting to hear more.

Best,

BW

2. Latency of the mechnanism. You will need to be able to "start" to deactivate the brake long BEFORE mach makes the actual move.

There is a signal mach has "current hi/low" that can trigger a relay on axis movement, we use it to drive the timer for the lube pumps,  BUT by the time the Brake reacts it it will be too late. Servo error or lost steps would be the results

Yet lateency is an issue, but only with unlocking. Right now I use macros to engage and disengage and I have delays built into the macros. A G4 command can also be used in the G-code immediately preceding the move.  My goals is to eliminate the need for manually inserting stuff into the G-code. To do that I need to find some available trigger that occurs at the correct point and use that to operate the lock.

What Mach signal are you using as a trigger?

Presumably you just want to look at the step/dir train incoming, unlock when it starts, and lock again when it stops.

Yes exactly, but only while in 'indexer' mode. In 'lathe' mode (including all simultaneous axis moves that include the 'A" axis), all locking would be disabled . .  except perhaps for an e-stop.

I guess what I would do is use an M-Code to close a relay that turns "indexing mode" on and off.  When its on, the locking is enabled and the lock synchronizer will function whenever it sees step pulses.  When off, the 4th axis stays unlocked for continuous machining.

Correct again. My thought is to rig two 'modes' for the locking function. When the 4th axis is in 'indexer' mode, the automatic locking feature would be active and in 'lathe' mode all locking would simply be disabled. This would be easy to trigger simultaneously with the swapaxis hardware. i.e. I could split the signal to the Swapaxis SELect pin and use a mirrored signal to enable the lock solenoid, or something like that.

It is an interesting challenge.

I thought you had three modes:

1. Full A axis mode
2. Indexing mode
3. Spindle mode

Now you're saying you will need the locking only in the "indexing" mode. Can't see how the program "knows" whether you're in "indexer" mode or in "Full A axis mode"? Looks like a macro is needed...?

Dan

Current Hi/low is an ouput signal that can be mapped to pin/port, look in config,pin/port,output.  BUT it signals on ANY axis movement and is WAY too far behind the data stream time wise.

I have seen this done from a motion card and a realtime system. I cannot fathom it working from mach(;-( WITHOUT the use of a macro. You would have to be able to TAP the function into the DRIVER level. AND as Art said once "That aint gonna happen".

BUT I will keep the thinking cap running(;-)

Is this something that could be configured into the post processor ?

Just rambling.

Russ

I thought you had three modes:
1. Full A axis mode
2. Indexing mode
3. Spindle mode

I don't know where this came from, but it was not from me. I don't recall ever saying 'Full A axis mode' and I really don't even know what that would be.

There is no point in getting into a semantics argument.  There are no defined 'modes' so you can call them whatever you like, but there are only two. There is an A axis and a Spindle axis. One has postion and one does not. 

Current Hi/low is an ouput signal that can be mapped to pin/port, look in config,pin/port,output.  BUT it signals on ANY axis movement and is WAY too far behind the data stream time wise.

I have seen this done from a motion card and a realtime system. I cannot fathom it working from mach(;-( WITHOUT the use of a macro. You would have to be able to TAP the function into the DRIVER level. AND as Art said once "That aint gonna happen".

I'm not familiar with the 'current hi/low', but my ignorance there is irrelevant since by your description, it would be unusable in any case. Sounds like you have a visual on the challenges.

In order to function, it seems to me that the trigger must come from the servo drive. So I would need a drive that has or will have some function that identifies a condition where the lock should be applied and released. Custom firmware is certainly one path. A 'position reached' function looks like a promising possibility.

Another poster mentioned the need to disable the drive while the spindle is locked. The 4th axis has a belt drive and the lock is on the spindle and *so far* there is enough 'give' in the belt that the drive is not too unhappy with a count of two off an 1800 line encoder . . . BUT . . I am also pursuing the solution mentioned where the drive is disabled during the lock event and re enabled. I am waiting to get one question answered by a vendor to determine the feasibility of that solution.

Overloaded: you are exactly correct.  Right now I have to manually insert the macros int the G-code. Automating that process would require messaging a post processor, as you correctly point out.  I want to avoid this. That is what drives the goal to make it automatic and transparent.

Doing it at the servo drive level won't work either, Tried that as well using the servo brake

Anything you see at the drive level is already BEHIND the time curve of the buffered data AND mach has no idea what is happening at the servo level movement wise so it cannot STOP the data flow out of the port.