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.

Well they say that admitting it is the first step towards healing. 

HA!

Well they say that admitting it is the first step towards healing. 

HA!

Well they say that admitting it is the first step towards healing. 

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.

My bad, I missed the part where you said 'project-based conversation dialog'.

 

Let me recollect something: The dialog that appears will in fact list all the LabVIEW items in your project:

Mark Project Items to Seperate Compiled Code.png

 

The enumeration process might take a while depending on the number of files in your project but there has never been a loading screen for me. Be aware that all files within the project (VIs, libraries, llbs, auto-populated VIs/libraries/llbs, etc...) will be enumerated (except for files under 'dependencies'). Have you ever reached that dialog at all? It's not clear for me.

 

If you never reached that dialog, it should be rather safe to kill LabVIEW (it's enumerating files) -> I assume your dialog does only say 'Loading:' and not 'Compiling:' as in your screenshot. It seems like LabVIEW is trying to load everything (the entire LabVIEW directory?) into memory (..LabVIEW 2012resourceFramework* is part of the LabVIEW core!). So you could abort that operation and try on an empty project file. If you have the same behaviour again, it would be a good time to contact NI.

...

LogMAN,

The dialog you pictured is right behind what I took a screenshot of. My loading screen as pictured ccame up immediately after I clicked on "Mark selected items" (after selecting them all in the list).

There are quite a few items loaded and I'm not sure how the sources will react if you kill LabVIEW (some of them might have their compiled code removed while others dont). It wouldn't be a big issue if you had your code in SVN or something where you could just revert the working copy... (I recommand to create a backup before doing such stuff anyways)

However if you have a single project file and want to remove compiled code from VIs within the project you can do that from the project properties dialog (Seperate compiled code from new project items & Mark existing items) I recommand to use that function as it is shipped with LabVIEW (at least since 2011 afaik) I used it on my recent project with 1000+ VIs and it took just a couple of minutes.

 

Just read the thread you linked: Seems that LabVIEW 2010 had some issues with the removing of compiled code. As you are using LabVIEW 2012 that should be no issue, so why using that VI instead of the build-in function anyways?

Actually, I AM using the built-in functionality exactly as you indicated. The fact that you did 1000+ VIs in so short a time does not bode well for me. I left it running over the weekend, I really hope it's all resolved by the time I get back to work tomorrow.

I'm working on doing the same thing with a project that sounds similar to yours. The thing I'm worried about is having all of the typedefs in memory along with all of their callers - many of which are ACBR. Over the next couple of days I'm hoping to get a little script together that creates a tree.vi to keep everything loaded.

Yes, I have the same concern. A tree VI sounds good at least to help make sure things get updated when the Typedefs change, but of course that means maintaining the tree as the project is modified. What about auto-populating folders in the project tree? Do those make everything get loaded into memory?

That's what LAVA is for.

When I thought about removing the compiled code from the VIs of all our Instrument driver(about 200 lvclasses), which the whole company is using, I was very worried, does this new feature work 100%?!?

So to become more confident I contacted AQ, who referred me to a compiled code specialist at NI that gave me the confident of going ahead.

I would like to report this to NI, but first I need to know how to reproduce it, because it happens very seldom, but when it happens everything comes crashing down.

I first noticed it, when I needed to build a new version of my executable, the executable didn't work.

And when I dug in to the driver layers I found one class where all commands to the instrument was reset to the first element.

CLS.png

You guys are scaring me away from this feature. Between anecdotal evidence like this and the mark project items to separate... process I just stopped after the 5th hour of processing, I'm feeling pretty nervous. I might still give it a try with Shaun's conversion VI posted at http://lavag.org/topic/12886-experience-with-separate-compiled-code-from-source-lv-2010/?p=77020, but now I seem to be stuck in this operation for good and I'm terrified to kill LabVIEW forcibly. With a project folder containing rougly 850+ vis, lvlibs, and ctls, the project-based conversion dialog says it's at 6736 loaded and counting. I would love to know what is going on here. I assume this is enumerating the files, removing the compiled code, and saving them?

Thanks again, Ryan. This is exactly what I decided on and just finished testing. I set a 10 second timeout and use an error case for the code after.

I've got a stream reader endpoint, and I'm trying to avoid waiting for a timeout from the reader endpoint creation. Do you have to wait until the writer end is created before you can create the reader end? The LabVIEW help says that both are needed, obviously, but doesn't explicitly state precedence or a requirement that they be created at the same time.

Never mind. I see from reading http://www.ni.com/white-paper/12267/en that "The endpoint that is created first will wait until the other endpoint has been created and is ready to connect, at which point both create functions will exit. The stream is then ready to transfer data.  Used in this manner, the create function effectively acts as a network rendezvous where neither create function will progress until both sides of the stream are ready or until the create call times out."

This raises a different question, now. If these endpoint attempts are preventing my program from exiting, is it possible to force them to stop before their timeout? Perhaps I'll just put them in loops with short timeouts and made the loops aware of my exit conditions.

Ryan R.

Thanks, J. I'm on 2012, so that VI wasn't on my palette, but it got me looking in the right place so I found the equivalent. I got it working basically as I need to using a VI to place the IP address in a shared variable and work from there. I still will have to figure out how to set up a launcher VI that can run this vi that executes on the PC and also the RT Main that must run on the cRIO. Since they are in different application instances (if that's the right terminology) I can't just have them both be subVIs of the launcher.

Ryan R.

Check out the System Configuration pallet to locate remote systems. From there building a simple interface shouldn't be hard.

That doesn't solve your problem with the IP address in the project though.

Thanks, Ryan. I'm not overly worried about the project just yet, though I will eventually have to deal with that somehow.

I'm working with a contractor on a cRIO-based test system, and we are arranging a shared version control scheme so I can work on the code as well. One issue is that there are 2 different cRIO systems operating in completely different network environments, and there are currently 3 different locations where we have to change the IP address between environments:

1. RT controller properties in project

2. A front-panel control on a UI vi that connects to the RT controller

3. A constant in an RT Main vi to set the target for the FPGA BitFile

I'd prefer to make this more portable and more easily maintainable in this shared satting under VCS, ideally just popping up a panel that offers controllers to connect to so the operator just clicks on a system to connect to. Desired features would be:

1. Dynamically identifies connected cRIO controllers

2. Offers choice of controller to connect with

3. Remembers last choice with ini file and automatically connects if there is only 1 possible target

Thank you for any help.

Ryan Rutledge