DH+

[frank.raymond 0]

I have 2 SLC504's I want to connect to each other using DH+. I want to learn how to share data between them or share common address locations. I just want to learn from experimenting. I looked for some downloads to see if there was something there to get me started but didn't see anything that caught my eye. Does anyone have any same code that I can learn from? Thanks

[gravitar 3]

Read the thread "DH485 network", it should be on the same page as yours. The considerations and programming procedures are largely the same for DH+ as for DH485.

[TimWilborne 108]

I think THIS is the thread Gravitar is refering too

[BobLfoot 302]

Can't give you any code, but do have a couple of observations about your post that I hope are usefull. The AB processors do not have shared memory locations like the Omron Host Link Protocol or the Toshiba SysLink. Your most obvious way to share data will be with Message reads and writes. The MSG instruction is well documented in the help program. If using the MSG Instruction you'll also want to know that using only Reads is more efficient than using Reads and Writes. I can't find the post right now, but it is proven fact researched by others as well as myself. Keep posting and let us know how your experiments go.

[frank.raymond 0]

Gentlemen, I think you for the link. Bob you're observation is well founded. I reckon from my previous Omron posts you saw that I was thinking the Omron and AB were similiar. I'm trying to store serial numbers in one PLC and have the other PLC read the table for a match. Edited 6 Jul 2006 by frank.raymond

[David Nelson 3]

this one is on the msg instruction i learned a great deal from it(i was using 2 5/04's on DH+ also) http://forums.mrplc.com/index.php?showtopic=6667&hl=

[BobLfoot 302]

David you are obviously better with the MRPLC search engine than I at this time. Thanks. Bob

[paulengr 44]

DH+ is very easy to deal with. First off, ignore all the older "twinax" information that AB has. Nobody wires it up that way anymore. Instead, it is generally a single twisted pair with the ground (3 wire connection). Don't believe the "synchronous vs. asynchronous" networking blather either. Ethernet is so fast that these arguments are academic. In addition, if you don't use hubs (network switches only), you don't have collisions...it's just as fast as a token passing network. Just buy the Belden cable they recommend. Wire it up (blue, white/clear, shield/bare) on each end identically. Put in the recommended termination resistors on the "ends" (it's a bus-style network). If you have more than 2 nodes, at the ends of the connectors, match colors (white to white, blue to blue, shield to shield) to splice in an extra connector. If you've wired up AB Remote I/O before, it is ALMOST identical. There are only three differences that I know of. First, remote I/O is a polling-style network (DH+ is token passing). Second, you flip the white and blue wires so that from a color coding point of view, the connections are reversed. Third, although it is probably possible to run DH+ at any speed other than the minimum, AB has never made that an option as near as I can tell (unlike Remote I/O). As far as I can tell, electrically, DH+ and Remote I/O are identically. Programming-wise, set the node address manually on each PLC or other device to whatever number you want. I suggest that you change them all so that there is not a 0 or 1 anywhere because these tend to be defaults (not using the defaults helps with troubleshooting). Beyond that, simply follow the instructions to set up a MSG statement. In your message block, it is best to use reads instead of writes for most cases. Reads have higher performance. And in addition, it is easier to deal with the programming issue of data "mysteriously appearing" if you have an explicit MSG block. Regardless, most versions of RS-Logix will not correctly detect references inside MSG blocks (the "used" memory map is not correct and a search for an address in an MSG statement doesn't work). As far as triggering MSG blocks go, you have 3 choices here. You can set the "continuous" bit in the block which causes it to continuously poll. You can trigger off the "DN" and "ER" bits. In fact, there are buffer limits to be aware of for each channel. If you are a heavy duty MSG block user, consider setting up your MSG blocks in "chains". The first one will trigger off of say a timer or off the last block. The next one going to the SAME PLC will trigger off the DN or ER bits of the first block. That way at any given time you should have just one MSG block outstanding for a given PLC. That being said, the OVERHEAD of MSG blocks is such that you really should try to set up all of your words or bits into a single block of memory so that you can use as few MSG blocks as possible. Each additional block just adds more handshaking and more bandwidth. In addition, you may not want to trigger off the .ER bits. That way if the first read doesn't go through, don't do any of the others! When you don't use "continuous", the MSG block fires off and goes into the communication channel buffers when the rung first goes true. The actual MSG transfer occurs independently of the ladder scan (during the "housekeeping" operations). When it completes (or fails), the DN or ER bits will be set. If it is not set to continuous, the MSG block will wait for another false-true transition. There are plenty of cases where you want to monitor the .ER bits. Normally you can set the number of retries on a message block to reasonable limits (2 or 3). But after that, you can assume that you've lost communication and take action (set an alarm off or take some fail safe action). You can also check for the presence or absence of a node in the system status flags for DH+ networking but be aware that even if a PLC faults, it doesn't "disappear" off the network. Explicitly checking the .ER bit is the most reliable way of detecting when a message fails. So for your first attempt, just set up a simple self-triggered timer (XIO T4:x/DN TON T4:x 1.0 1 0) and then trigger your message block to fire on timer done. That makes it easy to debug. I strongly recommend you don't use the .CO bit so you can control bandwidth, timing, and detect errors. One other item to be aware of with DH+ networks. The "token" is several words long. If you configure a data table to hold the status information from the DH+ channel, there is a neat trick you can use. Each word in the global status word corresponds to a single PLC (by node address). Each PLC can set it's global status word to a unique value. In addition, all the other unused node addresses are "free" and can be used by any PLC. This word gets passed around automatically when the token passes REGARDLESS of whether you are doing any MSG transfers. It does not add latency. What this means is that effectively you have a small "global shared memory" among DH+ nodes. Back in the PLC-2/3 days when every bit mattered, it was a very powerful and convenient tool. There is one exception to the "reads vs. writes" rule. When you have an event that occurs on one PLC on a sporadic basis and you need to send it to the other PLC, a write may make more sense since compared with polling. In my case I have a scale in one part of the production line that weighs parts every few seconds that are produced by several production machines. The individual machine cycles are about once a minute or so. If I only used reads, I would have to read the weight information on each machine every few seconds to be assured that I captured it. Instead, I issue writes from the scale so that the network load is equal to the load of just one machine issuing polls.

[David Nelson 3]

Now thats a post!! well done chap!!!!{{{applause}}}}

[frank.raymond 0]

David, Your link helped me get started in the right direction. Paulengr, You may be new to this forum but your post reflects an experienced controls person. I thank you both for your wealth of knowledge.