Messaging speed in Contrologix

I've tried finding the answer to this problem with Google, AB manuals and searching this and other forums...I need help.

I am using a CLX 5561 processor to communicate with a Phoenix Contact RAD-ISM-900-RS232-BD radio (MASTER) which is then connected to 6 other RAD-ISM-900-DATA-BD-BUS radios (SLAVES).

This setup lets the PLC poll the radios and see them, and their connected I/O, as remote I/O. This is done through the serial port on the PLC using DF1 Master protocol.

I'm using this setup as SCADA on cranes in our shipping area.

Part of the system is for the crane operator to control a roll line. I need to see his inputs as soon as they are made...the best I've been able to get is a 1 - 2 second lag time from input at the remote radio to seeing the input in the PLC.

Now for the question. I have to use messages in the PLC to poll the slaves via the master radio. I have eight messages that I need to fire off as fast as possible. I know it is not typically good practice to have a MSG in continuous mode, but this is really the only code the PLC is going to be doing...so scan time is not really an issue. I am having trouble configuring the 8 messages to run continuously.

The answer is probably right in front of me...I've read the 1756-PM012C-EN manual about messaging and it helped me get them talking..I just need to make them execute as fast as possible. I am aware that using the serial port is going to impose some limitations. I have it configured for 38400 baud, no handshake, no parity.

Any suggestions?

Suggestion - daisy chain them. At the completion of one message, perform the second, then the third...

Use the .err or .dn bit to indicate when to move on to the next message. When you get to the end, start over. I usually put a delay timer between each message so I would trigger the timer after each message, then trigger the next message with the timer. I use the same timer so delay, if I want it, is easily changed between each message. Maybe with serial it doesn't matter much, but with ethernet I found if I just message as fast as possible I have issues with connectivity from RSLogix, web page, etc. I don't have any example code handy, but others might.

Also timeouts will KILL your throughput - if you really want fast serial data, minimize the number of serial requests that timeout. Make sure devices are available, put code in to skip over known 'dead' devices, benchmark the serial response performance to use the smallest timeout possible, etc.

What do you mean continuous? And why 8 messages to 6 slaves?
How long are the messages (TX bytes and RX Bytes?) per transaction?

And how would running all continuously help? Don't you have to decode them in some way?

In general, a MSG READ is faster then a MSG WRITE, as there is much less handshaking going on.
Also, in general, the best speed you will get is triggering each message in sequence, as soon as the prior one is done. You can do that by triggering off of the .DN (or .ER) bits of the prior message (The first in the chain would trigger off of the last, and needs to be jump-started with a one-shot at program startup).

Timeouts are gonna hurt though.

Thanks for the responses guys...I just found the AB manual for DF1 Protocol (1770.6.5.16) and am seeing that my setup probably isn't going to work for my application.

DF1 Master, as far as I can tell, is Half-duplex. Only one slave can talk at a time...so I have to sequence the messages...even if they each only take 250 ms thats 2 secs between reads for each message (Message 1 would get read every 2 seconds)

To answer your questions...I don't know how big the messages are yet...they will have analog data from several channels and I'm bench testing the system before I try to install it on the operational cranes, so I don't have all the data coming in yet.

There are 8 messages for 6 slaves because of the addressing layout of the radios when in AB Emulation mode. I can't get all the info off two of the slaves in one block.

All of the messages are READS.

I had set them up in groups, like the example in 1756-PM012C-EN, which sequences them to read as fast as they get done...but like I said, it's too long between reads of each message to get the refresh rate I want.

I don't think the problem is the messaging speed.
I had a quick read of the docs for the radios, and it looks like when the PLC requests data then the message has to go through the master to the remote then the data gets returned. You have 2 radio paths in there each time and you are really driving them radios hard.(ie they are continually transmitting/receiving)

Your radios may be able to do what is detailed below.
Set each remote radio to update a common register in the master on its IO change of state. (this will mean a lot less radio traffic) Read this message block in the master as quick as the message function allows.

This is only a brief overview of what I think is wrong with the system the way it is after a real quick look.

Regards Alan Case