Modbus transaction status?

[Merle]

When entering Modbus operations in the Register/Coil table there is a Status field for each operation.  According to the help file, the Error Codes for this status parameter is listed below:

However, when using one of the "Aperiodic Triggers", they also have a status parameter which is listed in the help file as:

Can someone explain why these are different (different error codes)?  And how they are supposed to be used?  Is the Operation Status meant to be specific to that operation and it is updated (and tracked) each time that operation is used?  And the Aperiodic Trigger status is just for that particular transaction (no matter what the operation is)?

[Merle]

UPDATE:

Ok, so I've confirmed (I think) that the first table is linked to the status of the actual modbus operation, and the second table is linked to the status of the specific modbus transaction.  And if a transaction takes place, the status of the periodic/aperiodic transaction (2nd table) is updated and so is the status of the actual modbus operation (1st table) used in that transaction.

I found a third status code table which is apparently also the status of the operation (like table 1), but it has an extra line (-2 = Slave Messaging Suspension).

This -2 status code adds some explanation to what I am seeing but also some confusion.

In my basic testing I am just sending modbus messages from the PLC to a terminal.  The terminal is not providing any responses, so the transaction times out as expected (status code -11).  When I look at the Transaction status it is -1 = Modbus Protocol Error, which in the table says the actual error code is stored in the Operation Status.  The operation status code is -11, indicating a timeout which makes sense since the message was only received by a terminal which did not provide a response.

Where the confusion comes from is, when sending messages back-to-back, I have to wait at least 3.6 seconds between failed messages.  I say failed messages because they are all timing out (error -11) since there is no response.  I have a 500ms Response Time configured for the Modbus master.  So, the required 3.6 secs between transactions would indicate that this 3 second Slave Messaging Suspension (error code -2) is being enforced.  (3 secs + 500ms Response Time + 100ms overhead = 3.6secs).

So why would this be the case?  Since I am not getting an error code -2, why is this 3 second suspension being enforced?  Is this 3 second suspension being enforced at the Master by preventing all transmissions for 3 seconds (without reporting an error code -2) - there is no real slave connected to enforce it? 

If anyone can shed any light on this for me, please do.  I'm about ready to give up on Modbus with this PLC

Thanks.

 

[Flex727]

Have you elevated this to Unitronics Support (support@unitronics.com)? Keep in mind that this is a user forum staffed by volunteer users who for the most part are not Unitronics employees. Most of the people here do not have the type of specialized knowledge you are seeking. In any case, I recommend patience as most forum members likely don't check this board every day.

[Merle]

Sure I get that. 

I haven't elevated to Unitronics support because I just assumed there is something rather simple I am missing or doing wrong, which I thought someone could point out and put me on the right track.  I am assuming the issue is with me and my understanding rather than a software issue or something, so just trying to avoid submitting support request prematurely   And to be perfectly honest, I am quickly running out of time, and I thought the forum might be faster as well.

[Joe Tauser]

The three second recovery probably has something to do with your Retry count setting.

My experience has been that the specific modbus error codes you describe above don't always get set they way you think they should.  I spent a huge amount of time trying to simulate errors between the PLC and another device and then trying to figure out the timing and value of the error codes, just as you have.

Are you experiencing errors when trying to communicate with a device or are you just trying to interpret what the PLC response is when firing commands to a dumb terminal?

If you're just trying to observe PLC behavior with a PC, I'd Google "free Modbus simulator" and put that on your PC.

If you're just trying to get a more real-time monitor of the communication status between your PLC and the actual device, I'd abandon the Status column in the Modbus Table and go straight to the source - the Modbus Remote Slave Status word.  It changes its value to 2 or 3 pretty quickly when communication is lost and will reset itself back to 1 when communication restores itself.

Joe T.

[Merle]

@Joe Tauser

I was trying to communicate with an actual slave device, which works for single commands only.  If I try to send multiple commands within a relatively short period of time is when the issues appeared.

Right now, in an attempt to understand the issues better, I am just sending Modbus messages to a terminal, playing with the timing and monitoring the status codes.  All messages generate errors since there is no actual slave connected to provide a response.  My confusion is "Do all failed messages/errors generate this 3 second suspension?"  So anytime I get a status code back other than zero, do I need to wait 3+ seconds before attempting another message?  Otherwise, the next message receives a status code of -2.  I may be answering my own question here a bit - but the documentation is far from clear on this.

