Architecture Confusion

[dblk22vball]

I am going back and forth on how I should go about designing my next program.

 

Whatever I use, I want to be able to re-use for multiple projects.  I am not in a particular rush at the moment to create this next program, so I do have a little time to "play" around.

 

Most of my Low-level vi's are re-used on many different test programs (IR message builders, etc), but the high level program seems to run into the "Cluster of death" scenario a lot.

 

Our company currently has 3 test engineers, I am the main LabVIEW programmer.  One test engineer thinks LabVIEW is horrible and only writes in C or .Net if required.  The other test engineer is able to modify some code, but even queues and FGV's are not in his wheel house at this time.  I have done a little OOP (I do have a program using basic OOP for the Instrumentation currently deployed), but I am still very much on the basic end of the spectrum with OOP.

 

Most of the projects I am involved in require about 5+ instruments (IR COM device, Sig Gen, Freq Counter, Spec Analyzer, DMM, PSU chassis, etc), but they have been 1 UUT fixtures.  We would like to scale to using the same hardware, just an additional IR com device (one for each UUT), and the test hardware is shared between the other UUTs via switches if they do not have enough inputs.

 

Something similar to the Continuous Measurement and Logging (NI-DAQmx) example that ships with LV 2014 seems like a typical solution that has worked for many developers.  QSM, separate Logging, UI, Acquisition loops.  But I am not sure how easy it would be to scale, and how do you avoid trying to access the same hardware when running each UUT separately?  One solution is to use a For loop, to cycle through each nest location at each test step.  But this ends up being a serial process and does not save a lot of time.

 

I did a couple of the tutorials on the Actor Framework, and I am still wrapping my head around that.  I did also see the MAL Plugin framework, which had the hardware checkin and checkout.  I thought this was a nice feature as it would allow you to test many UUT with limited hardware.  But the learning curve for me seems pretty steep (for using the AF), and I am sure that my co-worker will have no idea how to support it if he ever had to.

 

 

[infinitenothing]

TestStand? You can use TS semaphores to arbitrate the equipment.

 

And regarding super clusters, a complicated system can have big clusters (lots of variables). Clusters are nice because they prove some scalability. You just want to make sure your clusters have high cohesion. Also, you want them to have well organized sub clusters. In a sense, you can treat them the same way you treat subVIs. Your top level VI or cluster shouldn't have all the code on its block diagram, it should be broken down into logical chunks.

Edited November 21, 2014 by infinitenothing