Is it ok to assign IO to more than one controller or will that cause comm issues? In other words. I have an R1 controller controlling one leach field and then I have 2 E1 brains at a second leach field. Is it ok to assign the E1s to the R1 controller and also assign them to our Main S1 Controller at the plant so either Controller can control the E1s directly or is it best to use REST or scratch pad instead?
I do this and it works fine when the second controller is setup as generic MMP. I do this to access the scratchpad with the built in commands. If setting them both up as E1s, then I would want to make sure my IO configuration was the same on both projects.
I do get warnings about PIDs being configured already or something like that in the message log for the controller, but everything works okay.
I also do this a lot.
I might have a PAC R doing some local control, but then the master PAC S needs to get some I/O data from it.
So I just export the PAC R I/O config once I am happy with it and import it into the PAC S.
Now you can see the I/O from each controller.
Just keep in mind that you probably only want to read the I/O from the master, that way you don’t have two strategies fighting over the one digital point… hehe… ask me how much fun that can be…
Why is that pesky light flickering again!
Are you the one turning my garage light on and off and on and off and on and off and on and off and on…???
Wow I would have assumed this was a no-no, but I guess if you keep the I/o configurations up to date with each other it works.
Here is a little more info. Remember that each controller when it boots up or starts, will send it’s config to the brain (whether it is a EB1 or an R1 brain). The problem here is, if you have any items configured (such as PID loops event reactions or IO points), they will be configured as the last controller to send it’s config to the brain. Therefore, if there is a difference, then the controller that sent it’s config first will have issues…
You can read any point (inputs or outputs) from either controller without issues, you can also writ to any point as well. However, if you do intend to write to the same point from one controller that another controller is writing to, the output will be what ever the state of the last controller to write to it. Also, if you are reading or writing to it the brain very fast with both controllers, either one of these controllers may have timeouts or will pop a message that it failed on first try.
You can also do this using peer to peer (scratchpad). This way you can do logic in the controller to control the outcome by the R1 for instance. IE; the R1 becomes the master and the S1 only has sub-control of the brain or visa versa.
Ha. I’ve had stuff speed up, slow down, speed up, slow down…