I have been monitoring the Remote Slave Status and yes, it is 3 most of the time since the messages are timing out just going to the terminal.  Good advice on this one.  Much easier to monitor this one status than the status of each transaction.  The only issue with monitoring this slave status is it does not reset after the 3 second suspension.  So, you have no idea if it is ok to try again unless you use a timer to track the 3 seconds.  Would be nice if this (or another) status bit reset to indicate it is good to try again.  Right now, as far as I can tell, the only way to know if it is good to try again is to actually try sending another message.  You could possibly get yourself in a situation where you can never transmit again if you are not waiting long enough between failures.

I did try a simulator, but the couple I tried only allow a few messages through before is stops (demo mode).  Haven't found a good free one.  I'll look again.

Thanks.

[Joe Tauser]

10 minutes ago, Merle said:

I was trying to communicate with an actual slave device, which works for single commands only.  If I try to send multiple commands within a relatively short period of time is when the issues appeared.

Have you tried setting up an Aperiodic Batch Operation?

Joe T.

[Merle]

I did try the "Aperiodic Indirect Group Trigger" but that did not work.  I did not successfully try the Batch Operation - basically I was unsure how to use it based on the documentation.

Whatever method I have tried, it seems to come down to anytime there is an error, the Modbus Master blocks all communications for 3 seconds.  

What I am trying to do now is monitor the Remote Slave Status (as you suggested) and when it is anything but 1, wait for the 3 seconds before I allow anymore communication attempts.  The issue with this is of course the status does not reset on its own after the suspension, so you have to figure out when it is ok to try sending another message which will bring the status back to 1.  Easy in theory, but not so easy in practice as I am finding.

[Ausman]

I'm a Non-Unilogic user, but I agree with Joe that it sounds like a retry length issue, which can be a problem if not correctly set up to allow for the time errors take to run out of attempts on the current request before trying another.  Are you sure that retries and numbers of them are being allowed for, or better yet for testing purposes, there are none?  Perhaps there is a setting squirreled away somewhere that you have forgotten?  Or don't know about?  We all learn something new each day!  😉

Question for my learning...is this 485 or TCP? I don't know the table source due to not having Unilogic.   If  TCP, could the plc be dropping the ethernet connection for some reason, and it's not actually a modbus issue at all?  If 485, bump the timeout UP a bit and see what happens. And also, is this involving the device that does addressing in hex?  Just curious.....

cheers, Aus

 

[Merle]

@Ausman

I am using rs485 (Modbus RTU).

As far as I can tell, there is no way to configure Retries or control the timing for multiple Modbus transactions.  Not that I can find at least.  There is a Response Time option for the Modbus Master which essentially decides how long the Master will wait (default = 500ms) for a response before it quits and generates a timeout error condition.

I am using a UAC-CX-01RS4 expansion module for the PLC to give me the required RS485 interface capability.  There is a single option that can be configured for this module which is the "Delay Time (ms)".  There is no documentation that I can find on what this option actually does.  Is it an intercharacter delay for the RS485 comms - probably??  This defaults at 0, but changing this will only slow down the transmission (probably) - you will still get the same errors if it times out or generates another error.

The only way I can see right now, to make this work reliably, is you have to manually control the timing between multiple transaction to ensure there are no collisions (issuing an aperiodic operation before a previous one is finished).   And also waiting the 3+ seconds when an error occurs to let the suspension expire before attempting another transmission.   I'm also unsure if ANY error causes this 3 second suspension as well or is it just certain errors?  Not indicated in documentation - so I have to assume any and all errors cause this suspension.

It seems a bit cumbersome to have to do this.  I expected (or assumed I guess) that the UniLogic Master would handle more of this for you, but I guess not.

[Ausman]

I've been squizzing at the specs for that module, and a question is what baud rate are you using?  Does changing the rate change the timings you're experiencing?  Start low and speed up for the tests.

And questions which might sound insulting, given it sounds like you know what you are doing.....  Are the correct resistors in the correct place, and/or the  unit's termination set correctly?  Is the cable a quality one? 

cheers, Aus

[Merle]

No worries.  At this point I am happy to be questioned on anything

The link is terminated correctly.  The baud rate I'm using is 115.2kbaud.

