Search the Community

I see a lot of knowledgeable minds around here, so here's my challenge. I have a test system that will have, at the user interface level per channel, 3 inputs and 2 outputs that together encompass a simple test scenario. I would like that scheme repeated up to 10 times in a single application so you could watch a bank of units under test, allowing both scripted or manual manipulation of inputs; plus viewing and logging of the outputs. Here is an example of what I think I want the user to interact with: I would like to associate each of these "subpanels" (not to be confused with actual subpanels - yet) with a LabVIEW class object that will handle the interface with hardware. All channels would be coordinated by a top-level VI (let's call it the Controller) that aggregates the channels and provides the ability to parse script files to press buttons and stuff. Here's where I'm having trouble, conceptually. One solution seems to be to spin off a new asynchronous call-and-collect VI (in the form of the pictured panel as a brat VI) that has the brat throw its control references into a queue for the Controller to catch and store for later access. The brat would receive stuff like a user stop event and the hardware session's class object when first called. I would then create an array a grid of 10 Sub Panel controls on the Controller's front panel and place each brat VI into its own Sub Panel like a facade. The core of the hardware IO would be built into the brat VI (operating on the class objects), with the Controller pulling the strings and catching outputs and user interaction through dynamically registered events and property nodes operating on the brat's references. This all seems like it should all be workable and isn't fundamentally new to me. Does this seem reasonable? Another - much less (in)formed - concept I had was to avoid the ACBR brat structure entirely and implement this "subpanel" as an XControl that I can treat like a regular control on my Controller's front panel. I think of XControls because I can't have a cluster with both inputs and ouputs (unless I access the indicators with property nodes and fake it, I think), though I am actually only assuming that XControls allow both at once, or the equivalent behavior. In this scenario, the controller would retain an array of my hardware session's class objects and index them associated with each control. This way, the controller would invoke a hardware IO operation in a for loop to iterate across all devices. Similarly, when one of the XControls had a button clicked, the controller would see the value change event, figure out which one fired it, and do some function for only that associated hardware. I've never implemented an XControl before - at all - so the first solution is going to be the easier one for me. Is there a good argument for going the XControl route over the asynchronous-brats-with-Sub-Panel route? Thank you for your inputs, and sorry for the wall of text!