Multiple R1's for semi-redundancy

New to the forum. Did some work with a LCSX and Factory Floor, but new to the PAC platform. I have a project I am working on that I am looking for some guidance. I will be using two 16 ch. racks.

Is the controller and the brain two separate peices of hardware in the R1?

Can I have R1’s on both racks (both loaded with the same strategy) and have the R1 on Rack A be the controller for both Rack A & B?

If so, is it possible to switch to the controller on Rack B and have it control the I/O on Rack A & B (if there is a problem with the controller on Rack A)?

If not, in case of a failure of the R1 on Rack A, is it possible to switch to the R1 on Rack B to control the I/O on just Rack B?

Hello randall_d,

Welcome to the OptoForums!

The SNAP-PAC-R1 (where R stands for Rack) is both a controller and a brain in the same rack-mounted hardware, which sits on the same rack as your (up to) 16 I/O modules.

Re: your question about the R1 Rack A as the controller for both Rack A & B – yes, but… The strategy in A’s R1 could have an I/O Unit for itself (e.g. IP address 127.0.0.1) and another for the R1 on rack B. However, the strategy’s wouldn’t be EXACTLY the same, since they’d have different IP addresses for the “other” controller, and I’m not sure why you’d want to do that.

When you talk about “failure” – what kind do you anticipate? Loss of power? Communication? We do have some options for “redundancy” but that’s usually for a complete duplication of the whole system. And since both the controller AND the brain are the same hardware, whatever might go wrong with one (power, etc.) would usually knock out the other.

Can you tell us a little more about your application and concerns re: possible failures?

Thanks,
-OptoMary

By failure I mean that the controller stops functioning. I have to believe that Opto 22 has had controllers fail just “because”. Electronics fail. Maybe the building sustains a lightning strike and one of the R1’s survived and the other didn’t.

I am controlling 16 air compressors. I have half of the output modules (compressors 1-8) on Rack A and the other half (compressors 9-16) on the Rack B. Let’s say that the R1 on Rack B fails. Won’t the R1 on Rack A still control the I/O (compressors 1-8) on its own rack?

If so, if needed, can I have the R1 on Rack B be made to control the I/O (compressors 9-16) on its own rack? Would I need to have a different strategy loaded into the controller on Rack B to do it? Then if Controller B got a signal (lack of a handshake from Controller A, or even the manual closure of a switched input in Rack B), couldn’t it then run its own strategy (or charts on an already running strategy) in Controller B to control the I/O in its own rack?

Sure, stuff happens. In the case of something as serious as a lightening strike knocking out the R1 on Rack B, I’m saying the I/O on that same Rack B is also likely to a problem too, since they’re all right there on the same rack.

But yes, at that point, you could have the R1 on Rack A figure out that Rack B is gone (check out [U][B]this related[/B][/U] thread for options on figuring out how, for exampling using a [URL=“http://www.opto22.com/site/downloads/dl_drilldown.aspx?aid=4170”][U][B]PING[/B][/U]).

And yes, you’d have an already-running strategy there on Rack A, that’s just in a loop periodically checking on Rack B, which could then start charts, etc. if/when B is gone. Those charts and/or subroutines with your logic in A could be identical to what’s running on B. The import/export chart option and/or use of subroutines makes it easy to share pieces between similar strategies.