automationtx

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.

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!