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

Just some ideas:* timestamp each reading* Instead of logging the timestamp to the file, you can raise a flag 'Old data' or the like. I think the OPC protocol has some flag that indicates how new/recent any value is. Maybe you want to copy it from this standard.* In such scenarios, I'd just have the readings broadcasting the data via a notifier all the time instead of the temproary callback notifier. The logger (or whatever) just goes through the list of notifiers and takes the most recent value. Felix

LabVIEW

Architecture Review

Solved!

Author

Thank you, both. That's some really insightful info 🙂

Felix, that nugget is superb, I have been wondering how one might implement a plug-in architecture in LabVIEW.

_____________________________
- Cheers, Ed

Message 11 of 12

(630 Views)

The coolest plug-in architecture I've written so far can be found in my State Machine Compiler. It is written in 7.1 and might be broken with newer versions due to some scripting nodes. Just check the Parser and the Verification Modules. I think they will provide for an easy scaling once I'll (or someone else) continue on that project.

Felix