LabVIEW 2009 Features

[Michael Aivaliotis]

Watch this video to find out about the upcoming LV2009 Features:

https://admin.na3.acrobat.com/_a56821929/p67979404/

[ESST]

Thanks for posting! I'v been aiting to find out

Snippets, by reference, recursion ....... I need to have a Lie down, or maybe a cookie:)

[Abdullah R]

data reference is what i like!!

[jgcode]

I really like the sound of the integrated TDMS with DAQmx and the the probe window.

The new ICON editor looks brilliant too - just what was needed

Its a shame they didn't go into detail about LVOOP enhancements other than slide 26.

I wonder what they meant by "ability to easily deploy executables?"

Does this mean that .exe's are now built cleaner - no files contained outside of the exe for duplicate names?

Waiting for the download to complete - this is one of the first things I will try!

[Michael Aivaliotis]

"ability to easily deploy executables?"

Does this mean that .exe's are now built cleaner - no files contained outside of the exe for duplicate names?

Yes.

[jgcode]

Yes.

You little ripper!

Download is slow...

I can't wait... ...do you have time to provide any details of how it works

- Do the .LVLIB or LVOOP library's get complied into another type of binary file (e.g. compiled LVOOP) that can sit in an LLB/EXE?

- Can LLBs now sit inside of LLB/EXE?

- Or there is a underlying folder type structure in EXEs now?

I am excited!

Edited August 1, 2009 by jgcode

[jgcode]

From the LabVIEW 2009 Help Manual here it is...

The Application Builder no longer moves VIs with conflicting filenames outside of stand-alone applications, shared libraries, or Web services for build specifications you create in LabVIEW 2009. In LabVIEW 8.6 and earlier, the Application Builder saves VIs and library files in a flat list within the application and saves VIs with conflicting filenames outside the application in separate directories.

If you build a stand-alone application or shared library using LabVIEW 2009, the Application Builder stores source files within the application using a layout similar to the directory structure of the source files on disk. For example, the following table lists the relative paths for a top-level VI, foo.vi, which calls a.vi and b.vi. C:\..\Application.exe represents the path to the application.

Path to source files Path to files in application

C:\Source\foo.vi C:\..\Application.exe\foo.vi

C:\Source\xxx\a.vi C:\..\Application.exe\xxx\a.vi

C:\Source\yyy\b.vi C:\..\Application.exe\yyy\b.vi

To use the legacy file layout, place a checkmark in the Use LabVIEW 8.x file layout checkbox on the Advanced page of the Application Properties, Shared Library Properties, and Web Service Properties dialog boxes. LabVIEW enables this option by default for build specifications you load from previous LabVIEW versions.

[Abdullah R]

From the LabVIEW 2009 Help Manual here it is...

The Application Builder no longer moves VIs with conflicting filenames outside of stand-alone applications, shared libraries, or Web services for build specifications you create in LabVIEW 2009. In LabVIEW 8.6 and earlier, the Application Builder saves VIs and library files in a flat list within the application and saves VIs with conflicting filenames outside the application in separate directories.

If you build a stand-alone application or shared library using LabVIEW 2009, the Application Builder stores source files within the application using a layout similar to the directory structure of the source files on disk. For example, the following table lists the relative paths for a top-level VI, foo.vi, which calls a.vi and b.vi. C:\..\Application.exe represents the path to the application.

Path to source files Path to files in application

C:\Source\foo.vi C:\..\Application.exe\foo.vi

C:\Source\xxx\a.vi C:\..\Application.exe\xxx\a.vi

C:\Source\yyy\b.vi C:\..\Application.exe\yyy\b.vi

To use the legacy file layout, place a checkmark in the Use LabVIEW 8.x file layout checkbox on the Advanced page of the Application Properties, Shared Library Properties, and Web Service Properties dialog boxes. LabVIEW enables this option by default for build specifications you load from previous LabVIEW versions.

ohh so the size of application and performance is untouched. Well actually the size may now get even bigger because everything is in it.

[Ton Plomp]

Create .net interop assemblies!

I think this means we can actual create a .net code!

Ton

[Anders Björk]

Finally a matrixplot similar to matlab's subplot. This makes things eaiser

