CLogix5555 Message Timing

[C. Marshall]

Is anyone able to say what the recommended time delay between messaging is in a ControlLogix5555 controller? I have a Message scheduler rung that schedules read/write messaging to a couple of PLC5s and one SLC500 via DH+. There are 8 messages total. The message configurations are sending/receiving floating point arrays up to 256 elements each. Only one message is indicating enable waiting in the configurations telltale on each pass. For all messages I am using the odd xmit.bit and each message rung is subsequently assigned odd timer accumulator integers.

Again, my question is, what is a reasonable/recommended time interval between messages?

Thanks.

Wayupnorth

 

[daba]

As each message is done (.DN) or errored (.ER) you can trigger the next, because the DH+ network is not doing anything.

But this approach gives each message equal "priority". You need to schedule the data according to its function. I would assess what data is being transmitted by each message, and time it accordingly.

by example :-
1. analog data that is being used in PID instructions that calculate once per second need not be sent every PLC scan,
2. data that is just for visual display need only be refreshed say once per second,
3. production data could be sent every 10 seconds,

use your own judgement on how fast the data needs to be updated.

 

[C. Marshall]

Thanks for the reply. Confirms my thinking and that always needs help. No PIDs involved in these arrays. We are sending real data used in peel profiles in a green end veneer plant. A Control Logix 5000 handles our messaging to several PLC5/40s and SLC500s on DH+; One end of our process requires high speed ouputs and that is sent via ENet to Elite Softlogic PLCs. We also do some calcs with the data and return process variables to display on Panelviews (slow is ok). There was some concern regarding the updates on all that was DH+ as we increased the size of the arrays (needed for more data retention).
At any rate, thanks again for your reply. We are ok it appears.

 

[daba]

You're welcome.

You say you are transferring REAl data. is that really necessary? I'd be willing to bet that this is truncated for PanelView displays to a fixed number of decimal digits? Could you not transfer such data as Integers, x10, or x100 and display to suit? (Obviously it depends on maximum values, 3,276.7 or 327.67). Always strive to minimise the volume of data being transferred, and maximise the time between transfers.

I've worked on some jobs with dozens of "ad-hoc" DH+ messages being sent all over the place, and in my observation DH+ generally sorts itself out quite well, unless you really overload it.

Talking of overload, once an A-B engineer was investigating failed DH+ messages at one customers site, and appeared to be horrified that it was running at near to 100% utilisation, my reply - "oh good, we're not wasting much of the precious bandwidth". After he'd thought about that for a while, he just nodded and carried on investigating.

I wasn't there at the end of his investigations, but I later found out they discovered a lengthy "blue hose" that was running into an unused panel, and then there was another 20-foot or so coiled up at the bottom of thi panel, complete with bare wire-ends exposed. It transpires that this panel was decommissioned and had been stripped out, but this was the DH+ end-of-line, and therefore used to have a terminating resistor. Once it was traced back to the next node, disconnected, and the terminator added at the actual end-of-line, all the problems miraculously disappeared. Seems like the manuals may have some truth in them then, eh?