Rio gets channel definitions cleared after download

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.

Your current setup sounds like a great candidate for MQTT. There are some great videos about how to set it up in the training section of the website.

1 Like

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.

1 Like

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…

1 Like

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 and I agree. Based on what you said, this is the way.

@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.