Alltså the other new 3D graphs, like 3d scatter or 2d histograms and the error bar plot is something that was needed.

[Val Brown]

From the LabVIEW 2009 Help Manual here it is...

The Application Builder no longer moves VIs with conflicting filenames outside of stand-alone applications, shared libraries, or Web services for build specifications you create in LabVIEW 2009. In LabVIEW 8.6 and earlier, the Application Builder saves VIs and library files in a flat list within the application and saves VIs with conflicting filenames outside the application in separate directories.

If you build a stand-alone application or shared library using LabVIEW 2009, the Application Builder stores source files within the application using a layout similar to the directory structure of the source files on disk. For example, the following table lists the relative paths for a top-level VI, foo.vi, which calls a.vi and b.vi. C:\..\Application.exe represents the path to the application.

Path to source files Path to files in application

C:\Source\foo.vi C:\..\Application.exe\foo.vi

C:\Source\xxx\a.vi C:\..\Application.exe\xxx\a.vi

C:\Source\yyy\b.vi C:\..\Application.exe\yyy\b.vi

To use the legacy file layout, place a checkmark in the Use LabVIEW 8.x file layout checkbox on the Advanced page of the Application Properties, Shared Library Properties, and Web Service Properties dialog boxes. LabVIEW enables this option by default for build specifications you load from previous LabVIEW versions.

OK, so I have a build spec for an EXE that builds without any problem in 8.6.1 but, in LV 2009, the build "completes" but then I get a "...not a resource..." error when trying to start the built EXE. I've tried both the legacy 8.6.1 "flat file" setup as well as the LV 2009. Nothing else has changed in the buildspec but, interestingly enough, while performing the build, LV asks me -- repeatedly -- to browse for several VIs, all from SPT.

Any good ideas?

[ShaunR]

I've just upgraded to LV2009 and........

Is it just me or does it make 8.6.1 look like a paraplegic sloth? It seems far quicker to load, a lot more responsive and debug execution seems brisk.

[jgcode]

I've just upgraded to LV2009 and........

Is it just me or does it make 8.6.1 look like a paraplegic sloth? It seems far quicker to load, a lot more responsive and debug execution seems brisk.

I wanted to post about how impressively fast I thought 2009 was compared to 8.6.1 but I didn't have all the module installed at the time and thought it might be due do that.

But yes, I have noticed that it is quick to start, even with all the palettes loading on startup, RCF, etc...

Edited August 11, 2009 by jgcode

[ShaunR]

I wanted to post about how impressively fast I thought 2009 was compared to 8.6.1 but I didn't have all the module installed at the time and thought it might be due do that.

But yes, I have noticed that it is quick to start, even with all the palettes loading on startup, RCF, etc...

I had a funny one today in LV 2009.

I had a sequence engine running and one other vi running (mainly keeping image references in memory so I could stop and start the engine). The sequence engine would only execute (by that I mean its state machine would only go from state to the next) if the diagram was in the foreground or I moved the mouse over menu items (in the main menu) if the front panel was in the foreground. How the hell do you debug that?

[shoneill]

On the negative side there's a group of people having a collective aneurysm about NI packing Mathscript into a seperate licence as from next year.

Shane.

[Cat]

On the negative side there's a group of people having a collective aneurysm about NI packing Mathscript into a seperate licence as from next year.

It is a bit concerning. I don't use Mathscript, but lots of people around here use MatLab, and it's always been nice to be able to say that LabVIEW comes with hooks into MatLab. I guess I'll now (or in a year) have to add, "for an additional cost."

But what is *really* concerning is that someone stated that old code using mathscript wouldn't work until you activate the new license. And when LV2010 comes out, old code won't work unless you shell out even more $$ to renew the Mathscript license. I couldn't find a denial of this in any of the NI responses. If this is true, it is a Bad Thing.

Cat

[shoneill]

It is a bit concerning. I don't use Mathscript, but lots of people around here use MatLab, and it's always been nice to be able to say that LabVIEW comes with hooks into MatLab. I guess I'll now (or in a year) have to add, "for an additional cost."

