This technote will show you the built in communications troubleshooting variables built into all drivers in the Red Lion Workbench when using ModbusTCP and ModbusRTU. see you These can be used to greatly enhance system performance and stability and to alert you automatically if your communications.
ST-IPm-8460\VT-mIPm-138-D\VT-mIPm-248-D
Red Lion Workbench version 1.0.3 or greater.
We will start with a block of IO already built into the Red Lion Workbench. We will then concentrate on adding in the communications monitoring capabilities of the ModbusTCP driver.
Below is a list of the communications monitoring functions that are available for ModbusTCP and RTU.
Please know that these variables need to be either a float or a Long float (Double Precision Float). to be used in communications math functions and with the Red Lion Workbench UDFB "CommStats" block
|
Error report |
The variable is set to an error value when the last unsuccessful exchange is performed on the request. It is reset to 0 on the next successful exchange. |
|
Error report (set only) |
Same as upper, but the variable is not reset by the MODBUS stack. The application is in charge of resetting the variable. |
|
On-going request |
The variable is set to 1 when the request is sent to the slave and reset to 0 after either an answer from the slave or a timeout. |
|
Success counter |
The variable is increased each time the request is exchanged successfully. |
|
Fail counter |
The variable is increased each time the exchange of the request leads to an error. |
|
Retry counter |
The variable is set to 0 on the first trial and increased each time the request is retried. |
|
Slave: last error |
The variable contains the error code of the last error detected on this slave. |
|
Slave: last error date stamp |
The variable contains the date stamp of the last error detected on this slave. |
|
Slave: last error time stamp |
The variable contains the time stamp of the last error detected on this slave. |
|
Slave: last reset date stamp |
The variable contains the date stamp of the last "reset" action performed on slave counters. |
|
Slave: last reset time stamp |
The variable contains the time stamp of the last "reset" action performed on slave counters. |
|
Slave: transaction counter |
The variable is increased on any new exchange performed with this slave, whatever the exchange is successful or faulty. |
|
Slave: failed transaction counter |
This variable is increased on any new faulty exchange with this slave. |
On-going request: You can use this to monitor if the RTU is sending out requests and just not getting an answer back. This could indicate either networking or configuration issues on the RTU or end device
Success Counter: You can use this floating-point number as part of a logic section to calculate communications efficiency and also establish communication alarm settings and parameters.
Fail Counter: See Success Counter
Retry Counter: This is probably the best diagnostic tool in the box. Here is why....
Slave: last error: The Number below indicates the detected error
|
Command (enable) |
The request is sent continuously as long as the mapped command variable is TRUE (or not zero). |
|
Command (one shot) |
The request is sent only once when the mapped command variable becomes TRUE (or not zero). The variable is reset to 0 after the exchange. |
|
Reset counters |
The request counters are reset to 0 when the variable becomes TRUE (or not zero), and the command variable is then reset to 0. |
|
Slave: reset counters |
The slave counters are reset to 0 when the variable becomes TRUE (or not zero), and the command variable is then reset to 0. |
Command Enable: This is a triggered send. For example, a write to the DOs could be controlled thru code by using this command.
Command Oneshot: If you only want to send something once and then have it automatically disable itself.
Reset Counters: Use this to reset the comms counters back to zero. Useful if you are trending the communications statistics in a Scada system and want to reset them at midnight or some preset time
Slave: Reset Counters
Again, this is predicated on the fact that the remote IO is already configured and now we are going to add in all the communications statistics .
Start by choosing to add a variable- Remember this as all functions start here.
After this a popup box will appear that will show all of the choices you can make. Again there are 3 recommended functions to be added here and they are Success, Fails, and Retries. With these 3 functions you can calculate communications success statistics and also keep track of the retries which "may" indicate an issue in your comms but not bad enough to cause you comms loss/failures.
You will need to set the function to Status/Control as shown in the screenshot above. Please note that the symbol name can be anything of your choosing as long as it does not violate the limits of Red Lion Workbench naming structure.
It is recommended to make all communications counter as LReals so you can let them run as long as possible without having to reset them or them rolling over.
You will also want these to be global parameters so you can monitor them with an HMI or SCADA system.
Now lets proceed to using Failure and Retries along with the screenshots.
Now lets configure Retries...
We now have all 3 of the main variables available for us to use in code to calculate the success, failure, and retries, percentages. You can now use these percentages to triggere various alarm levels in your plc code.
Another good general-purpose use is the Modbus Error codes.
Unlike the others, this one will be an integer
Using the above variables to detect our communications efficiency, you can now determine success, fails, retries, and even get the driver failure codes to know where to start looking. As communications is always one of if not the hardest item on a project to get right, these functions can help you DRAMATICALLY speed up the troubleshooting process and root cause correction.
User Defined Function Blocks are easily created in Red Lion Workbench. One of the factories built UDFB's is the CommStats block. Below is an example. This block will calculate the successful percentage of the communications for each remote slave device it is used for. Look for a coming link to the block as our technotes are updated.
