Ab dh+ programing

I have several machines with 4 PLC 5's controling the machine function. I am installing a contrologix to gather first outs. I am using several messages to obtain the information over DH+. I discovered that I cannot let them run free, and need to operate them one at a time. I am not sure the best way to do this. If I just use the DN or ER bit from the previous one, they still operate quite a bit. IS it good to set up a timer and turn on each in turn by the acc value, if so how long do I need to leave the rung true for it to actually work. Or if anyone can advise me on this I would greatly appreciate it.

You could change your methodology to have the PLC's WRITE to the controllogix on data change.

Oakley said:

You could change your methodology to have the PLC's WRITE to the controllogix on data change.

Click to expand...

I thought about this, but with the project I am working on, I do not work for this plant, so hesitate to do any programing changes to their machine plc's

There's no real rule of thumb It depends on how much data you're transfering, plus how much other traffic is on the DH+ network.

If you want to use timers, try allowing 1 second for smaller messages and 2 seconds for bigger messages. You then need to monitor the DH+ network and be prepared to make changes if you are getting multiple message errors.

Tim Ledwith said:

There's no real rule of thumb It depends on how much data you're transfering, plus how much other traffic is on the DH+ network.

If you want to use timers, try allowing 1 second for smaller messages and 2 seconds for bigger messages. You then need to monitor the DH+ network and be prepared to make changes if you are getting multiple message errors.

Click to expand...

what is a good way to monitor the DH+ network, I have not been able to find this. Also, I was told by AB that the length of the data collected does not affect the time. I found this hard to believe.

I thought about this, but with the project I am working on, I do not work for this plant, so hesitate to do any programing changes to their machine plc's

Click to expand...

Then try using your CLX as a 'read', like Tim said... depending on how often and how fast you need the data you can just do a read from the other PLC on the hwy

We use msg blocks on DH+ and across a DH backbone with 3 DH+ nodes.
Try not to use the DH or DH+ for time sensetive control as it will
not work very well. For transfering data it is great. And you should be able to let free run but using timer done bit works well too.

We have a older PLC-5 fluid distribution system that communicates with six or so sub-systems using DH+. Each subsystem also uses a PLC-5. The distribution PLC-5 talks with three subsystems across port A and three on port B. Actually, the subsystems do all the DH+ message reading and writing and the distribution system PLC just responds. All is well now, but when the last subsystem was introduced, we experienced immediate DH+ B network failures.

What I found out was every MSG instruction on every subsystem was programmed for continuous broadcast. This meant that once the message was successful (DN bit set) the message would be automatically reloaded into the queue and eventually be sent out again, regardless of rung input conditions. There were 12 messages per PLC being continuously broadcast to the distribution PLC. So when we added that last node, message errors were being encountered. It didn't crash the network, because the next iteration of the message would usually get through. What it did do, however, was cause one of the PLCs to fault because the message was delayed enough to trip a communication timout.

After evaluating all of the messages, I discovered and corrected several things:

1. We did not need to continuously transmit (data transferred was not time sensitive).
2. 9 write messages to the same node could be reduced to a single three word message with a little bit of data organizing.
3. 3 read messages to the same node could be reduced to a single, one word read message.
4. An unconditional timer was added to "pace" the read and write messages. I set it to 500msec.
5. No changes were made to the functionality of the distribution PLC or subsystem PLCs (only messaging logic was modified).

Keep in mind that every message creates what I call administrative overhead, meaning additional control and status information must be broadcast across the network and this was what was really taxing our distribution PLC (not too many data words, but too many messages). By condensing the same amount of information into fewer (but longer) messages, it greatly reduced overall network traffic. Slowing things down with the timer made it even better and will easily allow me to adjust things should it become necessary in the future.

I also created and incremented an up counter on each MSG DN bit and just watched the accumulator increase over time. Even with a slow update on the laptop, it was very easy to see the consistent rate at which successful messages were being braodcast; pretty much two per second.

One thing I failed to mention was that we couldn't even run an online RSLogix connection at the distribution system PLC A-port via a laptop. It would always crash as it uploaded. Now that all the nodes have been reprogrammed, I can run two programs online from the A-port with no problems.

You don't need to modify the other PLC programs. Program your ControlLogix to push out (MSG write) data out to the other PLCs and retrieve (MSG read) data back from them. Put the MSG instructions on timers and experiment with how frequent you want the data updated. Set the time with the assumption that if one iteration failed, the process will be OK until the next one got through. I put 3-second timeout fault detection and response logic on all nodes as well to handle a PLC being offline.

Also, if you have one of the better RSLinx versions (OEM and Gateway, perhaps some others, definitely not Lite, though) you can invoke Station Diagnostics and see if there are any comm issues on any connected node. It is pretty handy.

CeCo3

Take a look at a DH+ to Ethernet bridge to goto the Contrologix. Or you could use a Lantronix at each rack and do a serial to Ethernet bridge.

One project I did some time back required the use of five PLC processors now one of them being somewhat a master controller. So what I did was have the master computer poll each PLC node Read or Write in sequence one after the other.

Each Message instruction was placed on a separate rung,
Each Rung would be enabled with the use of a compare instruction of C5:0.acc = X

The counter was incremented when either the done bit of error bit of the active message instruction was activated.

One easy way to trigger the counter would be to use the MG file I think it was called to control the message transfer rather than use integer. If this was done the rung to trigger the counter could simply be a combination of MG9:[C5:0.acc]/DN OR MG9:[c5:0.acc]/ER


When the counter done bit was active a delay timer was activated' this would delay the next scan.

Thanks for the replys. I have 9 message reads from my CLX as of now, I am turning them on one at a time using latches. I do think I can lower the number of messages by making the messages I have read more data. I was under the assumtion that if I had more reads that read less data that it would work better. I can combine some, although some will read up to 50 words of data. I might have to eventually break down and combine the data in the plc's I am reading from into smaller files to have less messages and smaller files to read. Thanks again to all