Ah ben, the good old ‘Set I/O Unit Configured Flag’ command. Must bring back some memories of the hospital days?
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