Abstract
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.
Products
ST-IPm-8460\VT-mIPm-138-D\VT-mIPm-248-D
Use Case: Use troubleshooting functions to monitor and automatically report trouble in communications via Modbus protocol
Required Software
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. |
Practical Applications
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....
- Especially across radio links you will not see a data fail, but the entire time you are getting multiple retries across your network for various reasons. This indicates either a signal loss situation or potentially a high noise to signal ratio...
- If you are just using the Success and fail to calculate a success percentage, you will never see all of these retries
- On cellular networks if you have a marginal signal strength or a high noise level on the antenna, that will cause retries as well. Again, you may have great success rates but high retries which still indicates work needs to be done on the cell tower signal strength. If you are using a cellular connection, it is recommended that you read and datalog the cellular signal level if your modem supports Modbus
ModbusTCP and ModbusRTU Error Codes
Slave: last error: The Number below indicates the detected error
- 0 = Ok
- 1 = Modbus function not supported
- 2 = Invalid Modbus Address
- 4 = Modbus Server Failure
- 6 = Server is busy
- 8 = Data Parity Error
- 10 = Invalid gateway path
- 11 = Gateway Target Failed
- 128 = Communications Timeout
- 129 = Bad CRC16
- 130 = RS232 communications error
Practical Applications for Modbus Errors
- 1 = check the register type you are trying to use to get your data
- 2 = This is typically the Modbus node address/station number is set wrong
- 8 = The data parity setting is wrong
- 128 = Increase your timeout on the retries as you may have a slow responding device on the other end
- 129 = If you get a bad CRC this is typically an issue of broken packets/malformed packets, be sure your firmware is up to date, and this may necessitate using Wireshark to packet capture to see what register is causing the issue.
Boolean Commands
|
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. |
Practical Applications
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
How to Add the Commands for communications monitoring
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.
Red Lion Work Bench UDFB's
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.