We have a customer with a single S1 in a panel running a strategy to communicate with three additional panels each with up to four EB2 racks (11 racks total).
Each panel has it’s own HMI (Windows 7 Panel PC running PAC Display) and does a completely different thing than the other panels. To relieve some of the resource stress on the S1, I suggested they put controllers in each cabinet. (Looking at PAC Terminal, the S1 has at least 16 charts running and a Loop Time of 250 ms, sometimes as high as 500 ms that I’ve seen, which seems excessive).
I guess my question is, should I suggest using an S or R controller or a SoftPAC controller on each HMI PC? I’ve never used the SoftPAC so I don’t know how it compares with a hardware controller.
Before you add other controllers into the mix, a few options to consider that might save you needing the extra controller(s):
Are all of these devices on the same network? If so, is your PAC Display project configured to read I/O Tags directly from the I/O Units (rather than bugging the S1 more than necessary). Check PAC Display Configurator: Configure > Runtime Setup > tab:[I/O Unit tags]
Under: Configure > Refresh Times, what refresh times are you using? Try making them all 2 seconds (assuming you have shorter ones now ) to see what impact that has on your Loop Time
Do all you looping charts in your strategy have delays in them? (If you're not sure why I ask, check out form [U][B][1776](http://documents.opto22.com/1776_Optimizing_PAC_Project_System_Performance.pdf)[/B][/U]).
You mentioned multiple HMIs for each panel/PC -- are you using [[U][B]OptoOPCServer[/B][/U]](http://documents.opto22.com/1487_OptoOPCServer_Data_Sheet.pdf)?
Of course, we would be happy for you to buy loads of controllers, even if you just want to use them for lovely desk decorations. However, which ones to buy and if/why you should include them in this system might depend on a few other things. Like:
What’s the distance between these panels and how important is it that each can function on it’s own in the even that say, someone breaks the network connection between them?
There’s something to be said for distributed control. For more on that topic check out [U][B]this white paper[/B][/U] which covers:
Minimizing single points of failure,
Spreading the load (like you mentioned), and
Maximizing scalability
You mentioned 4 panels now, might there be more in the future?
I’m also wondering, you mentioned up to 16 charts running on that S1, how is that strategy organized? (Would it be simple to break out various parts by panel, or is it pretty intermingled?
So, most of their issues are network related. The entire facility, PLCs and office, were on the same subnet. They are in the process of correcting this and are already seeing improvements.
Another thing I noticed was the EB2s where daisy chained, Ethernet cable running from one EB2 to the next and so forth. I don’t think they were going through a switch, just from one cabinet to the next. Usually, I would put an Ethernet switch in a cabinet then run each controller/brain directly to the switch. Seems like it would cut down on unnecessary traffic. I’ve suggested they do this.
Also, running PAC Display on the computer in the cabinet seems to be fairly quick, since the brains are right there. Running the same PAC Display on a computer in the office was sluggish. This was further evidence that there were network issues.
Separating the controller tasks just seemed like the next logical step. Each cabinet does something different and independent, so why not separate controllers. Not only would it spread the load but also make diagnostics easier.
Anyway, that’s my opinion. The customer was just wondering if they could use SoftPAC instead of a hardware controller since each cabinet already has a PanelPC. BTW the PanelPCs are running Windows 7 with an Intel i7 processor at around 3 GHz, if that matters.
Without looking at your strategy, I would guess you have plenty of controller.
We have multiple installations with a S-1 connected to 20+ racks.
I’d suggest looking at isolating the IO from the rest of network. Use the “second” Ethernet port on the S-1. Configure it with a non-routable ip address like 192.168.0.x, subnet 255.255.255.0. Configure your I/O with the same scheme. This will take all your I/O traffic off the common network. Use the “first” Ethernet port on the S-1 to talk to your HMIs.
Daisy-chaining the EBs is not a problem as long as they do not exceed the max length for your CATx cabling…I’ve done it both ways…with a switch and daisy chaining.
