PAC R or EPIC Redundancy - PACDisplay or PACControl

PAC Project
1

In PACDisplay (PACProject as a whole) - instead of setting up the control engine IP address for the Primary and Secondary IP Address for a single Controller, has anyone ever tried to setup the Primary IP to one Controller and the Secondary IP to another Controller (both running the same strategy) ?

The scenario that I am looking at is a redundant IO setup where both controllers would be loaded with the same configuration (same IO). In the event of loss of communication of the primary controller, was thinking that PACDisplay (or PACControl looking at a peer to peer setup) could switch to the secondary controller (like we do on network failure).

Of course both the Primary and Secondary Controllers would have to be on the same subnet:
Primary Controller 192.168.1.1
Secondary Controller 192.168.1.2

I havenā€™t had the chance to test this setup (yet) but was wondering if anyone has ever tried this and/or if it would work (with PACDisplay or PACControl)?

I realize that redundant IO has its own list of issues, at this point just want to know PACDisplay (and PACControl via OPTOMMP device) would be able to work in this fashion.

2

Tried the setup and it works - now the question ā€œis this a good ideaā€?

@Beno is there a way to force PACDisplay between Primary and Secondary Addresses other than Configuration Status under View (in PACDisplay Runtime)?

Would like to have the controller (whichever is active when both are running / good) to swap Primary / Secondary based on command from logic (similar to using Application Manager to initiate a program based on a trigger tag).

3

I went down the rabbit hole. Itā€™s an interesting question, and I am still undecided if itā€™s a good idea or not.

Iā€™m sure you saw this in the PAC Display users guide, page 45:

image
image979Ɨ601 158 KB

Itā€™s the main reason I am undecidedā€¦ That and the answer to your other question:

I looked pretty hard, including reviewing the 52 forum search results for the word ā€˜redundantā€™. We added the MMP address for the ROC kit status, but I could not find a way to switch back and forth between the primary and the secondary.
It will have to be something that the operators are trained to do.

Sorry I donā€™t have stronger words of wisdom on this one Lou.

4

@Beno thanks for your insight.
I also went down the rabbit hole on this one.

From a control perspective (peer to peer interfacing) the approach works (because I can change between primary and secondary networks (or controllers) within logic) but from on operator interface perspective it could could get ugly.

I decided to use an additional controller that will aggregate data, operator interfacing, tuning (adjustments will get pushed to both controllers), etc. when everything is working correctly. In the event of a network or IO rack failure (or loss of this aggregate controller) the individual IO Rack / Controllers ensure local control / operation (selection between IO racks will be handled at the rack level).

1 Like