But what is *really* concerning is that someone stated that old code using mathscript wouldn't work until you activate the new license. And when LV2010 comes out, old code won't work unless you shell out even more $ to renew the Mathscript license. I couldn't find a denial of this in any of the NI responses. If this is true, it is a Bad Thing.

Cat

It's in the upgrade notes that old code will not run without a licence in future LV versions.

So unlike the Event structure which is unavailable for editing in lower LV versions but can at least be USED, the mathscript removal also disses any past work which has been done.

I don't like the way NI is going about this.

Shane.

[ShaunR]

It's in the upgrade notes that old code will not run without a licence in future LV versions.

So unlike the Event structure which is unavailable for editing in lower LV versions but can at least be USED, the mathscript removal also disses any past work which has been done.

I don't like the way NI is going about this.

Shane.

Pretty soon you'll have to buy a license for each pallet item the way they seem to be modularising and licensing. I'm already up to 23 activation codes for my developer suite. It grows by about 3 licenses every year and I've had the same suite for 4 years.

[nhollenback]

data reference is what i like!!

Me too! But I really want named DVRs. Maybe next release.

[Yair]

I really want named DVRs. Maybe next release.

I wouldn't count on it. NI already has enough named ref-based options to deduce that if they didn't add it to this feature, they did that (or should that be "they didn't do that"? ) deliberately.

The most obvious reason for such a decision is that it would make creating deadlocks too easy. Today, to create a deadlock using a single DVR, you need to bring it over the boundary of a structure where you're using it or pass it inside using a non-dataflow means of communication (local, global, etc.).

If you had named DVRs, you might be tempted to encapsulate the Obtain DVR code in specific VIs and then call them one inside another, ultimately leading to deadlocks without the ability to see where they came from.

[John Lokanis]

If you really want named DVRs, just store your DVR in a single element queue and then use preview queue to retrieve it. You could put together a very simple set of VIs to implement this. I used to do something similar with single element queues and variants.

Be sure not to destroy your DVR without freeing the queue or you might end up with Totally Invalid Value Objects, or TIVOs.

[nhollenback]

If you really want named DVRs, just store your DVR in a single element queue and then use preview queue to retrieve it. You could put together a very simple set of VIs to implement this. I used to do something similar with single element queues and variants.

Be sure not to destroy your DVR without freeing the queue or you might end up with Totally Invalid Value Objects, or TIVOs.

But if I'm going to put the DVR in the SEQ, then I will just bypass the DVR and just use the SEQ

And I am TIVOless and hope to remain so

[John Lokanis]

But if I'm going to put the DVR in the SEQ, then I will just bypass the DVR and just use the SEQ

Yes, you could certainly do this, but then you must store the queue data in a variant and cast it back to it's native type after accessing it. (assuming you want to build a set of generic helper VIs to do this and want to be able to pass 'any' datatype using these functions.)

I don't have LV2009 installed yet, but my understanding is the DVR reference is a single static datatype but it knows what it is storing. So, you would be replacing the variant in the queue with the DVR datatype and then when you need to access the data, you would use the inplace structure that could decode the data in the DVR into its native type without having to do a cast. It's a minor savings but let's you skip the typedef for the data you are passing as well as leading to cleaner diagrams.

Of course I could be wrong... Anyone want to test this? Does the DVR carry it's datatype on the wire or is it stored in the memory where it points to?

-John

ps. sorry about your lack of TIVOness. Honestly don't think I could live without a DVR anymore (the original kind, not the LV data type).

[Mark Yedinak]

ps. sorry about your lack of TIVOness. Honestly don't think I could live without a DVR anymore (the original kind, not the LV data type).

I agree with you. I would hate to be without my TiVo. NOw I just need to upgrade it to the HD XL unit.

[Yair]

Yes, you could certainly do this, but then you must store the queue data in a variant and cast it back to it's native type after accessing it.

Why? You just use the SEQ directly to store the data itself. DVRs don't offer anything you couldn't do with a SEQ. They do offer better guarantee of inplaceness and less chances of causing deadlocks, but the functionality is the same as you would get with a SEQ (except you can obtain a SEQ by name and preview its data, which you can't with a DVR).

As for your other question, DVRs are also typed, just like queues and notifiers.