Trying to find a way to notify user if modbus connection dies for any reason.

Docs on MACH's modbus implementation are sparse and I don't find any way to query MACH for Modbus status.

The application is to be able to E-stop MACH from an external source if the Modbus com stops for any reason.

If it is not possible to query MACH, then what methods are people using to monitor the connection?

A character could be sent and retrieved by the slave and a hardwired signal used to notify the user of a problem, but it seems there should be a way to query MACH.

The most basic use of Modbus is probably Feedrate override, since Mach by itself does not do analog/digital conversion.  When the feedrate pot quits working, the PLC is probably not getting power, but Modbus is still working. The "slave" is just out to lunch.
Other indicators, will be the various inputs handled by Modbus do not work, however this is not really an emergency situation; just another bump in the Mach3 road.
I find the Modbus functions I use (Jog rate, Jog step size, rapid rate, feed rate, various screen buttons) to be very reliable and just putter along in the background. Once you get the various buttons, pots, and brains working right, you tend to forget it's there.
I have not heard of "Modbus" quitting outright. 
You could have a relay in the power circuit going to the PLC, and if power quits activate a signal, but this sounds to me to be a "solution looking for a problem"

On re-reading your post, you want a way to query Mach to see if ModBus is working. It is easy to read past some things

True, when your Mach screen comes on and everything is just sitting there, there is NO indication ModBus is working. However, the nature of ModBus is the Main program, and the ModBus cpu do communicate, but it is a "I am waiting for you to send me a task...."

Until the Master sends a command, the Slave just waits. The Slave does not initiate communication. However, they are always in touch!

The Mach3 program has the ModBus set-up addresses in it's memory (the actual block of code is in the Macros folder simply named Modbus), and the PLC cpu has a program in it's memory, which includes all the ladder logic you have decided on. The functions peculiar to Mach3 have to go through a "Brain" to cause an action, but the PLC can also be doing functions in concert like turning on the appropriate relays, led's etc.

The protocol for the communication is what makes ModBus what it is; a standard set of rules which govern all types of I/O communication; analog to digital, digital on/off, a timing loop, or what ever you need to be done in a given circumstance.

I twiddle the feedrate potentiometer back and forth at start-up, to verify everything is working. If the slider on the screen goes up and down, I am happy

Sometimes, nothing happens for a particular I/O; then you just look for what you may have changed; re-written a brain, and did not activate, etc.

Funny, I thought I had replied to your first post, but it does not seem to be here. Hmmmmmm.

I have reviewed the modbus standard and am familiar with the basics. The standard is quite old and not particularly sophisticated. As you correctly point out, the slaves are passive and that is why the monitoring would be best done by the master and there are some devices which do that. Unfortunately it appears that Mach is not one of those. Something as simple as access to the timeout flag, or equiv, would be very useful. I already time each modbus loop, so that is the trigger I am using, but I would prefer something more 'closed loop'.

My application is shown here: http://www.youtube.com/watch?v=vBLuF_F2_qs

This was the first prototype and it has undergone further development and has a lot of new features, but fundamentally, it could be considered an external  quasi axis. In INDEX mode, it has the protections of the built-in system E-stop, but in LATHE mode the reliability of the Modbus com becomes critical.
 

Hello Simpson:
I did watch your video, and you have an interesting setup. What exactly is it that you need Modbus to watch for, and E-stop the system in Lathe mode?
Just curious.

 

E-stop is already hardwired in both directions. If Mach E-stops, the 4th axis E-stops and vice versa. I do not rely on Modbus nor Brains for that.  The controller can operate from screen buttons and also collects Y and/or Z position data and acts on that data. With the functions that the controller and 4th axis perform now, the time lag require to 'surmise' that there may be a modbus issue is probably not going to have dire consequence, but I have other features in mind that would not be tolerant of packets being 'thrown out' as is the modbus spec.

Documentation of MACH's modbus implementation is all but nonexistent, which implies (to me, anyway) that it is intended for the types of inconsequential uses that you mentioned. I am not asking for advice on my projects, but I would like to know some details about MACH modbus, so I'm just asking questions to try to determine if it is a dead end before I go too far down that road.
 
Pappabear and Peter Homann have written some very good papers on MACH modbus, but neither touched on monitoring. Pappabear's, which delved deeper into the topic, had as much to say about the limitations as the capabilities, it seems. That is very useful to know, but not particularly encouraging. Kudos to Himmy for the programmer's reference, but the modbus was barely acknowledged, and to my knowledge there is no official documentation other than a couple of videos.

Simpson:
Thanks for the explanation. Agreed, the info regarding Modbus on the Mach forum is sparse.
My entry into Modbus was by way of the Cubloc PLC. I suggest downloading the Cubloc user manual as it has a chapter on Modbus, with over ten pages of detailed data about how Modbus works, and what the different functions can do. plus some example code. They have code examples in ASCII, and Binary. 

Based on one of your earlier posts, I already checked out the Cubelogic, but I am not keen on basic, nor ladder.

I am using an Arduino Mega 2560, which is the top level Arduino and it is adequate for this project. I looked at Atmel and PIC. PIC owns the low end, but I think Atmel has a better defined path to their higher end XMEGA and above. Some folks are looking to graphics processors to run not only the graphics, but the entire app, and I'm looking hard at that path. 

There is lots of modbus code floating around for the Arduino stuff. I have TCP modbus working on it, but MACH's implementation has some additional restrictions, so I am not using that flavor.