"Set I/O Unit Configured Flag"

PAC Project
1

Posting this on behalf of a customer that came through our training program a few months ago…

He’s got two controllers talking to the one rack of I/O.
All SNAP hardware (two PAC S1 controllers and an EB).
He’s set it up as a bit of a home-grown redundant system, he can manually or automatically switch between controllers. (I’m simplifying things here, but it’s enough to give a feel for the source of the question).

So, in each controller the rack of I/O is configured, but to make things interesting, only one of the controllers has the entire rack configured, in the other, only the points it needs are configured.
In both of the controllers he has the I/O rack configured the same;


The reason for this is that we don’t want the controllers to be sending their configuration to the I/O rack.
In the power up chart, we also use the command ‘Set I/O Unit Configured Flag’.
Same reasoning here, we don’t want the controllers sending their config to the rack.
We then issue the command ‘Enable Communication to All I/O Units’.

So, the controller, either one, powers up, runs the power up chart, which says, ‘don’t bother the I/O unit, it’s all good, just start talking to the unit as you need’.
The points, because they have not been reconfigured don’t change state, as far as the I/O unit is concerned, nothing has happened.

Here is our question then;
Should he be saving his configuration to flash every so often on the I/O unit?
This way the I/O rack has its full configuration every time it boots up… I mean its not going to get it from the controller, we have gone to great pains to ensure that it doesn’t, but it needs to know what modules are in what positions, what scaling etc it has…

Anyone done this sort of thing?
Got any thoughts you could share?

Thanks,

Ben.

2

Ah ben, the good old ‘Set I/O Unit Configured Flag’ command. Must bring back some memories of the hospital days?:smiley:

Here something from the top of my dome… if one of the S1’s has the full I/O unit configuration and the other a simplified configuration, as long as the scaling is the same, wouldn’t it make sense that the controller with the full config can configure the I/O unit and the S1 with the simplified config follows the Set I/O Unit Configured Flag? A save to flash would have to happen at some stage (maybe in the powerup chart of the strategy or a manual save from PAC Control?) so that if a power cycle to the brain happens the configuration will still be there. this way if the brains configuration changes, the ‘master’ controller will write the new I/O unit configuration to the brain. does that make sense?

Set I/O Unit Configured Flag command is still used at the hospital to stop mistic PID loops from spiking after downloading a strategy. The reason the spiking occurs (and correct me if i’m wrong here ben, i don’t know the nuts and bolts but this seems the most likely scenario) is that the PID loops on the Mistic B3000 or B200’s have been configured to obtain the input from Host (ie: being written to by the controller). When the controller strategy is run and initializes the I/O, it writes the PID configuration and essentially blows away the current value in the input (sets it to 0?). this then causes the PID loop to recalculate on a value of 0 and will either drive something open or closed (for the hospital this is a heating valve in an air con system). the strategy then loops around and writes the value to the input and the pid then starts calculating using the correct values. this used to cause discomfort for the patrons of the hospital because they would get a burst of hot air until the pid corrects and settles. on a 35°C day this is not nice.
The solution was to untick the box as ben shows above and in the powerup chart and issue the command ‘Set I/O Unit Configured Flag’. once this happened, problem solved. we recently installed some mistic b3000 I/O units configured on a S1 controller and without applying the same logic as above, the PID loops spiked.
This is not a problem if the input to the PID is configured to be an input on the I/O unit.

There is a downside to applying this method. what happens when you add some more I/O to the unit? the I/O unit needs to be re-configured. i know that there used to be a command in OptoControl called ‘Configure I/O Unit’ which you could issue to reconfigure the unit. This command has been lost in PAC Control (until just recently i see, i just opened PACControl 9.1 and found ‘Clear I/O Unit Configured Flag’) and made it a bit tricky to reconfigure the I/O unit. generally a clear eeprom from Inspect I/O in PAC Control would correct the issue, but sometimes this would not work and a power cycle would be needed.
Adding I/O to our mistic brains doesn’t happen very often but when it does it can be a bit tricky.

Sorry about the essay but there may be some people who are experiencing this same problem with their mistic pid loops.

Nick

3

I’m questioning the need to even save configuration to flash. I haven’t used the command unless I make changes to F° from C° or other network security changes. My shared I/O ethernet racks are talking to several S2 controllers. All read the units, but only the S2 acting as the master writes to specific shared points. Points specific only to a particular S2 are only written by that controller whether it is acting as a the master or not.

Fortunately, the PID loops I do use never change except the set point once tuned. I also have variables setup with the “default” values. If there is a power cycle or some other type of event then I SET the PID Gain, Int, D etc one time only from powerup. This ensures my PID values are restored.

Unless I make a change to the I/O rack like adding a point, why would I need to save to flash? Even if I don’t, the rack tells the controller it needs to be configured. I never restore a saved flash file after a firmware upgrade. I just download the control program and all is happy.

Am I missing something?