40 replies to this topic

[Michael Aivaliotis]

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

https://admin.na3.ac...1929/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 by jgcode, 01 August 2009 - 03:05 AM.

[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 by jgcode, 11 August 2009 - 11:39 PM.

[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.