OK, it does not appear that you are going thru modbus with your e-stop. Sounds like you are hardwired to the BOB (be that an SS or whatever).

My setup is similar except that I do not go thru a PLC. I have an E-stop 'collector' board that has 4 inputs daisy chained and one out put. Any input goes out the E-stop goes out.

I have only been using MACH modbus for a few months and I don't trust it very much. Seemed scary to run E-Stop thru it.

Thanks for the info.

I could just as easily go via Modbus to Mach and in reality it would not be much (if any) less  safe, the reason is as far as my machines are concerned the E-Stop to Mach is just a signal telling Mach to e-stop and thats about it as the rest of the E-Stop string is taken care of in Hardware via contactors etc.
Jeff mentioned earlier that putting limits etc via Modbus is unsafe and I agree with him if that is the only means of stopping but  even  going direct to the controller with them could still be deemed to be unsafe as you are still relying solely on software to E-Stop on a limit.
Hood

In my view, you are relying on software no matter how you arrange it. Mach is software.

Modbus is an old standard which one might assume was intended for and addressed a specific purpose when it was developed. However, now each device implements that standard, or more typically portions thereof, taking various degrees of license as they do. Mach is only one of many.

Even if you set the reliability question aside (probably just me being typically paranoid, yes?), you still have two serious risks with modbus, one being the slow refresh rate and it's tendency (in my experience thus far) to 'skip' cycles altogether. There is pretty much a guaranteed lag time which is not a good thing for an E-stop function. However, the most scary characteristic is that if it doesn't like something it just throws it away. What if that crunched up data packet in the circular file was your E-stop?

I may not have the operation of MACH modbus entirely accurate in my mind, but it is proving very difficult to get any useful information on it. Doesn't seem to me that I know enough about to be asking any really tough questions, yet . . . .  I am beginning to get the impression that few if any really have a thorough understanding of it, or at least of the fragment of it that is implemented in MACH.  Perhaps it is best left to the inconsequential applications it is typically used for.

I am not relying on Mach at all for limits or E-Stop. Limits are handled by the PLC internally and E-Stop is handled in the PLC but also via the second pole of the E-Stop switch cutting the power to the contactors which in turn cuts the power to my drives etc. The only thing Mach is doing is getting a signal and throwing an E-Stop for itself. If Mach didnt get my E-Stop signal then it may happily think it was carrying on machining but my servos would have been stopped by hardware and would not be doing anything that Mach was telling them to do.

Having said that Modbus has been totally reliable for me, I have never had a problem, most of my buttons on the control panels go via it, my lathes turret also goes via modbus, coolant on/off etc etc and not once have I seen a problem, possibly it is the hardware you are using that the problem lies with?

Hood

My comment on software was generic. A philosophical observation. Zen CNC   

However, I am reminded now of an important question related to 'external' E-stop schemes.  First let me say (again genetically, not directed at anyone) that to suggest 'kill the power to the drives' as a stand alone blanket statement, is good advise only if that advice ALSO explains the cosequenses and how to deal with them.   
 
For example, I've seen diagrams with contactors between a linear power supply and DC drives. You and I would know better than to re-close that contact before those big caps bleed down, but a noobee could loose all of his drives in a split second. I've read advice to put the cutoff between the drive and the motor, with no mention of braking the motor. What you have there is a 'coasting' axis or spindle. By following 'kill the power' advice, the user has inadvertently removed the drives ability to stop the motor, thereby creating a far more dangerous situation.

So my question is, where to you cut the power and by what mechanism do you stop the motors. I am curious myself and I think it would be good for readers to know that 'kill the power' is only half of the story.

 

Having said that Modbus has been totally reliable for me, I have never had a problem, most of my buttons on the control panels go via it, my lathes turret also goes via modbus, coolant on/off etc etc and not once have I seen a problem, possibly it is the hardware you are using that the problem lies with?

