LabVIEW
Architecture Review
Solved!
Summary of Queries:
- Would you imagine my design to be suitable,
should the need arise to scale up even further.
- How could I
improve on potential race conditions in data logging.
I
work in Catalyst Research, where I support about 100 scientists which
includes building automated test rigs. I have a joint honours degree
and 5 years working experience in both electronics and software
engineering, of which 3 years is LabVIEW development.
I can
bounce around electronics ideas on site, but as I am the only
software person, I was hoping some of you could take 10 minutes and
review my general software architecture.
The rigs will usually
have several pieces of hardware attached, Usually in the form of:
-
NI USB DAQ Device
- Eurotherm Controllers (Mini8 controller, 2000
series, 3000 series) on RS232, 485 or TCP.
-
The hardware protocol is irrelevant, as I communicate with them via
OCP
- Other RS232/RS485 instruments, communicating via NI VISA.
-
Other USB instruments, communicating via directx, or device drivers,
et al.
A typically run will last upwards of 12 hours, and so
they need to be safe to leave unattended. Mostly this is in the form
of hardware interlocks, as I don't trust computers not to lock up.
Furthermore, this means actual error handling in the software rather
than popping an error message up on screen 😛
I like my
software designs to be modular and abstracted (although never to
excess). Each hardware device is managed in its own class data
structure; Values are read, buffered, and saved to a shift register.
Values are continually compared against safe operating limits. The
only time an external, or higher level VI is called from the
controller is a config data structure during initialisation. Actions
can be sent to the device controller through a queue. If a value goes
outside of safe operating conditions, the particular condition is
sent to an alarm handler via a queue.
Thankfully, an
experiment can often be organised into a sequence of user
configurable steps. This takes the form of an array of clusters. The
cluster instance stores setpoints for temperatures, dwell times,
device states and so on. When a sequence step is advanced, the
setpoints are fed by queues to each device controller. This all works
fine and dandy.
A level above that, test runs can be queued as
well; a user will put a sample into the rig, log on to the system,
create a test run sequence, and leave it to get on with it. I should
also add that sequences and run conditions are saved to disk, so
should the PC crash, things can get up and running again
quickly.
With regards to the user interface; that is all it
is. None of the VIs in the UI deal with the running of the rig.
Changes made to the UI are written to the config file data structure,
directly to the device controllers, alarm handler, or some
miscellaneous process controller. The UI displayed readings have a
set update rate, which queries data from each device controller
At
the requests of the scientists, all data that can be logged, is
logged, at a user defined frequency. Once the log file reaches a
number of lines, it is closed and an incremented filename is
continued. This is so they can be imported into excel, or to ease
strain on a computer post processing the data. Each log iteration,
data is queried from wherever readings are taken.
I seem to
have a stable, reliable and safe way of building the rigs, but I
remain unsatisfied with my tried methods of presenting data to the
user and logging data. Given that data is being read from a number of
sources, I want a good way of keeping the data reasonably
synchronised. (Reasonable being under 50ms) Temperatures, pH levels,
pressures, Mass Flow Controllers, and motorised actuators don't
fluctuate enough that an accuracy of more than a few hundred Hertz
will matter (although oversampling and smoothing occur inside the data controller / on the device).
My current method is creating a temporary notifier and adding it to the front of the device queue. On the next device iteration, it is popped off the queue and the last buffered value is returned via the notifier to the calling function. I favour this over an action engine; because as there was no easy way to indicate when to take a reading, every time the device controller took a reading, it was necessary to update the action engine. I am still unhappy with my current method of querying data, as I cannot ensure that new values have been updated in the device controllers when the data logging section queries the data. This may even cause the same value to be logged. (Race condition) This problem would still persist with an action engine.
Lets say the device controller is running slowly for whatever reason. The automatic antivirus scanner has kicked in, and the shift register is being updated at 2 Hz (500ms)
If the data logging was to be querying the device data at 5Hz (200ms) then it would be logging the same value every other reading.
I don't want to have to resort to hacking in some flags indicating that the values have been updated, as this would make the data logging hang for readings and not have the correct timestamp. I am aware that a computer is not a real time system, but timestamps should be regular and correct to a few ms.
Cheers Felix, I reckon my best bet would be to broadcast.
I do think it's a bit of a shame that there is always lots of help for those learning a programming language, but it dwindles a bit once you need guidelines on how to design a large system 😞 I guess it is largely to do with needing to know the problem intimately before designing the system, so casual aid is a lot more difficult
Hi all, sorry for the delayed reply, I had a few days off 🙂
Mark, that's a great link to some sound software design theory
ST5, My current hardware controllers are based on a state machine as you described. The class holds any data regarding connection addresses and references. I would describe my structure as a queued-state-machine, because other parts of the software can queue actions to the controller to perform an action such as changing a COM port or enabling/disabling reading of an unused channel. Additional states I use include signal conditioning and limit checking.
Ben, I think I really need to find a spare week somewhere and do the LV advanced training course, but in the mean time, I think I can summarise:
In the system I currently implement, data needs to be constantly streaming into the system for safety checking. This data is also used in a number of other locations, namely; safe limit checking, logging, PID controller, displaying to user. Following Felix's suggestion, I am broadcasting the data from a notifier, which is updated at the speed it takes to read, buffer and prepare the data which is only a few milisec. From the looks of it, this is a similar approach to the one outlined in your powerpoint presentation; A liberal use of state machines and the synchronisation palette.
This is holding up for the time being but if I need to run an even more complex rig with a number of RS232/485/USB devices, I am unsure how stable and quick the system would be. The way I would fix this would be to put hardware read/write directly in the most greedy data user, the PID controller(s) and notify the other data sinks, but I would lose the abstraction of the hardware checking. Alternately, the whole hardware state machine could go in the PID loop, but then I might as well be sharing data around as above.
Basically, I just need some peers to be able to share and exaplain my ideas to, and steer me away from pit traps. Even just a thumbs up to my current architecture would be great
Here is some stuff from another app
where I was concerned about safety since I had 4 PIDs that if out of control would be bad.
This is a rough interaction diagram to show how the various componenets interact. THe import point in this diagram is that all Output Control (an AE) functions are invoked via the "Safety Limits" ( another AE).
The dotted lines are for error and exception handling and in normal conditions can be ignored. THe following is a cut and paste of my notes to myself that were transfered to the code.
have fun,
Ben
