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

 

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.