RSView Enterprise slow tag feedback

[MigelB 0]

Hello, For years we had a silo, that was bought from a 3rd party, with a control system that works ( has a fast input and plc scan time ), but has incredible slow feedback to SCADA. Since the silo is off site, often closed or in full operation it's been hard to get the time window to really work on this and get to know the alternative setup. Now lately there is a bit of room to work on it but the history around the issue is vague and the knowledge surrounding rsview and rslinx enterprise is limited, so I'd hope you guys would know a bit more about it after my explanation. So I can narrow down the bottlenecks better at the next visit. Current Setup: PLC: SLC 5/05 16 CPU with ETHERNET Connection with an 747 - SN/B I/O Scanner for field Connected w/ switch to 2 PC's by Glass fiber The PC's used to be in a master slave setup for Rsview, with added engineering stations for the programming. But have been replaced to two new identical PC's. Whether or not this caused the problem is still vague. These PC's both have RsLInx for Rsview version 2.43.01.23 (PR6) RsView Enterprise and RsView Kepware ( for RsLinx Enterprise in Rsview Studio ) The only addition they have from the old setup is that they also have a logix500 programming added to it. In the screens.zip are some screenshots for the setup. I had limited time. But if you make suggestions on where to look next I might be able to get more. I thought it was weird that the Ethernet setting for the SLC5 CPU seemed to be locked at 10 mbs half duplex. But since the installation was in operation I could not change it. So I need to be sure that it has some importance, before I can shut down the plc for download. Problem: When an operator controls the silo, his input starts straight away. Open a valve or start a dust blower will immediately result in a reaction in the silo. However in the viewer, it will take 5+ seconds to actually get the feedback. This is not only for I/O but also internal bits like setting a motor block from manual to auto will take long to read out. Though the PLC scan time is only 10-20 ms and doesn't have that many crucial parts, the installation works fine. But there have been moments where crucial parts didn't seem to start on screen, while already running in the silo, causing danger in communication. Since it's a small setup I don't see where the lag is coming from. And the network and card seem fine. My question: What is most likely to be the cause of theses communication problems? So I can have a plan of "attack", next visit at the silo. Thanks in advance, Migel Screens.zip Edited 16 Feb 2015 by MigelB

[Ken Roach 167]

The 1000 msec poll rate in RSLinx Classic, coupled with an asynchronous default 1000 msec update rate for RSView screens might explain much of the delay. This sounds like an RSView32 system with RSLinx Classic. Or is it RSView SE ? Either way it's about ten years old. Older SLC-5/05 controllers support only 10 Mb/ Half Duplex Ethernet and should not be connected to switches that do Auto-Negotiation. If at all possible, configure the switch port for 10 Mb/Half Duplex. You have already seen the Diagnostic web page, but the MBUF and Memory statistics are not as useful as the actual port statistics that show errors and packets in/out. Take a look at those. When you are online using RSLogix 500, does the little ladder icon spin quickly or slowly ? Is your navigation among ladder programs reasonably quick or does it also have long lag times ?

[Ken Roach 167]

I do want to point out also that you are using a public Internet IP address, 128.168.10.80. This is a public address, which is actually assigned to a company called Gold Hill Computers in Colorado, USA. Because you have no subnet mask entered, and no default gateway, I assume that this controller is not on a network that is connected to the Internet. There's probably no risk that the controller itself can communicate on the Internet. But you might have problems in which your PC recognizes that 128.168.10.80 is an Internet address, not a private address for your internal network, and it *attempts* to connect to a gateway and find that address out on the Internet instead of on your internal network. This is especially true if you have some sort of VPN or internet-dependent private network tunnel connecting your main site and the remote site.

[MigelB 0]

Thanks a lot for the quick reply. Ill try to make the settings comply to the 10 mbs half duplex network setting on the switch and pc's ethernet cards. Yes it's an older version of RSView SE from the enterprise edition. Ill update the next time I get the chance to visit the site. I will also look if there is a VPN or internet dependent network tunnel that still ghosts in the background :) Thanks again, Migel

[rdrast 3]

Also, on RSView SE, the update rate is set on the display properties (right click a display, properties, set update rate) irregardless of what the IO server can handle. Make sure you have a few GOOD backups before you try upgrading RSView, and plan a lot of time to do it. Probably best to just get a new PC, set it up with whatever version of RSView SE you want, and restore the application to that then try to do an in-place upgrade. Trust me.

[MigelB 0]

Hello guys, I visited the location and set up the communication of the pc network cards to half duplex on all systems. Which frankly saved about 4-5 seconds of the delay. And changed the driver poll time to 200ms. Which in total helped me to reduce the 10 second to 3-4 second lag. I did find a data sheet that said that our SCL5/05 could be configured for 100 mb/s full duplex, but since it was mentioned here that it's limited and the PLC had to be brought down I skipped this step for last and eventually didnt had to go through with it. I also started to fine tune the display properties of each window which, from 1 second to a half second on larger screens and to 0.1 second on the smaller displays ( valve motor control etc ). Done like said by sparky, finding a empty spot in the window to right click on. This reduced the problem to non existent so much, I kind of wonder if this step alone would have been enough to fix the problem straight away. Since from this moment on windows also saw it as a high priority process and handled the information much quicker. I don't why it does this. If you limit to 1 second it should force 1 second, but windows put it on low priority and the timer becomes asynchronous with windows itself. I tested this on the login of the operator. With default setting it can take up 5 to 20 seconds to login, which I figured was typical with Rsview. But when I changed it to 0.5 or 0.1 sec. it became instant. Maybe it was a performance bug for this version, but the silo is responding now like it should. So of course thank you guys. This saved me a lot of headaches and it's nice to put this problem finally to rest :D