SLC 5/04 DH+ Comms Issue

Have 9 SLC 5/04s on DH+ comms connecting to 2 Intellution Fix nodes (Full SCADA and view).PLCs use MSG blocks to pass a reasonable amount of data (they all have something to say to each other basically). Comms falls over on a regular basis neccesitating a reset of all the processors to kick them back in. They all have SVC comms statements in their code and run at 57.6K, they used to run at 230.4K but the issue was still there.
Is ther something I can do now to solve the problem ?
I also thought of upgrading to 5/05s and installing a small LAN in place of the DH+ network. A reasonable investment but one we're willing to make if it solves the problem.

"falls over" ?

A comms failure that necessitates a power cycle sounds like an out-of-buffers condition. Can you tell us more about the symptoms of the communication failure ? Can you communicate with the SLCs via DF1 when they are not communicating on DH+ ?

Ken,
When I say reset I mean a program/run/remote switch of the processor key. DH+ comms still works in that Fix and Logix 500 still connect to the processors OK. It's just the flags that are sent between PLCs as interlock conditions via the MSG blocks that stop being transmitted.

Have you looked at the distance between the SLC's? There is a maximum of 100ft dropline limit. Also Allen-Bradely recommends using Beldon cables (I can't tell the differnce between regular sheielded and Beldon cables.)
In your case it may be worth replacing the cable with AB shielded 1770-CD twinaxial. I don't know much about token-passing, but you may want to dig into to see if the token is not being held by a SLC longer than required.

Shahn,
We're daisy chaining the processors so I beleive we can treat this as a trunkline giving us 10 000 ft. I'll have a look at cable specs though.

I had a problem with the MSG instruction a while back because it was on continuously,(tied to the left side of the ladder). I put in a self-resetting timer triggering an OSR to enable the MSG. The timer value was about .3 seconds for what I was doing and it worked fine. Any less time would almost lock it up, it would only update once every 4 seconds. I don't know much about DH+ so this may not apply or help.

Also Allen-Bradley publication 1785-2.6 (DH+ Network Data) may be worth reading.

It sounds for all the world like a buffer overflow problem.

Any of the 'enhanced' SLC-500 controllers (5/03, 5/04, 5/05) only have a small number of buffers to hold outgoing messages (I think just five). If you trigger too many MSG instructions, the instructions start turning on the *.EW (Enabled and Waiting for Queue space) bit in their control arrays. If you overrun the Waiting buffer, then the messaging function of the control just "locks up". Cycling the keyswitch clears out the buffers and you can start messaging again.

(yes, Terry, that's what I think of it, too.)

Over the years I've done a few messaging applications and run into this problem, and have never had a Really Thorough explanation from A-B about what precisely is the "Right Way" to trigger MSG instructions and handle the buffers. I've seen some good Technotes since they started the Knowledgebase a few years ago, but I never paid enough attention to them after I solved my particular project to be an expert.

If you're willing, Jim, we can dig into your application on this thread. If it goes astray we'll take it to a less-traveled Forum.

A couple of things to check at first:

1. Are you using the Global Status Word function on DH+ ? That can make a lot of discrete-level interlocking very simple.

2. Do you have a Diagnostic File defined for Channel 1? Lots of people leave out this configuration but it can help you rule out noise or corrupted messages as a problem if you have it available.

3. What about bit S:33/7 (MSG Servicing Sel) and S:2/15 (Comms Servicing Sel). Those have a big effect on communications throughput.

And then the big question: How to you programmatically interlock your MSG instructions ?

Eddie,
That's what my problem was, Enabled and Waiting for Queue space.
Here's a cut and paste from the SLC500 Instruction help in RSLogix500.

SLC 5/03 OS301, OS302, and SLC 5/04.
With these controllers, data is buffered when you enable the MSG instruction, as long as there is space available in one of the transmit buffers. These processors can service up to 4 message instructions per channel for a maximum of 8. If a MSG instruction has entered one of the four "channel independent" transmission buffers and is waiting to be transmitted, its control block will have status bits EN and EW (Enabled and Waiting) set. If more than four MSG instructions are enabled at one time, a "channel dependent" overflow queue is used to store the MSG instruction header blocks (not the data for a MSG write) from the fifth instruction to the fourteenth.

I could post some code on how my work-around was set up but it's messy and I'm not happy with it even though it works. Besides that,it may just not work at all for this application.

Thanks Eddie,
Loads of really useful info.

Fistly, I wasn't aware of the Global Status Word function so I could use this for most of the discrete interlocks. I have some words I need to bring across so I'll still need some message blocks.

A diagnostic file doesn't seem to be available for the processor we're using (L541).

S:2/15 is set on which is going to restrict our throughput of Data so I'll set this off and set S:33/7 on.

As for interlocking the MSG instruction the DN bit for the instruction is the only other element on the rung so there's no interlocking as such. Cosidering that some PLCs have 8 MSG blocks all trying to go at once it's no wonder we experience problems.

What's the best way to let you have a look at the application to get your thoughts ?