Is this the most useful Express VI ever?

[Daklu]

As rule I tend to avoid express VIs, but I happened to click on a link in Christian's signature and found this. I haven't looked at it in detail, but this may be the one express vi I'm willing to use.

[John Lokanis]

Cool. I wrote a VI years ago that does that same basic operation and I use it everywhere. I wonder how many other wheels we all have reinvented...

[Yair]

I think that express VIs got a partly unjustified bad reputation. I find that they're actually quite an impressive technology which makes a lot of sense for many things (e.g. I'm sure most people here used the DAQ assistant to configure their DAQmx measurements, either in LabVIEW or in MAX). Of course, they do have their disadvantages, the chief IMO being that if you have something which needs to use an initializable resource they perform the init-destroy sequence each time.

As an aside, I also think the reference libraries NI releases are a good thing and have a lot of potential in standardizing some things. This one specifically looks like one I might actually use.

[Daklu]

I find that they're actually quite an impressive technology

I agree. My main issue with them is typically they don't do quite what I want or don't give me quite the control I'm looking for.

the chief IMO being that if you have something which needs to use an initializable resource they perform the init-destroy sequence each time.

Can you explain this a bit? Is the init-destroy sequence executed each time during runtime or each time you drop an express vi on a block diagram?

[Gary Rubin]

I agree. My main issue with them is typically they don't do quite what I want or don't give me quite the control I'm looking for.

I find that they often do too much. The few times I've used them, I've immediately converted them into a subvi, then stripped out all the cases and conditions that I didn't want/need. I guess I use them as templates/examples.

[jgcode]

They have there place in LabVIEW I guess.

For the stuff I do I rarely use them.

Except for the File Dialog Express VI, I always use that.

[ryank]

I agree. My main issue with them is typically they don't do quite what I want or don't give me quite the control I'm looking for.

Can you explain this a bit? Is the init-destroy sequence executed each time during runtime or each time you drop an express vi on a block diagram?

About Express VIs in general:

There is nothing inherent in Express VIs that requires them to do an init/destroy sequence. However, Express VIs that work with open resources (i.e. the assistants) do have to have some way to open and close those resources, since there aren't explicit open and close operations as you'd get when using a lower level API. Therefore, it all depends on the Express VI, which is a good mantra to remember when thinking about Express VIs. At run time they're really not much different from a subVI, most of the gripes people have with them have to do with the way that certain Express VIs are implemented, not with the technology itself.

About the Specific Error Handler:

The nice thing about having one as a reference library is that its open source. If you don't like what it does, then change it . Or better yet, post me a comment in the attached discussion forum so that I can make it what people want it to be .

The Specific Error Handler does not need any initialization or cleanup. Most of the processing of the error configuration is done when you hit OK from the configuration dialog, not at run time. At run time, it stores a fairly simple list of errrors and actions, the only performance hiccup will be that it does have to do a search in the event of an error. At the moment, I haven't done a whole lot to optimize the search, since I don't expect individual instances of the VI to have more than a dozen or so errors handled, but if anyone starts using larger lists in and individual instance, I'd be interested to know about it and I can consider doing some more optimization.

Regards,

Ryan K.

NI Systems Engineer

[Yair]

Because Express VIs are a one-VI-operation, that VI needs to do everything related to its task. If that task involves writing and reading to a serial port, for instance, the VI would need to open the port and close it every single time it runs. Call it in a loop many times and this can become a performance issue.

As Ryan said, this isn't something inherent to the technology, but it's what usually happens, and for good reasons.

Like Gary, at times I've simply converted the VIs after their creation and removed the parts I didn't want. This is done by right clicking and selecting Open Front Panel.

Also, I feel that part of the issue that people have with them is that many of the ones NI ships are geared towards mewbies and not towards experienced users. This results in you using an express VI and feeling your code to be "not code", since it looks too much like the NI demos where you string two blocks together and that's the end of the demo.

By the way, NI used to have an express VI development toolkit, but it seems that this now ships as standard (at least with the Dev Suite I have). It's found somewhere in the Tools menu. It's something which could be useful if you want to script (or even just configure) some code using a wizard.

[jcarmody]

They have there place in LabVIEW I guess.

For the stuff I do I rarely use them.

Except for the File Dialog Express VI, I always use that.

They have their place, sure.

For stuff I do, I don't need.

'cept file dialog

[ryank]

Because Express VIs are a one-VI-operation, that VI needs to do everything related to its task. If that task involves writing and reading to a serial port, for instance, the VI would need to open the port and close it every single time it runs. Call it in a loop many times and this can become a performance issue.

