ControlLogix Update Time Slow With rs232

[Darksabre]

Hey, I may have overlooked this in the oh-so-helpful AB manuals, but does anyone know of a way to decrease the update time interval when talking to a controllogix processor over RS232? It takes around 3 seconds between giving the processor a toggle bit command, and seeing it happen on the screen. Looking at the Processor Config tabs is also painfully slow.

 

[CowDung]

I believe that the update time is a function of baud rate. The faster the better.

 

[Darksabre]

I believe that the update time is a function of baud rate. The faster the better.

Yeah, I believe that's definitely the case. It's running at 19200. I was just kind of mentally comparing it to the speeds you see when running a Logix 500 program over rs232 (which seems to be pretty speedy). This is running the same baud, yet its so much slower. I suppose there could be a lot more info going through with the Logix 5000.

 

[TConnolly]

What is the system overhead time slice (Controller->Properties->Advanced tab)?

 

[Darksabre]

What is the system overhead time slice (Controller->Properties->Advanced tab)?

I think it is set to 20%.

 

[Rob A]

You could take the baud rate up to 38,400 which helps out.
Also if you are using Firmware ver 16 there were some issues with the serial port. They have been fixed in ver 16.21.
We run FW ver 16.21 with the baud rate set at 38,400 on L31 processors and it responds fairly well for serial.

 

[Darksabre]

You could take the baud rate up to 38,400 which helps out.
Also if you are using Firmware ver 16 there were some issues with the serial port. They have been fixed in ver 16.21.
We run FW ver 16.21 with the baud rate set at 38,400 on L31 processors and it responds fairly well for serial.

Hmm. 38400 didn't seem to help too much. We are running 16.20 I believe. Was there a fix in 16.21?

 

[Bob A.]

Do you have the option of backing down the update rates especially on the tags that are not on the current screen? Sometimes less is more. I once found a system that was trying to update about 80 numeric display elements on a screen at .2 second update rate (19,200 Baud). Sometimes the RS-485 network would freeze for minutes at a time. I changed everything to 2 second rates and the network caught up and worked great.

Best Regards,

Bob A.

 

[Darksabre]

Do you have the option of backing down the update rates especially on the tags that are not on the current screen? Sometimes less is more. I once found a system that was trying to update about 80 numeric display elements on a screen at .2 second update rate (19,200 Baud). Sometimes the RS-485 network would freeze for minutes at a time. I changed everything to 2 second rates and the network caught up and worked great.

Best Regards,

Bob A.

Hmm, interesting. Is the tag update time setting on the PLC side, or the screen side? I'm workin on a couple of projects, one has a screen, the other does not. They both have slow update times.

 

[Bob A.]

It is not in the PLC. Depending on the system, it may be in the tag definition or in the screen element properities. Basically, something has to tell the data server how often to poll the PLC for an update on the each tag. Some things change slowly and can be updated infrequently without losing anything significant. An example could be the temperature of a tank of oil.

Some systems will update on exception, such as a large DCS, where a change of more than a few % would trigger an automatic update. But in this case, you have computers running the system and other computers writing the screens and there is a lot of computational capacity available.

I usually start out with slow update times, say 3 - 5 seconds. Then once you see the system run, all the things that are too slow can be sped up a little at a time while observing the performance. Some systems will automatically take tags off scan (or slow them way down) when they are not on a screen that is being observed.

In the old days, we sometimes had to lay out this scheme as part of the development process.

After a while, you will develop a feel for the size and speed of the system and the bandwidth requirement of your screens. One thing to bear in mind, the operator has to look at the screen all day. Fast screen updates on things that he does not care about will likely be ignored. I have had to go back and slow screen updates down to get the operators off my back!

Best Regards,

Bob A.

 

[NOP]

Just to get back to Alaric's post; have you tried increasing the SOT?

Communicating with Logix (I'm assuming from the comment about the Config tabs that we're talking about slow update to an HMI/SCADA here) is one of the things that the ControlLogix will do when it gets some spare time from running your code. If you're running several tasks it has a relatively small amount of time for that; with the SOT at 20% it has only 20% of a relatively small amount so serial comms. take the hit.

It's hard to say that this is the issue without seeing the Task Monitor running on your project but it's worth increasing the SOT to see if it resolves the problem.

 

[curlyandshemp]

Hey, I may have overlooked this in the oh-so-helpful AB manuals, but does anyone know of a way to decrease the update time interval when talking to a controllogix processor over RS232? It takes around 3 seconds between giving the processor a toggle bit command, and seeing it happen on the screen. Looking at the Processor Config tabs is also painfully slow.

Maybe you experiencing the same problem I have , but with the serial port as per this post from several months ago

 

[Rob A]

There was an issue in FW ver 16.04 that if you had a Panelview Plus connected to the PLC via the serial port it would quit communicating after a while so they came out with ver 16.21.
Also technote #40653 talks about using CRC error detection rather than BCC.
It seems that the whole Logix family of processors has always communicated slower over serial than the SLC processors.