PLC5 to RSLogix5 update rate slow

Hey guys, I have a PLC5 that is really hard to troubleshoot. I am talking to it via DH+ configured for 57.6K. The ladder is updating about every 10 seconds. When I look at processor status, the time and date updates roughly every 10 seconds, but the scan time is hovering right around 40 milliseconds. Does anyone have any idea why this would be so slow. I have used the same setup to talk to a different PLC5 and the update rate is about 1 to 2 seconds. Thanks.

Russ

What's your Driver Diagnostic for DH+ looks like?

We have the same problem on our site were 8 plc5/40's are linked together on a DH+ network. I know that with us the problem is the amount of data passing between plc's and also data being extracted onto excel spreadsheets.

diagnostics ok

I checked the driver diagnostics prior to posting. Everything there seems to be fine, there are no bad sent messages, nothing timed out or anything. On this piece of machinery, there are 5 PLC 5s linked together, but none of the others are as slow as the one in question.

Try to disconnect all other DH+ cables other than your RSLogix PC from that PLC5. If the update gets much more responsive, then you know that the problems are related to the amount of traffic the PLC must handle.

You can try to set S:77 to a relatively high value.
From the online help:
"Communications Time Slice [ms] - S:77
This is the Communication Time Slice between MCPs. Use this option to add a period of time to basic housekeeping for communication functions such as DH+, remote block transfers, and serial port operations. If you enter a 0 (zero) this function is disabled. Using this feature sets housekeeping time to a constant."

Also, what kind of PLC5 model is it ?

One more thing:

You have allready checked the driver diagnostics in RSLinx.
Do the same in the PLC5.
A diagnosic file must be specified for the channel in question.
You can then view the status information for the channel while online.
Maybe the PLC5 sees some errors that RSlinx do not.

PLC5 Comm

I have seen this before. It's more than likely the Message blocks between processors and you may want to change your Message blocks from a timer based to the data changing state. You may also want to look at the way the message blocks are laid out and see if you can consolidate them somewhat.
You should be able to see the ladder updating faster if you connect directly to the PLC in question instead of going over the highway.
With all that said, it's only the ladder display that is running slow and the program is scanning at its proper rate. I know it is a pain to debug it though.
Another thing to check for is how your processors are connected over the DH+, are they laid out daisy chain or trunk line. Are there resistors on each end of the network.

Are you connecting directly to the CPU, or are you going thru a DHRIO in the CLX rack (your thread title says ControLogix to PLC5)?
If you are going thru DHRIO, and you are using a lot of MSG instructions, check out this link:

http://domino.automation.rockwell.com/applications/kb/RAKB.nsf/0/B7B2036A7725EFF185256F80004B7353?OpenDocument

Don't Change S:77

Don't make S:77 a high value! It will delay the operation of the rungs internally, and could cause machine damage and other unpredictable
stuff. S:77 adds time to the sweep/scan, and creates a delay between
inputs and outputs that might cause other headaches.

If you have a 5/40 or later, and have any I/O at all attached locally,
S:77 is un-needed. S:77 is only needed for the 5/40 and higher, and
only then if you have NO local I/O and a very small program.

'unregistered'.
Yes it will increase the overall scan time.
But if russrmartin estimates that it is OK for testing purposes, then he can try set S:77=20, increasing the overall scan time to 60ms.
If it makes a positive difference, he can then try to decrease S:77 in steps until the problem appears again.
It is possible that a reasonable compromise between scan time and comms performance can be found.

If you have a 5/40 or later, and have any I/O at all attached locally,
S:77 is un-needed. S:77 is only needed for the 5/40 and higher, and
only then if you have NO local I/O and a very small program

Click to expand...

This simply doesnt make sense to me. S:77 increases the time the processor allocates to service communications. Local i/o and i/o on RIO is only affected when it comes to block transfers (as far as I understand).
Where have you found that S:77 is only relevant to PLC5/40 or higher ?

First, thanks for all the ideas and suggestions. Foremost, the PLC in question is a PLC5/40 C. The normal scan time seems to be hovering around 50 mS.

MgVol, I think you misread the header. Everyone else is on the same page as I am. I am looking at a ladder in RSLogix5, talking to a PLC5. No CLX processor in the equation.

IN response to Mark, there are no MSG instructions in the processor in question. In the MAIN PLC that talks to this network of PLC5's, there are only 2. The PLC in question does have a lot of FAL's, but I am unsure how much time they take up. If I am reading you correctly, you are suggesting simply connecting to the processor serially, and see if the ladder updates faster. I may try this just for experimentation sake.

Lastly, Jesper, if I do decide to adjust this time slice, what would be your recommendations? Better to start with 20, or should I increase in increments of 5? I have no experience adjusting this, so I'm all ears when it comes to this. Thanks again to all for the input. I will post the outcomes of the suggestions I tried after I have done them. Thanks again.

Russ

Hi Russ,

actually it is only you who can estimate if your proces or machine will be sensitive to a longer scantime. There IS a risk that critical timing sequences can be affected. However, there is also a chance that it is not so critical at all. Only you can know this.

To my opinion, 50 ms scantime is not unheard of with a PLC5/40. However, it is in the high end for PLCs today.
In the past, with slower PLCs, 100ms scantime sometimes had to be accepted, with the programmers using all kinds of tricks to update the critical parts faster than the main scan.

You can try to increase S:77 in small steps rather than jumping to 20 ms in one go.

Is the "C" in PLC5/40C because you have a CPU with ControlNet ?
If so, what happens if you go online via ControlNet ?
What happens if you go online via the serial port ?
I am a little pessimistic that using other channels than DH+ will help. This because I think the bottleneck is the CPUs updating of all communications. But try it, you never know.

Some more comments Russ,

the FAL instructions certainly affect the scantime of the CPU. But they shouldnt affect the communications.

I would look into how often the main PLC sends messages to you troubled CPU.

And if you PLC has ControlNet, how is it used in your system ?
I have zero experience with ControlNet. Maybe someone else can shed some light on how ControlNet affects general communications on the CPU.

And a long shot: Is the memory of troubled CPU utilised to 99.9% ?
I have heard something about the CPU needs a little "air" to function properly.

Jesper,

you are right about the memory used. We have the same problem. The memory is so full that we cannot edit online.


Ron

Another DH+ traffic consideration...How many HMIs and haw many tags each are being tranferred to/from the network at what frequency? There may be other devices that transparently take up the communication time slice of the processor in question. Also here's a link to a testing method for DH+ using a scope.

http://domino.automation.rockwell.com/applications/kb/RAKB.nsf/0/D37CC0D90F1EBE7585256AFB0061E197?OpenDocument

Here's an explanation of S:77
http://domino.automation.rockwell.com/applications/kb/RAKB.nsf/0/0746EA3F2DFF91A585256AFB006FE60E?OpenDocument