Data intensive RSView PC

[Pierre 1]

Data intensive RSView PCs Can 2 ENET card/module be installed on 1 PLC5/40C 4 slots rack with different IP address in order to segregate between the SCADA Operator control part and the Trend logging part. A trend and loging intensive setup slows down this system and I beleive upgrading to RSLinx Gateway will just not be enough.

[Nathan 7]

I really doubt that the ENET module is your bottleneck on a system with 2 PCs and 1 PLC. I'd be surprised if a PLC5 could drive the I/O to "top out" one Ethernet connection - I could only imagine another slowing down responses to the client(s). What do you mean by "slows down the system"? One obvious thing to look for is really high speed polling. I think you're right about RSLinx Gateway - it won't change a thing unless you're planning on a significant distributed restructuring, which doesn't make sense with 2 PCs. Edited 22 Apr 2008 by Nathan

[Pierre 1]

Sorry for my lack of a precision on this. There are 3 PLC5/40C with with each a network of about 20 Flex I/O nodes with roughly 6 groups each. What we have is a mix of about 120 I/O in each CNET network. Roughly 30% analog values the rest is digital. One of them has a DH+ network to some small remote panel gathering about 60 I/O (50% analog). Them 3 PLC exchange data through there 1785-ENET modules. On top of this, one SLC5/05 act as a bridge for transfering some ???data, commands??? between the other SLCs. This unit is faulted and no longer needed BUT we just cannot yet remove it from the network for if we do, the RSView screens slow down to a halt... no more refresh... no changing values... it is stopped. Now for the PCs. RSView runs on about 10 of them. They ALL have access to the full application. Lots of graphic. Sometimes I walk by to see all but one displaying graphics. They of course are running each of them RSLinx OEM. Now here an OPC Gateway makes sense BUT this plant has a tendancy to just add and add trends when it can. And up to now it could. We need to address a few issues here but my concern is about the Ethernet link saturation. I was wondering if we could add another 1785-ENET to take care of the trending with its own Trend Server but from what I have read, the only way would be to have the Ethernet port on the CPU unit and then the next one as this 1785-ENET module. I have not read that we could have a sonce ENET module on a PLC5/40C. We have a meeting tomorrow and I will be the one addressing the basic issues of " Why the heck you need to Trend every seconds x 36 values to display the last 24 hours on a plasma screen that don't even have 2000 pixel wide?" But this is my task. For me all of them devices are the same. Loging some data only differs from any other com task in the fact that it never stops. Once you have configured a log you have it forever... or until you decide it is not really needed. This system has been under no supervision, free to expand with no guidelines for the past years. Its crappy, its heavy and its slowing down. It has reached the "Tipping point". Now the Rockwell Sales Force suggest we just throw some money at it and all we be OK. Before dropping all these "new" old solutions I intend to educate the Users about the way data should be considered. There is a world of difference between "Nice to have", "Important", "Need to have" and just "Why the heck we log this point". So here is my situation. We are still going to have to replace all the old ACN module and the PLCs firmware to update an be a little younger (also we have hard time finding the old ACN modules) but the network is getting slow every day. All the Ethernet devices and PCs pass through an unmanaged switch. Before I log the data to an SQL database and write some Java application for all those peepers :) I wonder if what we got can easaly do it with just some good configuration? Thanks Nathan

[Nathan 7]

OK, Pierre - I should have given you more benefit of the doubt. I remember you from other posts and did a "double take" as it seemed pretty obvious. This is one where Ken or other Rockwell guys would be the most help, but I do have a few ideas and comments. 1. A Control Logix PLC can be used to interface with the PLCs and OPC Server as you described the role of your single "PLC 5 Bridge". You'll need to dig deeper with an AB expert on this one to determine if it would help in your case. My thoughts are that it depends on your backbone - how you program your data transfer, etc. 2. I'm told that KepServer EX outperforms RSLinx in a large setup. That probably doesn't help you much for the 10 clients each banging at the PLC (ouch!), but could help for your data logging portion. You really want to do what you can to aggregate the data requests with respect to your PLCs. Kepware has a free 2 hour trial to evaluate it. 3. The painful thing about lots of standalone RSViews is that they each connect to the PLCs and poll separately. Obviously, you'll want to push this as best as you can so you don't have to purchase more/recreate your application. Try slowing down your polling rates or creating a setup where idle PCs log off or jump to a screen that doesn't communicate much. You can check this in your connections listing in RSLinx. 4. I don't know enough about RSLinx Gateway to determine if your idea of using it would help. Gateway allows other RSLinx instances to connect through it. If it was well written it would group the requests from all clients and only hit the PLC once. I don't know if this is the case. The other question is whether RSLinx OEM instances can connect through a single copy of RSLinx Gateway - that's about the only way it could be cost effective. 5. I agree - trending data every second is retarded on a 24 hour display. How much historical data do you maintain? 6. Getting a newer managed switch may be a good idea. The more important point is to determine the load on the ENET module - I'm not sure how to do that, but AB/Rockwell should. Keep in mind that it's typically connections, not raw data that is more likely to overload your PLC Ethernet connection. I'm sure your hunch is correct - some good 'ol configuration management is the best step. I'd start with actual requirements things like: "see a 24 hour snapshot of data on a graph", NOT "log data every X seconds" unless it's driven by a real (legal/regulatory) requirement. Also, in theory, a distributed system would help you out, but keep in mind that it adds significant complexity. Don't let them sell you a "newer" software solution without considering engineering/development time, maintenance, etc. It's like the saying "The cheapest car is the one you already have". It sounds like you don't have a lemon or need a minivan - just a tune up.