LabVIEW
Maintaining correct hardware state after reconnection
This is something that I have never found an elegant solution to. I have refrained from posting it on here because it is quite a broad question which is difficult to simplify enough to fit in one post.
I am looking for advice on a design pattern for communication with hardware that can have multiple states
I will give a simple example that I am working on at the moment; a heater with TCP comms with the following commands/states:
- Turn on/off
- Set heater power
Lets say I have module with a QMH (like in the snippet below which is an example of how I normally approach this) which deals with the connection. Other areas of the code can enqueue a command such as turn on, or set power to the queue and that is then sent to the heater.
This means that I can have the following timeline
- System turn on
- Successful connection to the heater
- Another area of the code tells the heater to turn on
- At some point the heater disconnects (Lets say the network cable is unplugged)
- The other area of the code might notice this and then put the entire system into standby which involves enqueuing a command to turn the heater off (This cannot be processed because the heater is not current connected)
Alternatively the rest of the system may continue to operate without the heater and could send other commands to the QMH despite the fact the heater is disconnected, lets say a set power command
Either way the heater is actually operating in a different state to the one that the software actually wants - The system reconnects to the heater......
This is where my problem lies. Can anyone suggest a way of then reinitialising the heater to the state that the system actually wants.
Here are some ways that I have approached this in the past:
- Process all queue elements and actually send the relevant commands to the heater:
If there are several commands enqueued, (set power 50%, turn off, turn on, turn off for example) The heater would actually toggle through all of these states. This may happen so quickly that it isn't an issue, equally this might be an issue, if nothing else it doesn't give the user a very good impression of the software if the heater appears to do random things upon reconnection (I had this when I was communicating with hardware with a noisy pump, the pump would turn off and then back on upon reconnection which left a very poor impression as the customer had the feel that the system had a tendency to do 'random' things.) - Upon disconnection the entire system needs to go into standby to prevent any more automatic control of the heater, the user then needs to manually start it again upon reconnection. Upon reconnection the first thing the module would do is turn the heater off.
If there are only manual controls they could be set to 'Off' and disabled to achieve the same affect. The user would then have to manually turn the heater back on again once it has disconnected. This can be automated but we are back to needing some area of the code to maintain the commanded state of the heater.
This approach is sometimes required if the hardware is critical to the process, but sometimes it is not. In the cases where it is not it can be irritating if the entire system stops, especially when you are communicating with lots of hardware - Upon reconnection the module flushes the queue and handles all commands without sending any commands to the hardware, instead it just updates the internal state of the module. Once there are no elements left some code runs which issues all relevant commands to the hardware to initialise it into the correct state.
This is currently my preferred method but does mean that I end up duplicating code a little bit. I have to handle the commands in the initialisation logic and in the QMH.
A long question, thanks for sticking with me.
Does anyone have any improvements/thoughts on any of these approaches?