I am not actually having a 'problem' with modbus. What I am using it for now are the type of functions typically described, pendands, as well as the functions you mentioned. It is not particularly serious is it if the coolant shuts off a quarter of a second later that it should have? If you push a button and nothing happens, you just push it again. If a few steps from a pendant wind up in the trash, no biggie.

Having read the spec and learned a bit about modbus, together with my couple of years experience with MACH and 30+ years of experience with digital processes in general, I am trying to asses whether it is wise to rely on MACH's implementation of modbus for anything critical. Certain people have my ear; you are one of them certainly. Another is Papabear. He wrote recently not to use Modbus for axis motion as the refresh rate is too slow. Good advice, I recon. Somewhere between 'Do not use it' and 'It is totally reliable' is quite a range. I am leaning toward 'do not use' for critical functions. My new motor controller talks to Mach continuously over Modbus, for example, but the E-stop is hardwired from the controller to the BOB in both directions. I am using a Brain to get the Estop from MACH to the BOB pin, but Brains are extremely fast and even if they skip a beat (which seems unlikely) it would be inconsequential.  

You did not answer the question about Modbus lag time in terms of using it for E-stop. That would be high on my 'nervous list'. A lot of bad stuff can happen in 40ms.

Scott is right, modbus in Mach is no use for time critical use so if that is what you will be trying forget it, it was not meant for that but just rather to add general purpose I/O to Mach.

Regarding the E-Stop, I have mine via my controller (Scorpion or SS or ESS depending on which machine) but as said it would not matter a toss to me on my machines if it did go via modbus and had a ten minute delay. The E-Stop input to Mach on my Machines is primarily to inform Mach that an E-Stop situation has happened and not for Mach to call an E-Stop. Relying  on software to call an E-Stop is not safe to me and is not what I do but others do and are happy that way.

Regarding the way I do things, I was being specific about my machines and my hardware and not being "generic"
You have to obviously do what suits the hardware you have.
Hood

Oh just better mention something else, Brains are fast but that is just internally in the brains, they still communicate with Mach at its refresh rate (10Hz at the moment) so in reality are no faster than a macropump.

Out of curiosity, which Modbus are you using?
 I use serial Non-Plugin as I cant see any benefits to using the plugin variant and actually there is a disadvantage in that you cant directly set up the inputs/outputs of Mach  with port and pin numbers for modbus if using the plugin, in fact I am not even sure if the modbus I/O can be set/read in VB when using the plugin. Both of these can be done if using the non plugin serial interface.


Hood

I ran into the same issue you described so I am also using non plugin serial. Some of the VB macros manipulate the registers directly and relacing all of that with brains or whatever would be a lot of trouble with little benefit since the plug-in modbus is no better in the aspects that are important to my app.

Now then . . . I had no idea the brains were that slow! They seem extremely fast to me. I pull Z or Y axis position from Mach and use it to calculate the 4th axis RPM based on the SFM the user wants. Just based on visually observing the update rate (i.e. how many steps are in the RPM delta), the brain seems like it is real time. By the time the data slogs thru Modbus, it is in sort of big chunks, but the brain itself seems to be breathing in data very fast. I'll need to look at that again.

One of the workarounds I mentioned was to take two data chunks from modbus, say 150RPM and then 220RPM and calculate 8 to 10 'tweens' to provide a much smoother transition while waiting for the next chunk. So I am actually intoducing some lag outside the modbus, but the 4th axis arriving at commanded RPM 40ms late is incosequential. The controller then sends the 4th axis current RPM data back to MACH for display on the MACH screen. So there is a real world example of one of my current uses of modbus.

There is some documentation somewhere that implies that TCP modbus can access vaiables, and there are separate commands juts for that . . . . but none of the commands actually work, so no help on that front either.



 

It may be that the Brain can communicate directly over modbus at the Brains speed, I dont know. I do know however that anything going to Mach from a Brain is at the 10Hz update of Mach, or at least thats what I have been told on several occasions by the high heid yins.

Hood