GATEWAY PACKET INCREASE

[Pierre 1]

We have about 12 PCs running RSView32 and they connect to a Gateway, polling data from 5 PLCs (3cPLC5, 2xSLC5/05). Since about a year ago I started to notice the packet exchange between the Gateway PC and the PLC5 increase in pkts/second. Nothing significant was added, a register here and there but not much. It was around 150-180 packets/s 2 years ago, now its over 300. Any adeas on where to look? I have a AB router on this setup (Stratix8000). An SQL database reads through the Gateway at 45 Pkts/s. How to troubleshoot this? I will get a wireshark log of the communication when I have a minute. Any hints? Thanks.

[Ken Roach 194]

I'm impressed that you have records from several years ago about the number of packets per second ! My guess is that there are OPC Groups that gave been created then abandoned, but are still polling the controllers. A restart of RSLinx Classic Gateway would purge those. Could there be a trend or data log running in the background someplace ? I'm not sure if Wireshark will help as much as the OPC Group diagnostics and OPC Performance diagnostics in RSLinx will.

[paulengr 44]

PLC-5's use a request/response protocol. Fundamentally, the request is to READ a block of data starting at an offset and for a specific number of elements in a data table. To get the required update rate, this has to be repeated periodically. If you have two diffferent reads of the same data and the requirement is to read data at say 1 packet per second, 2 packets per second, and 3 packets per second, it depends on how the gateway software is implemented. Some software will simply take the maximum update rate (3 reads/second in this case) and update the slower tags at a faster rate than required. Others will take the GCD (greatest common denominator) which in this case is 6 and then deliver updates to the HMI at exactly the required rate. In this example, the read rate is 6 reads/second even though the fastest update is only 3 reads/second. Lesson learned: try to always pick even multiples of the fastest rate when setting up your tag database to avoid this problem, no matter how the software is implemented. So changing the 2 reads/second update rate to 3 updates/second solves the problem even though it would seem like it would increase traffic. The second thing that happens with PLC-5's is optimizing the memory footprint. If you read say 2 tags at N7:0 and N7:1, and then another tag at N7:19, some OPC implementations will convert this into a single read of 20 elements. Others may turn it into 2 separate reads. On DH+ packet lengths are limited to around 500 bytes while on Ethernet they are limited to closer to 1500 bytes. How many reads get executed depends on how well your OPC implementation does this "merged read" function, which also of course hinges on the read rates of the different tags as outlined above. If you truly want to minimize this, put all your READ and WRITE data into separate blocks of memory. Also separate them into "fast read" and "slow read" blocks. This does two things. First, it keeps your memory map organized and makes it easy to keep track of what the HMI is actually reading and writing. Second, it helps the OPC server because it can just issue reads and writes to consecutive values in memory and can use the minimal number of reads (and packets) necessary. The exact same strategy occurs with any other PLC. It's just that with a ControlLogix PLC, it is helpful to organize memory in UDT's and arrays. The same memory optimization scheme works equally well. The downside with the scheme of course is that you will probably have a bunch of extra "mapping" code that simply copies data from the "HMI interface" memory over into the locations where it is actually used. On ControlLogix, you can avoid the actual physical copy with aliases, though it would be really, really nice if aliases were real objects that could be changed in online programming (Rockwell: PLEASE!) One further optimization should also be considered but is usually specific to PLC-PLC communication. Except for the "producer/consumer" protocol in ControlLogix, a read instruction takes at least 2 packets. The first is the "READ" command itself. The second is the actual data returned from the PLC. With a WRITE command, the minimum is 3 packets. First the request to execute the write goes to the PLC. Then the PLC responds with a "go ahead" packet. Finally the data itself is sent to the PLC. The lesson here is that whenever the data is a simple periodic update, it is preferable to do reads and not writes. It also has the troubleshooter's aid in that the data does not just mysteriously "appear". The exception would be for "change of state" data. In this case, the writer is aware of when the data changes state and can schedule the write to occur only when necessary. Usually writing "on demand" allows the communication link to remain idle for long periods of time, resulting in a far lower communication load. HMI's are inherently doing this when they only issue a write when an operator pushes a button.

[Pierre 1]

