automationtx

One thing to think about is the possibility of organizing instruments into "subsystems", so the higher level program controls subsystems and each subsystem deals with a limited number of instruments that work together. Then no part of the program is trying to juggle too many parts, and you can test the subsystems independently. It depends if your application can be organized into subsystems ("VacuumSystem", "PowerSystem"). I think that is called the "Facade Pattern" in OOP.

Personally, I usually find it worthwhile to give each instrument a VI running in parallel that handles all communication with it. Then any feature like connection monitoring (as Daklu mentioned) can be made a part of this VI; this can include things like alarm conditions, or statistics gathering, or even active things like PID control (the first instrument I ever did this way was a PID temperature controller). Think of this as a higher-level driver for the instrument, which the rest of the program manipulates.

You can use a class to represent or proxy for each subsystem or instrument; this class would mainly contain the communication method to the parallel-running VI. Daklu's "Slave loop" is an example. You can either write API methods for this class (as Daklu does) or send "messages" to this object (which I've been experimenting with recently).

Thanks, I do like this approach. The separate VI's organized as subsystems seem like the most logical flow. I'll just have to master one of the messaging options discussed. I am not an oop programmer yet but I can see clear benifits to the approach and enforced modularity of oop. I'll check out the facade pattern. In general, the best term I've read to describe what I've been looking for is "a hardware abstraction layer".

I appreciate Todd and Daklu's running conversation. Lots to learn there.

This is exactly the kind of problem I've been trying to solve. I really like using classes, since the instruments must sometimes be swapped out. But I can't quite figure out where to keep the class wires so that they're available to the tests AND to some other processes (simulation, for example).

Have you found an example anywhere? I've found it very odd that the most complex example out there just talks to two drivers, and does not do it very well. Meaning, no restart ability ect

What is the the best way to organize code when your core program has to manage several instruments and device drivers? I need to have several instrument drivers up and running while my state machine operates. I have to talk to about 10 devices and coordinate their actions. I have to handle the case where I loose communications with some of them, in which case I need to be able to try to re-initiate communications. How do you handle this when you have to communicate with 100 devices? Surely this is not unique? I am looking for a modular approach so we can test and debug without too much going on in one vi.

It seem like this is the problem that LabView is made for, but I have not come up with a good architecture. It could be I just don't know how to phrase the problem correctly for a google or NI search! Thanks for any suggestions you can give!