Sign in to follow this  
Followers 0
Pierre

RSView32 slowing down to almost a halt...

4 posts in this topic

We have an application with 3 PLC5 with about 4000 tags in each of the 9 PC with RSView32. They com over Ethernet to the 3 PLC (PLC5/40C + Enet module) and exchange messages between each other. Whe we have all 9 PC online, they pass throuhg a RSLinx Gateway equiped PC to have data from the 3 PLC. When more than 5 PC are online... the comunication is VERY slow... Tag need more then 10 seconds to update. Is there a way to make this better... is it normal now like it is?. Is there a formula to figure what speed we should be getting out of such loaded system... Edited by Pierre

Share this post


Link to post
Share on other sites
You need to optimize your system. I have dozens of PC's polling about 2 dozen PLC's. It should be reasonably possible to scale to many more PC's and PLC's even with RS-View32. First, you've got to consider your basic network implementation. Are you running hubs or switches? With the price difference being what it is, remove all hubs and replace with switches. If you have hubs, all the hubs that are directly connected together form a broadcast domain. Within that domain, the total bandwidth is going to be effectively 1/3 of the slowest device, usually 10 Mbps for PLC-5's. So you've got 3 Mbps total input and output with hubs for ALL connected devices. If you use hubs, EVEN if you optimize your PLC communication, you will still have bandwidth issues. If you have switches and they are capable of full duplex operation, you've got 10 Mbps bandwidth for EACH device (not total). If your PLC-5's will do full duplex (most of the older hardware won't), then the bandwidth is really 20 Mbps, 10 Mbps uplink and 10Mbps downlink. Also look at your PC's and network switches too and make sure you don't have any ugly situations in terms of aggregate bandwidth. In other words, if you have all 10 Mbps connections between PC's and switches, then you will be limited to 10 Mbps total even if the PC's can handle a lot more. These days it makes sense to run 100 Mbps minimum between PC's and switches, and backbones are now typically running 1 Gbps (even though this is overkill for most controls networks). Not saying that any of this is your issue but start here. You also should be looking at what other traffic is running on your network. Sometimes bad network setups such as using Ethernet/IP without an IGMP agent is the kiss of death (PLC-5's don't use Ethernet/IP). If you aren't truly sure what's going on, the best thing to do is to buy a managed switch (yes, even a cheap one is expensive), the smaller the better. You only need 4 ports total. Get a copy of Wireshark (free, google it) and a second NIC card (Ethernet port) for a laptop. Install wireshark. Plug the managed switch in between say a PC and a switch or a PLC and a switch. Plug the laptop into one of the remaining ports. Connect to the managed switch and program the remaining free port for port mirroring mode. Mirror one of the PLC or PC ports that you want to inspect. Now plug the remaining free port on the laptop into the mirror port and run wireshark to monitor this port. This will allow you to monitor packet rates, data, etc. The key here is not to look so much at the traffic itself (wireshark doesn't understand PLC-5 Ethernet) so much as it is to look at traffic OTHER than that intended for the PLC or PC such as broadcast traffic. If you already have say 500 packets per second worth of broadcast traffic then optimizing your PLC communications isn't going to do much good. I'd go after the source of all that traffic and start working there. PC's can handle thousands of packets per second easily but PLC's are much more limited in their ability to process both legitimate and unwanted traffic. Those are the more or less "global" issues. Now let's focus in on what's going on with RS-Linx and the PLC-PC communications. RS-Linx itself does not scale well. You are getting close to the point where RS-Linx will become your major bottleneck. It is easy to check for this. Bring up the Windows Task Manager (usually ctrl-alt-del to get to it the fastest way). Click on the Processes tab. Look for RS-Linx. If it is more than roughly 20% of your CPU, then this is most likely your problem. I don't think this is it though because you said it only becomes a problem as you add more PC's. If this becomes your issue, switch to a Kepware OPC driver. These particular OPC servers have been shown to have probably the best scalability...they can reach 10's of thousands of tags without an issue. Alternatively you can split your existing PC's into clusters. So for instance process line #1 uses RS-Linx Gateway #1, and process line #2 uses RS-Linx Gateway #2. Several PC's only look at process line #1 or #2 but not both. This reduces load on RS-Linx. But again, I don't think you're there yet. OK, with a direct driver, we need to look at your SCAN CLASSES. This is probably where your problem lies. NEVER use "0" for the scan period. Use 1 as a minimum. Make sure your scan classes are set to reasonable values especially for foreground values. Some examples: 1. Set points should be set very low. I usually use 5 seconds. The reason is because an operator is unlikely to change set points faster than that and it's pretty much a tag you use mostly for writing anyways. 2. Very slow sensors such as thermocouples should also be set very low such as 1 second because temperature is unlikely to change more than 1 degree per second. 3. Human reaction rates are typically about 0.2-0.4 seconds. You should have a very, very good reason for setting anything lower than that because it won't make a difference. 4. Encoders (position indicators) should be set fairly quickly (say 0.3 seconds) for the foreground setting but very slow (say 2 seconds) for the background setting. The reason is if you are watching the value and it's moving, you expect it to move very quickly. But if it's not on screen, does anyone even care? 5. Set alarms similarly with 1-2 second delays for background settings but much faster (say 1 second) for foreground activity. 6. Go through EVERY tag and verify that it has a scan class that makes sense. With OPC, you don't have scan classes at all. You have to set up different scan classes effectively manually by setting up separate OPC topics and OPC drivers. I suggest you create at least 3 of them. One is for set points and very slow data. One is for "fast" data. One is for everything else. The whole idea is to request each tag at the minimum scan rate and no more than that. With RS-Linx Gateway involved, and I suggest you do things this way, the way that you configure things is very important. If you use all direct drivers, then RS-Linx Gateway acts as a pass-through device. Effectively if you have 9 PC's all polling "N7:0" using direct drivers using one PC as an RS-Linx Gateway, the PLC (and the gateway PC) will be hammered with 9 reads to N7:0! RS-View 32 handles scheduling of every single read request and all RS-View 32 copies work independently. As an OPC server, the system acts much differently. Each copy of RS-View 32 registers a list of tags that it is interested in and an update rate with an OPC Server (whether you use one or more than one). It is up to RS-Linx itself to decide how to handle the list of tags. So if you have 9 PC's all requesting "N7:0" with the same scan rate, RS-Linx will request 1 copy of N7:0 from the PLC and send out 9 copies to each copy of RS-View 32. Finally, there is packet optimization going on. First consider what happens on the "wire". For a read, the request sends a DF-1 protocol command for reading the data. PCCC, aka PLC-5 Ethernet is just a variation on DF-1. Then the PLC responds with the data requested in a separate packet. For a write, a packet goes to the PLC requesting permission to write. Then the PLC responds with an "OK" or "Refused" packet (we'll assume OK). Then finally the PC can send the data, resulting in 3 separate packets for a write. This is all for just one tag. If you set up a tag for reading "B3:0/0", then you just created 2 packets worth of traffic at the specified scan rate (one in each direction). If you then set up a second tag for "B3:0/5" with the same scan rate however, you still get exactly 2 packets. Even if you use say "B3:1/0", you will still get 2 packets. Each read can transfer up to around 500 bytes of data. RS-Linx and RS-View 32 are smart enough to notice this and will combine multiple tags into a single read request. They will also usually do this even across scan classes so if the tag for "B3:1/0" was half the speed of "B3:0/0", then B3:1/0 would probably be scanned at twice the requested speed regardless of the scan class. To help this process along, it is useful to always pick scan times that are even multiples of each other (use 1.0 seconds and 2.0 seconds, not 2.0 and 3.0 seconds). You can check exactly what is going on by looking at the OPC statistics in RS-Linx (look under the DDE/OPC menu). There is a similar feature buried somewhere in RS-View 32 for direct drivers but it's been almost 10 years since I've used RS-View 32 so I don't remember exactly where to look. The upshot of this is that even without optimizing scan rates, if you move all your PLC-5 memory layouts around so that all HMI traffic occurs in just one or two data tables, you will see dramatic performance improvements in terms of throughput. If you have everything scattered so that the tags are all over the place with no particular order, then the number of packets goes up dramatically, which affects performance. As a general rule whether it's on ControlLogix or PLC-5, I try to set up a couple data tables that are intended specifically for PLC/HMI communication and try to put all communication in those tables. Even with 4000 tags if most of them are bit tags, you may be able to get all of your communication down to just 4 or 5 packets to cover all tags, enough that scanning everything at 0.250 seconds is reasonable. Finally, consider unsolicited messaging (aka producer/consumer). This essentially turns communication upside down. Instead of a request-response system, it becomes "don't call us, we'll call you". You have this feature available as part of OPC if you are using one PC as an OPC server. With unsolicited messaging, the OPC client sends a list of tags that it is interested in monitoring. Whenever any of those tags change, the OPC server marks them as changed and sends a packet with the updated information at the requested scan rate. However, if no tags have changed, then a packet is NOT sent. This can also obviously dramatically cut down on bandwidth. This is the default mode in OPC, so it gets used automatically for PC-to-PC communication. This feature is also implemented on ControlLogix processors. RS-Linx will (almost) automatically use it and it cuts down on the bandwidth from those processors. With a PLC-5 it's a different story. There is an "unsolicited mode" in RS-View 32/RS-Linx. The way that it works is that you manually set up MSG write instructions in the PLC-5 to write updates to RS-Linx based on PLC code. It works but there are some downsides. Since the MSG protocol is using solicited (DF-1) writes, 3 packets are generated (request, response, data) instead of just two (request, data), or the Ethernet/IP unsolicited version which creates only one packet (data). The advantage is that you can write code on the PLC and write only when necessary. For instance if you collect one large file of data for each batch in a batch process, you could write the entire file at once, eliminating virtually all of the load on RS-Linx. For the record, I have never actually used or had a need for this feature. In the past when I had only a DH+ network to work with and RS-View 32, using these optimization techniques dramatically sped up everything. The only two changes I made was to set up scan classes properly (optimizing scan rates) and to rearrange addresses on the PLC as much as practically possible to reduce the number of packets. These two simple changes made even a slow 56 kbps serial link seem like Ethernet in terms of responsiveness. Edited by paulengr

Share this post


Link to post
Share on other sites
Thanks a lot. I print this answer and will read it again a few times so not to miss anything.

Share this post


Link to post
Share on other sites
I just wanted to add a little tidbit here regarding comms to SLC-5/05. I realize your particular app was using PLC-5, but thought this may help someone thats having the same difficulty as I had. http://rockwellautomation.custhelp.com/cgi...p?p_faqid=25915 We had (2) SLC-5/05's being querried by (3) RSView32 stations. Each RSView station was requesting between 5000 and 10000 tags worth of data from the two processors. When I brought the 3rd RSView station online, everything came to a screeching halt. The link listed above talks about a COMMS request bit. Setting bit S:2/15 to 0 solved our probems. A word of caution, our PLC's were ONLY being used as data concentrators. They had no real-world I/O to handle. This may be a consideration in other applications. Hope this helps someone. I lost 3 solid days over this little snag.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0