RnDMonkey

I'm interested in this as well now, for a school project. Any update on 1.0? Also I just signed up for the beta. Cool stuff!

I had to chew on what you said for a while before really visualizing what you were saying. I decided to go with ACBR for a few reasons: 1. I'd like each front panel to be controllable independently 2. I don't know how many nodes will be run, up to 10 total 3. I want to be able to pick up and drop nodes without affecting others I know that these issues are surmountable using a synchronous call model, but I feel like it's just easier to mount and unmount them asynchronously and have the nodes shut down if they see that they are no longer in their sub panels.

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!

Well, after a full system restart, the menu options are back, and creating a new command worked! Amazing what restarting a Winblows machine can do! Ryan R.

This is not going well for me at all. The springboard just won't work. Between the package being installed to a different location than the springboard expects, and the attached casting error, I can't get it to work. Ryan R.

Very, very cool, Norm. Let's say I wanted to remotely monitor a test system. Would it be breaking to have the remote system broadcast its disposition to the entire network every 30 seconds or so, ignoring errors in the case that no listeners are running? What are the limits of data types that can be passed? What would be the ideal way to show the entire front panel of the remote system? Duplicate the front panel on a listener, bundle the data on the sender, then unbundle on the listener? Edit: I'm imagining more than just the remote panel capabilities built into LabVIEW. Edit 2: So I upgraded from 1.12.0.27 (installed when I installed TLB`, I think) to the version attached here (1.14.0.29), and now the REx»New Command button is gone from my tools menu, and the examples folder went from having the source files shown in your video, to only having the Listener exe and ini in it. It's like it uninstalled what I had and didn't replace it. I did uninstall the whole package and reinstall it, and restart LabVIEW, but no joy. Edit 3: Ok, I found the demos, at least. Looks like everything is in user.lib now. Were the tools menu options supposed to go away? Ryan R.

Okay, Norm, I'm soon to embark on a journey through your minds. I'm planning on refactoring an automated test system into using TLB`. Generally speaking, the current program takes a start command from a front panel button OR a boolean output from a VI that runs in a loop that samples an input to a DAQ from a switch. Then it goes through a series of steps like engaging a couple solenoids, reading from a laser displacement meter while adjusting a servo, making adjustments to device parameters, and displaying and logging results. To put it in your framework (tell me if I'm mistaken), I would trigger the start by either an event that catches the start button press and fires off a trigger to "start test", or by having the VI that reads my DAQ's switch input live in the "Idle" action case of the main loop and - what? Have a case in the idle action that sees this and enqueues the "start test" trigger itself? What about subsequent test steps? Should I have the "start test" system trigger case in the idle state case enqueue "first test step, update display" into the action engine (terminology?), and "testing" into the state, etc? Or should I have the transition completion after each action while in the "testing" case result in an "update display" action, possibly using an element in the mothercluster to signal to provide the next step in the test? I guess what I'm really getting at, is how to I intersperse regular display updates in with the steps of a test sequence, or, how do I keep the sequence running without enqueuing all the actions at once when the initial "start test" system trigger is sent? Ryan R.

I love this design pattern. Gotta practice with it when I can.

Website is still down for me, as Stephen indicated.

Bump? I'm using LV2013 and I'd like to give this a go, but how? I installed the base 2.0.5 package from https://decibel.ni.com/content/groups/labview-apis/blog/2009/11/19/labview-speak--programming-lv-through-voice-commands but I can't install the plugin pack (apparently, my version of LabVIEW isn't compatible).

I don't understand why the funding goal was a full $750k. Can anybody tell? This seems way, way too high given the project.

HA! HA! HA!

Okay, so the requirement is that dynamic dispatch VIs have the same name, so they must have to have separate folders on disk (these are still actual VI files, and not embedded in anything else, correct?). I've been burned by cross-linked references, so am I to assume that the strong linking of the .lvclass files (and the fact that LabVIEW seems to not attempt to automatically find missing members) to their member VIs will prevent things from getting messed up? Ryan R.

I see in VIPM that there is the OpenG Toolkit, then the individual packages as well. Is the intent to install the OpenG Toolkit (assuming you want all the modules) package, then update the individual modules as they are updated? I feel safe in assuming that *since I've already installed all the individual packages that there is nothing for me to be bothered about, if I am correct in assuming that the "OpenG Toolkit" package is just a snapshot of a major release or when the appropriate person feels like updating the snapshot. Ryan R.

Ok, in my mind something is DEFINITELY broken here. The "Loading" count is up to 40166. It would seem to be in an infinite loop here. Time to kill LabVIEW. Update: After killing LabVIEW and re-opening my project and going back into the separate source dialog (thinking to try just a few rather than the whole shebang), I discovered that all but about a dozen were showing as marked. I was able to mark the remaining items in no time at all. Of course, I still have the issue of opening all the files and saving them to do the actual separation.