So If I am correct, and I think this is what Joe said He is working on, You could have a brain comparing your encoders to the g53 position also in the brain specify your following error allowance, and if it is exceeded trigger an e-stop? Wow, now I am getting ahead of my self But.. then maybe instead of an e-stop, you could do a modified adaptive feedrate!
Do you need the rogers board to interface with encoders or just a 2nd bi-directional parallel port?
Thanks for any replies,
Cutmore

Not sure on the adaptive feedrate, Brian or Art would have to answer that one but yes it should be easy enough to look at the DROs and compare. A simple formula to compare your DROs and see if they differ by a set amount then if they do press the Reset button.

I think you can imput encoders through a parallel port so dont think you really need the board from Ron if that is all you are doing.

Hood

I would think the question is how fast is the brains logic. Will it compare positions and stop the axis fast enough to save the part. I would think yes. Second question is can a reliable encoder be setup on a second parralel port. I would think yes again. About the feed rate. I would ask why change the feedrate if your axis position is off. I would think at that point you would want to stop and rehome sence your never going to get the position error back. Just my two cents.

Writing closed loop code is more complicated than how fast the Brain might or LPT might be. When you are comparing fast signals its not only important to be able to read them fast but you have to read them consistently (meaning the same time delay between each loop, i.e. hard real time). You are always dealing with signals after the fact, that is after the event already occurred. If your LPT (your encoder signals) latches with a different/inconsistent time delay and/or the DRO signals have an inconsistent time of update than the information garnered would not be very accurate. As I understand it Mach runs in a quasi hard real time, using a hardware timer on the mobo. This works great 99.999% of the time, but things can decide to grab large amounts of processor time (like stupid QuickTime services) and then Mach can/will loose steps. EMC works differently, they use a Real Time kernel extension that gives EMC top billing over everything else.

With external stepper/servo controllers (Galil, NCpod, G100) you get the best of both worlds. You have a hardware driver whose only job is to control the motor (the loop is closed in the drivers) and that leaves the whole PC available to Mach to calculate the next moves to be taken, update the display, and monitor the keyboard (etc).