We are running multiple strategies on epic controllers that all have the same RIO defined.
On every strategy, the first RIO channel is a digital output that all strategies need to be able to read.
On one of our strategies, the next six channels are three analog then three digital inputs.
When I download the strategy that has the seven channels defined, the RIO shows those channels defined when I log into it. If I follow that download with one of the other strategies, all except the first channel has been wiped clear.
Is there a solution to this so that all seven channels stay defined through any downloads to any controller?
Anyone know if this is the same for groov modules?
Having multiple controllers using a common IO unit is not supported. Whenever a controller does a download or restart it wants to reinitialize the IO. My only suggestion if you must do this is to make sure that the IO configuration is identical on each Epic. But there are other issues that may cause problems down the road.
Is this the official Opto position ā that shared ethernet I/O is not supported? I know I previously had conversations with Mary St. John about needing to be careful with outputs, but Iāve always operated under the assumption that inputs can be shared between controllers without issue.
I have done this at some locations and havenāt ran into any show stopping issues. I do get warnings in the event log about PID loops being configured outside the controller or something like that.
The key is to make sure every controller has the IO configuration setup the exact same way (scaling and all) like Norm_Freeman1 stated:
The brains/IO is initialized at first run of the strategy after a download so the last one to start wins the configuration contest. You can disable the initial comm to the brain and there is a command to tell the controller that the IO is already configured before you enable communications, but I wouldnāt trust that as much as making sure all strategies have the same config.
Official position? Not sure anyone here would go āon recordā either way on this question.
We love how our customers use our stuff in so many different ways in so many different applications.
It would be tough for Opto to officially say to any of our customers how they should or shouldnāt use our products.
I personally have done exactly the same method that @philip and @Norm_Freeman1 have said and (way before I knew her) took Marys advice and just ensured that I did not have one controller turning an output on and another chart in another controller turning the same output off.
I have also had cases where I have had one controller with the I/O configuration and all the other controllers had āgeneric MMP deviceā for that that I/O rack in their strategy.
Think of it as 6 people all talking to one person at the same time. As long as none of them are shouting conflicting instructions perhaps it will all work outā¦
I get the concept. But there are two sides to the analogy @Norm_Freeman1ā¦ It could also be seen as 6 people listening to one person at the same time. Thereās no problem with that as long as they all understand the language (as long as an input point on a network I/O unit is configured the same way on each client controller).
I donāt love having to have the entire I/O unit configured in every strategy. My opinion may not matter, but I donāt think thatās how it should work. In my case, I have a digital input on my RIO that tells me whether or not a security alarm is on or not. Many other controllers in my building use this input to make decisions. I also have a few digital outputs and some analog inputs on my RIO. Only one controller should talk to those devices. However, if I donāt configure those devices in every strategy, I lose the configuration every time I download a strategy that doesnāt use them. If I had my way, when I leave a point āunconfiguredā in PAC Control, the download simply wouldnāt send any configuration to those channels. I obviously donāt know all the technical details behind whether or not this would even be possible, but thatās what makes sense to me.
Having to define every I/O point increases the chances that one of my programmers is going to accidentally do something with an I/O device that they shouldnāt. I know I can find a workaround for the issue, but I wish I didnāt need to.
ā¦and I want points I removed to be removed from the brainā¦ you can see why it is the way it is.
I would recommend the following approach, which is probably more āstandardā. On the controller that needs all the points, have that controller put the security alarm digital input into the scratchpad. Then setup a Generic OptoMMP IO on the other strategies that read that value. You could also read the digital point directly by using the ReadNumFromIoUnitMemMap command on a generic OptoMMP device.
@philip: it seems like there are two different things. Configuring a channel as unused wipes configuration. Not configuring a channel at all doesnāt write anything to the channel.
But, just because thatās what I want or thatās what makes sense to me doesnāt make it the best way. Iāll adapt.