As Ryan said, this isn't something inherent to the technology, but it's what usually happens, and for good reasons.

Like Gary, at times I've simply converted the VIs after their creation and removed the parts I didn't want. This is done by right clicking and selecting Open Front Panel.

Also, I feel that part of the issue that people have with them is that many of the ones NI ships are geared towards mewbies and not towards experienced users. This results in you using an express VI and feeling your code to be "not code", since it looks too much like the NI demos where you string two blocks together and that's the end of the demo.

By the way, NI used to have an express VI development toolkit, but it seems that this now ships as standard (at least with the Dev Suite I have). It's found somewhere in the Tools menu. It's something which could be useful if you want to script (or even just configure) some code using a wizard.

There are some tricks they use to get around having to re-open resources every time (basically they use VI scripting to analyze whether the VI is being called in a loop), but they're very tricky and still have performance implications.

You are correct that the Express VI Development Toolkit is now part of LV Core. I haven't checked, since I always install professional, but the original spec suggested that it might be in Base or Full as well, you definitely don't need Dev Suite. I believe the transition occured at 8.6, although it's possible it was 8.6.1.

[ShaunR]

Or better yet, post me a comment in the attached discussion forum so that I can make it what people want it to be .

Don't know where the "attached discussion forum" is, but I've thought for years that "Elapsed Time" should be in ms resolution. It would have been useful then .

Edited August 20, 2009 by ShaunR

[ryank]

Don't know where the "attached discussion forum" is, but I've thought for years that "Elapsed Time" should be in ms resolution. It would have been useful then .

Hehe, just to clarify, I'm not in R&D (not that there's anything wrong with being in R&D ) and I didn't write and don't maintain any of the core LabVIEW Express VIs. I'm referring specifically to the Express VIs linked above, which I did write. The forum I was referring to is linked from the document that contains the example. I won't post a direct link, because I know some forums frown on that.

And for the record, I think the elapsed time VI accepts fractional numbers, so you can do ms resolution waits with it, you just have to divide by 1000 yourself .

[Yair]

There are some tricks they use to get around having to re-open resources every time

But what do they do about closing them? Do they just rely on the automatic cleanup?

One method I've used once (although I'm fairly sure I only used it in this example*) is to run my actual code in an asynchronous process (e.g. it would open the resource the first time and return it on request on subsequent runs) and monitor the execution state of the owning VI and clean up when the VI stopped. This worked for my example because it was working on a specific control, which was owned by a VI. It might work for an express VI, but it would require something like reference counting and garbage collection and probably wouldn't be worth it. For code which needs it, it's easier to just write the actual code with open and close outside the loop.

* It's actually a cute example - it allows setting a custom blink color and speed for each control. I thought of augmenting it by adding the ability to smoothly pulse the control's color, since I have the code for that as well, but since I never used either of them in any actual code, I didn't bother. Today that might be better implemented in an XControl.

[ryank]

But what do they do about closing them? Do they just rely on the automatic cleanup?

One method I've used once (although I'm fairly sure I only used it in this example*) is to run my actual code in an asynchronous process (e.g. it would open the resource the first time and return it on request on subsequent runs) and monitor the execution state of the owning VI and clean up when the VI stopped. This worked for my example because it was working on a specific control, which was owned by a VI. It might work for an express VI, but it would require something like reference counting and garbage collection and probably wouldn't be worth it. For code which needs it, it's easier to just write the actual code with open and close outside the loop.

* It's actually a cute example - it allows setting a custom blink color and speed for each control. I thought of augmenting it by adding the ability to smoothly pulse the control's color, since I have the code for that as well, but since I never used either of them in any actual code, I didn't bother. Today that might be better implemented in an XControl.

I'm not sure of the exact mechanism, since I've never tried doing it using VI Scripting. In most cases when I write an Express VI, it's to create a reusable block of code that I can easily reconfigure, like this one, and not necessarily to make a hard concept easy to understand (which is what most of the built in ones are designed to do). Therefore, for my Express VIs, I'm okay with making the user call an init and a close if I'm managing resources (under the hood the init and close just operate on a functional global, and I can use a reference into the FGV to handle multiple sessions).

For the SEH library, I did experiement for a while with allowing the user to call handler VIs for each error, either asynchronously or synchronously, but I took it out of the posted version because I was worried about the implications and because I intend to use this in RT systems, where arbitrarily spawning VIs to handle an error would be kind of a no-no .

That is a nice example, although I agree that it would make a good XControl.

[Vekthoar]

Has Anyone considered or tried to use an express VI as a class constructor?

I don't really like to have too much constants on the block diagram, this looks like a good way to hide the inputs, and with the custom context help it can be still readable.