Thanks guys, I have read your info and it confirm most of what I have done and observed. Now for an important follow up. God I wonder how I have not seen this before... 3 years ago, this client had Rockwell personel come in to try and make there system better. They where experiencing some pretty serious communication failures. There usual solution was to reset the whole plant PLC systems. They would turn OFF the power to all there PLC and reboot the plant. So when I arrived, they had purchased 2 RSLinx Gateway licences and RA was reconfiguring all the 5000 tags (topics, well, you know). My arrival was due to a plant upgrade of some processes. We have reprogrammed about 30% of all there ladders in there PLCs but have stood by what RA people have done. So this is where we where seing the packets counts. Out of curiosity I was often using the Driver diagnostic tool and looking at what was going on. I have since notice an increase in the packets between the RSL-Gateway PC and the PLCs. Last Thursday it was at around 350 Pckts/sec. So we have setup a test bench with 4 PC, 3 Laptops running RSView32 with the exact same configurations that what they have at the plant. We added one PC running RSLinx Gateway + 2 PLCs (PLC5-40C15 and SLC5/05) and what we found is so far from what I excpected that I bang my head on the wall for not having logically thought about it before. Here it is: The local RSLinx-Pro was configure with Topics and Alias-Topics and Direct Ethernet drivers in order to fall back to a second or third path IF we where to loose a Gateway. So Gateway1 was first to supply the data... if it failed then Gateway2 was the next in line, eventually the RSView32 application was supplied data from a direct Ethernet driver from its local RSLinx-pro application. Now, in our test bench, wether 1 or our 4 RSView station where using a Gateway we would see a major increase in the quantity of packets being pass between the Gateway and the PLCs. WTF ???? In RSView, we where using as Node, Data Source - OPC Server and as Station or Server - RSLinx OPC Server. This made no sense, OPC should not double the com between the PLCs and the RSLinx Gateway or only very little when we add some stations. We have reconfigure RSView32 with in the Node - Station or Server - RSLinx Remote OPC Server and now if we add stations there is no significant increase in the link between the Gateway and the PLCs. So IF we use the RSLinx OPC Server as a Server what happens is that we are only passing through the Gateway. Its like being in a direct ethernet link on each station but being routed through the RSLinx - Gateway. We add a station, we double the packets, another station, triples... and so on. Its acting like a Gateway... not an OPC Server. When we use the Node - Station or Server - RSLinx Remote OPC Server we have what looks like a true OPC Server link. I have ASSUMED the OPC configuration was OK for it was done by RA. I was wrong, but then again there is more. Using the RSLinx Remote OPC Server does not require the use of RSLinx in the local station, its a direct OPC driver. RSView runs without RSLinx. I have 2 questions. 1. Can we run a true OPC link, passing through our local RSLinx application? The reason is for the fall back feature that seemed only to be configurable through Alias-topics locally inside RSLinx. 2. If Q1 anwers is NO, then is there a way to fall back to another Gateway in RSView32? (We have not found a way to do this for all tags are routed to a OPC named driver which cannot be modify on-the-fly) To me, in the end... ...when RSView32 uses RSLinx Remote OPC Server, it calls the data to the remote OPC Server in the remote RSLinx Gateway ...when RSView32 uses RSLinx OPC Server, it calls the data to the OPC Server in the Local RSLinx Pro running which passes through the remote Gateway. Such a simple setup test made us find this the hard way. It all started when I saw the above 300 packets and questionned it. Y'a know what they say about ASSUME !!! :) Thanks again for your help. Edited 14 Feb 2011 by Pierre

[paulengr 44]

Not sure on the answers to some of your questions and not pushing the competitors products, BUT... RS-Linx above a couple thousand tags is not stable in terms of CPU usage. It scales horribly, and you are getting very close to if not deeply over that line. Recommend you switch to a competitor's OPC server. Any of them will do. Kepware is known to scale the best. Both Kepware and Matrikon have all the fall back, etc., features you are looking for built in. They work with RS-View just fine. Perhaps the only feature you can't (as far as I know) get with the competitors is the alarm feature built into Logix 5000. You said PLC-5 so you wouldn't even know about this but in Logix 500 there is a way to trigger alarms directly in the PLC. It eats a HUGE amount of memory but it caches the alarms in the PLC so there is never such a thing as a "missed event" which is the one very neat feature of it. Essentially it's an alarms-and-events server built into the PLC but the interface is proprietary so the only way to get it is with RS-Linx. Outside of that, and the fact that you can have RS-Linx loaded and it automatically supports programming software (Logix) as well, there's not much else redeeming about RS-Linx as an OPC server. Note that Linx Enterprise is just rebranded Kepware with some goofy AB front end on it.

[waterboy 7]

... and crippled. the Kepware plug-ins wont work with RSLinx Enterprise.

[Pierre 1]

Sadely, its all RS and Siemens stuff at that plant. No way out of this.