Best Practices for DH+ Communication

Vetteboy

Member
Join Date
Jul 2002
Posts
380
I am about to write my first Message code for communication between a SLC 5/04 and a PLC 5 on DH+ and was looking for Best Practices, etc. I can easily see how others have done it by browsing our existing code, but I hate to just copy what may not be the best way to do it. In general, I would like to optimize our DH+ to keep things running smoothly.

Thanks in Advance,

Vetteboy
 
there's some good info here:
http://www.ab.com/manuals/cp/1785685.pdf

and here:

http://www.ab.com/manuals/cp/17856512.pdf

- msg writes are much faster that msg reads
- keep the quantity of information being sent/requested to a minimum to reduce the impact on the network.
- if it's just a few bits (up to 16) that you need to communicate, consider using the global status file ... bandwidth-wise, it's free (one of the few times that you can get something for nothing)

hope this helps
 
I like the global status file concept. It isn't being used here at all. The only problem I'll have is that my 5/04s are old enough to not support it. I do have the manuals you mentioned and they are great, I just wanted a little human reassurance. So am I correct in assuming from your tip that it is better to write from each processor than have one both read and write?
 
Correct me if I'm wrong but,

From my understanding MSG reads are supposed to be faster across the DH+ network. If this is not true, I would certainly like to get straightened out!

I have used in the past MSG reads only with great results. Generally I use a dedicated B*:*.* or N*:*.* file for each node on the network and copy each file to every node. This keeps everything organized and you can copy, through the address/symbol database the same symbols and/or descriptions to each node quickly.

For example if you have 3 nodes (1,2, and 3 for example) you might setup up your data files like:
N7:21 (MSG_NODE_1)
N7:22 (MSG_NODE_2)
N7:23 (MSG_NODE_3)
and use these dedicated files in each node. Then use the MSG read for each file in each node.

It has worked well for me but there may be a better mousetrap out there.

Regards,
Chris
 
At one point I was told that reads were faster, then I was told writes were faster...clarification would be helpful.

I prefer reads because it's easier to see where the data is coming from. Of course, as long as your DOCUMENTATION is good, MSG writes are fine. If you don't document, though, someone else could be looking around for a spare integer in your program that's getting written to, not know that data's coming from another processor, and overwrite the DH+ data.

So if you go with writes, make sure you document (in the file that's getting written to) which file in which processor the data's coming from. If you don't, someone will either overwrite the data or at the very least have a difficult time knowing where the data is coming from.
 
Here is what I will do unless given a good reason not to:

The SLC Controls a Bin full of Planer Shavings for trucks to haul to another plant. The PLC5 controls the planer. When the bin is full we have to switch a diverter gate to a different bin. The gate cannot be switched while the blower is feeding shavings through the pipe, so the planer must be stopped to purge the pipe before the gate diverts to another bin. I will have the Bin SLC Write to the Planer PLC when to stop and when to start up again. I guess it would be wise to have the Planer confirm it is stopped and started by writing to SLC that it has done so. Therefore traffic would be kept at a minimum because this event would occur only when the trucks don't arrive fast enough to empty the bin. Worst case I don't see this occuring more than twice per day, so it's probably pointless to be reading for it all the time.
 
To clarify my stance on msg reads vs writes:

A msg write simply takes data from the source node and places (stuffs) it in the prescribed location in the destination node ... no questions asked and no intervention required by the destination node.

A msg read is basically a request made by the source node for data to be written back to it by the destination node. The request is sent during the source node's normal token time and must route through each intermediate node until it arrives at the destination node. (loosely analgous to a "write"). The destination node must then process the request, formulate the response, and write the requested data back to the source node (another "write").

At least that's how Mr. DH+ taught it to me.
 
When I have done messaging on DH485 , I have cascaded the messages such that only one MSG instruction is enabled at a time. You could probably apply this to DH+ as well.

I also found that if a MSG instruction goes into error, you will need to have some way of toggling the MSG instruction rung off then on (ie. false then true) to reset the error, hence the S4:8 bit in the picture below..

msg example.jpg
 

Similar Topics

Hey all, I'm working on a big Allen-Bradley Ethernet system and I'm looking for opinions on the best way to detect communication failure between...
Replies
7
Views
9,900
I have a relatively small network but I am having some issues with PowerFlex 755 drives (using the native ethernet card) Faulting with the F926...
Replies
0
Views
230
What's the best way to use lots of MSG instructions in the same program? Both multiple messages with the same device, and other devices. I've read...
Replies
10
Views
1,224
Hi all, We are looking for the best practices when it comes to maintenance technicians having online access to our PLC's. We would like to give...
Replies
5
Views
1,170
I would like to compile a list of all the CX-Programmer PID Best Practices If there is some clever way you have figured out to do something and...
Replies
0
Views
682
Back
Top Bottom