Just to clarify, for debugging purposes and to try to understand the Modbus errors, I'm not even connected to a slave device right now.  I'm just transmitting to a terminal app on a PC.  I have not seen any communication errors at all - by no errors I mean no bit or byte errors.  All commands that are transmitted are received at the terminal properly formatted and with correct CRC.

The issue appears to be when the Modbus Master determines there is an error (either because there is no response or because the next transmission happened too quickly before the previous one has timed out - within 500ms).  So , it's not so much a comms issue, but more a protocol issue I'm dealing with.

 

I've been discussing with Unitronics support, but I have to question their responses.  They are claiming that the only time there is a 3 second suspension by the Master, is when a transaction generates a -2 error code.  However, when I try to send three transactions in a row, with a 1 second delay between each, it does not work.  The first command times out (as expected since I am not trying to respond) and generates an error code -11 as expected.  However, the second command does not transmit at all and generates an error code -2 even after waiting a full second.  Since the 1 second delay between 1st and 2nd commands was not enough, this leads me to believe that the -11 timeout error also caused this 3 second suspension in the first command.  If I increase the inter-command delay to 3.5 seconds it works, which again leads me to believe the 3 second suspension is being generated by the timeout even though Unitronics support says it does not.  

I know from the documentation that the -2 error does cause the 3 second suspension (maybe others too), but what they have been unable to tell me is what actually causes a -2 error to occur?  What is the condition that generates it? 

[Ausman]

9 hours ago, Merle said:

but more a protocol issue I'm dealing with

Yes, I get that, but perhaps the protocol or something else has an error that relates to baud rate in use, and the way to check is to run different ones to see if it changes something.

[Merle]

ok.  I can certainly give it a try, but I haven't gone down that path since I am monitoring all transmissions from the Master and there is never any invalid data.  And there is no slave connected to give a response so wouldn't be generating any baud issues in responses/receiving anyway.

[Merle]

I've tried the same setup all the way down to 9600 baud.   Performs the same - no comms errors, but same Modbus issues.

My issues come down to not being able to transmit after a timeout (error -11).  I know that when I get a Modbus operation error = -2, that means the slave messaging suspension is being enforced so you have to wait 3+ seconds before attempting another Master transmission.  The issue is when I get a timeout error (-11) - how long a delay (if any) are you supposed to have before you try another Master transmission?  Unitronics claims this 3 second suspension only happens after a -2 error, but in my testing, if I get a timeout error (-11) and try to transmit another command with the 3 seconds, it THEN causes the -2 error.  This seems to indicate that ANY error causes the 3 second suspension and the -2 just reports to you that you are still within this suspension state if you try another transmission.  This is of course contrary to what Unitronics support is telling me, but its the only thing that makes sense.

[dierkens]

2 hours ago, Merle said:

ok.  I can certainly give it a try, but I haven't gone down that path since I am monitoring all transmissions from the Master and there is never any invalid data.  And there is no slave connected to give a response so wouldn't be generating any baud issues in responses/receiving anyway.

There's a big difference between sending MODBUS commands to a device that doesn't care what you send it and sending it to a MODBUS device.   

For testing purposes I'd do as Joe recommended and get the software setup correctly with no errors and then fault it out and see what you get for responses and such.

The different errors are going to cause a different timeout.  A CRC error for instance is a lot different than a "I can't find the device anywhere" error.    One is a pure communication error and the other isn't.   

[Merle]

Here is the latest in case anyone else runs into this:

So, after claiming otherwise for more than a week, Unitronics support is now saying that in fact ANY and ALL Modbus errors cause the master to enforce this 3 second messaging suspension.  So even a -11 timeout error (or anything else) will cause this 3 second lockout and the -2 error code just reports that the master is in this suspension period.  This matches the results of my testing, and I really could not understand how it could be any other way.  They claim that attempting a transaction and receiving the -2 error code does not reset the 3 second suspension (although I'm not completely convinced of this - will need to try it for myself since I'm fairly sure I have results that prove otherwise).

There is no indicator or flag you can use to check the state of the Master (which is a bit lacking) - the only way to check the state is to try another transaction and see if it works.

They did specifically say that this suspension applying to all errors is the case when you are using serial comms (Modbus RTU), so it may well not be the case if you are using Modbus TCP.  Not sure?

Would be awfully nice if this stuff was properly documented in the help file ....