Modbus over RS-485 for SLC 5/05

I keep getting this error. I'm not sure why, I have not changed the firmware on the OS(Still FRN 13 according to the embedded web page). Any advice?

From this, it looks like the rising edge of a MSG instruction input rung only buffers it into what amounts to a FIFO queue, and the execution (service?) of that transfer will occur when the CPU gets to it i.e. asynchronously. Everything else happens under the hood, so to speak, after that, with various bits (.EN, .EW, .DN, .ER) available to track the progress and e.g. ensure another is not queued until the first is done, results in an error, times out, etc.


So queuing four MSG instructions at a time, even on the same scan, would not seem to be a problem.


That said, this is only from reading a manual; I have never actually done it. The worst you can do is try it out.

Your project might still have the chosen processor with a lower firmware version. That being a warning and not an error, you can probably ignore it. I suspect that if you change the controller type to the newer firmware version, the warnings will stop.

If you do that, pay close attention to the message that follow, RSLogix will offer to clear the I/O memory and adjust data table sizes. I almost always say no to that 2nd option so the software doesn't erase my spare data table space that I like to keep available for online editing.

EDIT: My RSLogix 500 version 12 only gives me controller options for SLC 5/05s that are "FRN 10.0 or higher" so, you may always get those warnings and can just ignore them. I have a project using a SLC CH0 as a Modbus master from about a year ago I will dig up and see if I get those warnings when I verify it.

Ken Roach said:

What is the Modbus data that you need to read ? In general the most efficient thing to do is use just one message to read a block of Modbus registers.

I think the SLC implementation might limit you to 255 holding registers at a time, since that's the maximum SLC data table size to use as the destination.

If you have to read multiple blocks of registers, or different types of data using different Modbus commands, I typically write a simple state machine to increment an index register, and use "Index Register equals X" to trigger an MSG instruction. Some folks prefer to "chain" together their MSG instructions so that each /DN bit triggers the next /EN bit, but that sort of logic takes more work to revise when you want to change the order of the messages.

Click to expand...

I wish to read ints. I am not too concerned with the chaining method since I'm only reading a handful of registers from 2 modbus slaves and the order won't really need changing after I get it working.

Yes, my project using Modbus to poll Phoenix Contact TWE with I/O gives the same warnings. It might be a good example of how to poll multiple nodes for you to follow.

You can safely ignore those warning messages; they're just a nuisance because RSLogix 500 doesn't distinguish between FRN 10, 11, 12, 13 (and probably never will).

Modbus RTU doesn't have Transaction Identifiers in the protocol like DF1 does. If you send four DF1 messages to a slave device, it doesn't matter what order the replies come in because each reply will have a TNS value that matches the request.

Therefore with Modbus, I'm not sure if you can push even four messages into a FIFO. I would program them to execute only one at a time.

Since you want a bunch of different data spread around from registers 1 to 28, i would probably setup the modbus read as one message to read registers 1 to 28 inclusive. Then in plc code you can do what you want with the values of interest and just ignore the unneeded values. This would mean only needing to setup one MSG instruction and not having to deal with tge nuances of interlocking multiple messages.

g.mccormick said:

Since you want a bunch of different data spread around from registers 1 to 28, i would probably setup the modbus read as one message to read registers 1 to 28 inclusive. Then in plc code you can do what you want with the values of interest and just ignore the unneeded values. This would mean only needing to setup one MSG instruction and not having to deal with tge nuances of interlocking multiple messages.

Click to expand...

I agree with the idea of reading 28 words. Since you have two slaves, you still should interlock them and I would at least use a timer to control the alternation. Use the DN and ER bits from one message to trigger the mechanism to move on to the next message. My 16 message state engine I mentioned earlier is overkill for what you are doing since it includes stuff to disable slave comms, error counters and other things.

OkiePC said:

I agree with the idea of reading 28 words. Since you have two slaves, you still should interlock them and I would at least use a timer to control the alternation. Use the DN and ER bits from one message to trigger the mechanism to move on to the next message. My 16 message state engine I mentioned earlier is overkill for what you are doing since it includes stuff to disable slave comms, error counters and other things.

Click to expand...

I missed the two slaves part earlier, so yes do as OkiePC suggests.