Isn’t it just always the case? You brag about something and it completely turns around. Phoenix temperature was 110 when I blogged on Monday; now on Friday we may get all the way up to 70… and rain – very unusual for this late in May. Ok, back to PROFINET. The final point I wanted to respond to from a Raleigh course evaluation form, a very-well presented something new:
“PROFINET (and any fieldbus) communication system needs a diagnostic tool for idiots. A simple, generic plug-it-in-here hand held terminal that will tell a third shift mechanic where the problem is. This is a person that does not have access to a laptop and “programming” software. This person at most has a DVM. The troubleshooting tools you show are aimed at an engineer doing the troubleshooting. I do not want to have to go into the plant at 3am to troubleshoot the problem with a laptop.”
We do show tools that are intended for use by an engineer. But some of the things we showed can help that third shift mechanic without requiring any other devices! This is something we were obviously not explicit enough about. We showed Wireshark, a tool for examining Ethernet frames. This is obviously not a tool for the mechanic. In fact, it’s unlikely to be needed by the user engineer unless the problem is really, really esoteric. It is very much needed by the developer of control devices with a PROFINET interface though.
There are several “tools” we talked about that can be used to provide information the third shift mechanic needs and that information can be presented on the HMI – no plug-in hand held needed! There are two enablers for this capability; they are really not separate “tools”: SNMP from the IT world and PROFINET IO diagnostics from the automation world. First though we need to point out where the potential network problems are. Mostly they’ll be device failures or network problems caused by cabling problems, etc.
Device failures can be diagnosed in the controller and displayed on the HMI. For example, a module within a remote IO rack fails. We demonstrated how this can trigger an alarm during the class. [In future classes, we’ll add showing this in an HMI to make clear this point.] What if the device that fails is an Ethernet switch? I recommend using managed switches with PROFINET IO capability built in. (You can use an unmanaged switch without PROFINET IO capability, but finding a problem is going to be much more time consuming.) You can use the same PROFINET IO diagnostics to find a problem with a switch and react to it in the controller and display it on the HMI. Switches with PROFINET IO capability are available from several manufacturers.
Diagnosing network trouble can be pursued one of two ways: SNMP or PROFINET IO. PROFINET IO functionality can be handled the same way as for device failures. SNMP can be used in the IT way independently of the control system – just Google “SNMP Tools”. Or, better, bring the information available via SNMP into the HMI using OPC. One way to do that is to use an SNMP OPC Server like the one from PTO-member Kepware. Another approach would be to use a separate software program from Network Vision: IntraVUE.
For further reading on SNMP, I recommend the article “Engineer or Network Administrator?” in Automation World.
I blogged previously on other tools, but I know there are others out there. If you know of one, please comment here.