Years ago I asked a more experienced SNAP PAC designer if the IO of a SNAP-PAC-R2 running a strategy could be added as IO on a different strategy on a different controller. I was told this cannot be done. I was recently asked the same question and initially responded the same, but decided to look for the reason this is the case and after looking through user guides and other documentation, I have come up empty. Can IO be added to more than one controller?
We do this frequently, but we try to do it only with input points, not outputs. It gets pretty dangerous to have different strategies potentially fighting over the same output point. Just be careful that you define your points consistently (scaling, features, etc.). Also, be careful about using features like on time totalization, latching, etc. If you reset a latch with Controller A, Controller B won’t know anything about it.
Just as @varland said, yes you can add them, we have a heap of customers that do it… But just be mindful of more than one strategy or event reaction writing to the outputs. If you keep in mind that its sort of a ‘read only’ I/O unit in the second controller, then you will have no issues.
Here is how you configure them.
Go into your first controller and add the second controller as either a generic MMP device as in this screen shot, or add the other controller type.
But either way, just pop it in your strategy tree and you are up and running.
Have a think about how you are going to enable communications to it, if the network drops, keep in mind to not have both strategies fighting over the same outputs and jobs done.
Thanks Varland and Beno, I suppose the response I was given years ago was being overly cautious to avoid conflicts.
Actually, you can add them to another strategy, however, the real problem is that each controller will attempt to configure the IO each time each controller starts running. You have to prevent the 2nd, 3rd, etc. controllers from writing the configuration out to the brain on startup.
Also, in the past I have had issues with ethernet timeouts to shared brains, especially if the brains are being hammered every 500 ms for an update by each controller. I had a single strategy being downloaded to all three controllers, each controller using the IP address to determine charts to run, etc. All 3 controllers where were updating IO from each of the other brains, and this did actually work pretty good, except I would see an occasional timeout.
