DoMore Modbus issue?

[willpoll]

I have an application where a DoMore H2 PLC is polling 2 modbus slave RTUs via a 900 MHz radio, 5 seconds apart.  Most of the time the data is perfect, I am using SUBSCRIB to convert floats to Reals within the PLC.  However, on certain polls the data coming back appears to be corrupted.  My well level comes in as a negative number, which is not originating at the remote RTU as I have filters and limits in place to prevent this.  I believe the modbus stream is missing one or more registers or has an extra value that is causing things to be transposed.  Also, during these times the Success bit is cycled on and there are no exception responses being reported by the MRX modules.

SERIO-4 serial port A is set to Modbus RTU Client, 0 retries, 2000msec timeout, 5000us inter packet delay.  Baud is 9600,N,8,1.

Does MRX fully utilize the checksum to validate a modbus packet?  Is there something I'm missing.

As I said it works for 15-30 minutes with no issues, then Scratching my head so much it's starting to bleed.

Thanks!

[ATU]

Could it  be the radio?  If the data is critical and you have cycle time, I would read the data multiple times and do an integrity check.  Throw out anything that is not within a normal fluctuation.

[willpoll]

Yes, it's very likely the radio getting interference, it's in a non-licensed band. 

My point is, isn't that the point of the checksum in ModbusRTU to calculate what the checksum should be based on number of words and values received.  If it doesn't match the received checksum that was calculated by the transmitting station, you reject the packet. 

My question is, does the MRX function do this?  Why are there no exception responses and why is the success bit being turned on?

Thanks,

Will

[ATU]

I don't know, I mostly do Modbus TCP/IP . Is rock solid on the BRX.

[BobO]

Yes, it's very likely the radio getting interference, it's in a non-licensed band. 

My point is, isn't that the point of the checksum in ModbusRTU to calculate what the checksum should be based on number of words and values received.  If it doesn't match the received checksum that was calculated by the transmitting station, you reject the packet. 

My question is, does the MRX function do this?  Why are there no exception responses and why is the success bit being turned on?

Thanks,

Will

Modbus TCP doesn't use CRC because it is handled at the Ethernet level. Modbus RTU uses CRC16 and it is definitely checked. If there is a CRC error the data isn't kept and the system error value should be getting set to 21.

Are you monitoring the Error bit with logic? I like to add it to a rising edge contact that drives an INC. I'll do it for Complete as well when I'm monitoring the health of the comms.

[willpoll]

So, I realized I was using MHRs, and that is not advisable.  Moved all my data to N registers.  Problem is still occurring.  I do plenty of comms using ModbusRTU over RS485 with no issues, so I'm guessing it's related to being on 900MHz radio.

Could it be overloading the SERIO4 card.

Port A RS232 9600 Baud ModbusRTU Client - polling 2 remote RTUs, address 129 and 130, 43 and 47 registers each over 900 MHz radio
Port B RS232 115200 Baud ASCII protocol - querying a cell modem for signal strength, etc.
Port C RS485 19200 Baud ModbusRTU Client - polling 2 VMX Soft Starts and 1 Pulsar Level transmitter

[willpoll]

BobO,

Where can I find this system error value?  The D register I set for exception reporting in the MRX is fixed at 0.

-Will

[Bolt]

So, I realized I was using MHRs, and that is not advisable.  Moved all my data to N registers.  Problem is still occurring.

It doesn't really matter that you are dumping the data into MHR, it's only bad form in that it takes up space there I suppose.  I do allot of my Modbus TCP and RTU into the MC/MHR blocks, I find it makes for decent organization for my needs.

BobO,

Where can I find this system error value?  The D register I set for exception reporting in the MRX is fixed at 0.

-Will

It should post to the Exception Response D register you enable in the MRX instruction box.

Exception Response : enable this selection then enter a memory location to store the Modbus Exception Response for thisinstruction. This can be any writable numeric location.
Except for broadcast messages, when the MRX instruction sends a query to a Modbus server it expects a normal response. One of four possible events can occurfrom the query:

1.If the server receives the query without a communication error, and can handle the query normally, it returns a normal response.
2.If the server does not receive the query due to a communicationerror, no response is returned. The MRX instruction will eventually processa timeout condition for the query.
Note: the timeout value is defined in the ModbusTCP Client or the Modbus/RTUClient.
3.If the server receives the query, but detects a communicationerror (parity, LRC, or CRC), no response is returned. The MRX instructionwill eventually process a timeout condition for the query.
Note: the timeout value is definedin the ModbusTCP Client or the Modbus/RTUClient.
4.If the server receives the query without a communicationerror, but cannot handle it (for example, if the request is to read anon-existent coil or register), the server will return an exception responseinforming the MRX instruction of the nature of the error. This exceptionresponse value from the server can optionally be stored in a memory location.

There is a "Modbus Exception Response Codes" section in the help file, and the value 21 that BobO was referring to earlier doesn't appear in the table.

[willpoll]

Thanks Bolt.

I found all that info in the manual, I didn't see 21 either that's why I thought maybe there was another error value I should be looking at.  Since this value is never anything but 0, I made some ridiculous calls to the server and never got any exceptions, could be the device doesn't support it.

In which case I have to base all error checking on the 'set bit on success' output of the MRX.  I am using a leading edge trigger on this bit to call a subroutine that actually parses the Modbus message into usable data, however, I'm still seeing bad data make it through.

Some of the examples in the help file use casting...to force the N-register to act as an unsigned word, I suppose.  I've implemented this,hopefully it'll yield an uneventful weekend.

-Will

[willpoll]

No luck with the N's cast as unsigned. Switched to V's but issue is still occurring.

-Will

[ATU]

Have you looked at any of the packets? You would need a serial analyzer for this. Sometimes its the only way to tell what is going on.

[willpoll]

I believe what is happening is I am receiving a packet that is missing or has extra characters, causing data to be transposed.  It's hard to see with floats as they are encoded across to words.  I am adding some integer constants to the transmit array on my RTU to make it easier to spot, i.e. word 4 should always equal '7', word 45 should always equal '11'.  If I see these values moving in the receiving V registers on the DoMore, I'll know. 

Also, I can use this same logic to reject packets if I don't see a 7 and 11 where I expect them, just reject the whole packet and don't update any values.

I'll let you guys know the outcome.

-Will

[ATU]

I know in the past, when debugging serial protocols, it saves a lot of guesswork if you can capture the packets.  I have been surprised on more than one occasion.
I wonder if something like this would work? https://www.express-inc.com/BB_9PCDT_p/bb-9pcdt.htm

[willpoll]

Adding my own error checking as stated before seems to have done the trick, I'm not sure how but it seems like some packets were making it through the MRX checksum. 

It's possible both RTUs were adding/removing words from the packet before calculating the checksum and sending, but I've never seen this behavior from these RTUs before.  The radios I'm using Digi XTend 900 MHz are simple serial, data-in data-out, radios and know nothing of Modbus, so I know it's not the radios changing packets.

These sites are geographically separated so it's near impossible to monitor both ends.

For now I have it working adequately, so I'll leave it alone until I have more time to spend on it.

-Will