jgcode

Scripting for lv2009 was just released.

http://decibel.ni.com/content/docs/DOC-4973#cf

Sweet!

"Code Coverage" is a a relative term

Great job Crelf

Does anyone know where the version of DAQmx that supports LabVIEW 2009 can be downloaded from?

Hi Shaun

DAQmx for 2009 is now available for download from ni.com drivers and update page

Similiar options as before, but with cooler names

DAQmx 9.0

http://joule.ni.com/nidu/cds/view/p/lang/en/id/1278

DAQmx 9.0 Run Time Engine

http://joule.ni.com/nidu/cds/view/p/id/1388/lang/en

DAQmx 9.0 Run Time Engine Core

http://joule.ni.com/nidu/cds/view/p/lang/en/id/1368

In this post I mentioned that some 2009 Modules and Toolkits were available for download.

However, you can find LabVIEW 2009 and all Addon Modules and Toolkits here:

http://www.ni.com/labview/family/

You can download for 30-days evaluation or activate if covered under you SSP (or whatever license).

More specific links include:

NI LabVIEW Modules and Toolkits for Control Design and Simulation

https://lumen.ni.com/nicif/us/evaltlktcds/content.xhtml

NI LabVIEW Modules and Toolkits for Embedded Design

https://lumen.ni.com/nicif/us/evaltlktembdes/content.xhtml

NI LabVIEW Modules and Toolkits for Image and Signal Processing

https://lumen.ni.com/nicif/us/evaltlktsigproc/content.xhtml

NI LabVIEW Modules and Toolkits for Industrial Measurement and Control

https://lumen.ni.com/nicif/us/evaltlktindctrl/content.xhtml

NI LabVIEW Modules and Toolkits for Report Generation and Data Storage

https://lumen.ni.com/nicif/us/evaltlktrepgen/content.xhtml

Anyone know if Real-Time or FPGA can be downloaded yet?

Ok its seems to be up... go for it

https://lumen.ni.com/nicif/us/evaltlktcds/content.xhtml

I tried to point the LV8.6 installer to LV2009 folder during the install - but no luck

Now that LV2009 can be activated is there any talk on a LV2009 license release for scripting?

I was thinking the API may have been an feature of 2009.

Cannot find anything searching online and LV Help.

Cheers

JG

Mine just when though too.

It took a bit of toing and froing with the Activation Server though but it finally went though.

Only had to reboot LV2009 not my PC tho.

Anyone know if Real-Time or FPGA can be downloaded yet?

I have been searching for it on NI's support downloads page - but no luck at the mo.

LabVIEW Embedded Module for BlackFin Processors 2009 - Windows Vista x86/XP is out tho, so it maybe real soon.

That's a good point. You don't *need* to know LVOOP to use these new features, but if you've been waiting to get into the LVOOP world, now's a great time to dip your toes in the water...

I recommend everyone getting into it - as now I don't think I would want to code an app without it.

It was (and still is) a lot of fun to learn and program with.

The only issue I have is that my dev environment crashes alot (and I mean alot) when using it and I hoping this may have been fixed in 2009 (or occur less frequently).

In order to learn it I thought the best way was just to dive in head first do all the examples, read all the white papers, watch all the on demand videos and just start using it!

Around last year, I thought to myself that LVOOP was the way that NI had chosen to go with its OOP implementation so I decided I wanted to get into it and use it seriously for client apps.

At the time I was confident that LV8.5.1 was a very stable release for LVOOP - I had heard of some issues with its initial release around LV8.2.

We then moved up to LV8.6.1 internally and LVOOP had more features and improvements - which made it even better.

Its great to see once again that LVOOP has evolved a lot in 2009, and that it is starting to get used all over the place within LabVIEW.

So I am very confident that NI will continue to support it and will keep improving its implementation.

Along with all the new property additions to the .lvclass file - this addition of a native ByRef scheme (for any datatype in LabVIEW) looks awesome.

Plus NI have fixed up the conflicting file names get moved outside executable problem which usually comes up from using .lvclass files, (rather then .lvlib for me).

Therefore, from my point of view, I couldn't have asked for more in a release, from what I have seen: 2009 is a great release for me, as it covers my biggest issues/concerns/problems/gripes that I was facing as a LabVIEW developer using LVOOP on PC targets.

LVOOP moving to RT sounds sweet too.

Also wrt ByRef LVOOP - I can't wait to see the examples the community comes up with.

Cheers Kudos to NI, (and of course AQ) for their brilliant work

Cheers for the summary!

Yes, a data value reference (DVR) to an LVOOP object supports lots of great features, such as:

• use In Place Element Structure to get and operate on data, in place
• works with To More Specific Class and To More Generic Class
• DVR of Parent will coerce to DVR of Child
• LVClass can be configured to only allow DRV creation of its object from within a member of the class

At JKI, we've been playing with this for a while and have worked out some cool design patterns that we're looking forward to sharing and discussing with the community, very soon (just need to fit this around NIWeek).

Thanks Jim.

I missed out on the Beta Testing and this is all new to me.

And it's very exciting stuff thats for sure.

I have just been checking out Christian's Stuff (from this post), which looks awesome and is a great read.

AQ was correct in saying that LVOOP is used a lot in 2009 - even the new plot controls are LVOOP.

As you must know there seem to be alot of LVOOP additions - stuff thats I have seen been mentioned on LAVA is in there too (Friend Classes).

Since you have been using the DVR LVOOP objects for a while are you able to comment about what you have found on their implementation compared to ByRef GOOP toolkits (e.g. Sciware, Endevo, DqGOOP, OpenG etc..)?

Cheers!

Only been playing with 2009 for a few minutes or so...

Is this the by ref implementation of LVOOP?

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.

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!

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!

Awesome! Cheers for the links.. downloading now...

Unfortunately, we don't have anything to show yet because mostly we have design patterns that still need to evolve a little before they can become 'tools'. Generally, what we have done is utilized Windows API calls for keyboard and mouse emulation and used control references to validate the properties of UIs that we care about.

Very cool!

Thanks for replying

Your problem won't go away since you'll still need to run this tool everytime you want to save: which is longer? Changing the name or selecting from tools' menu? Anyway, it's fun to script . Give it a shot!

* You bloody little ripper (aussie slang for thank you) *

And the answer is.... "cut and paste your code!"

I cannot even see scripting methods!?!

I cut and pasted it into my new tool which is for a Right Click Framework package.

And it was perfect - exactly what I was after.

And yes scripting is fun and (very) addictive!! Thanks for posting Kurt & François.

Hey Mate

LabVIEW executes callback vi's on certain events, take a look at this article on OpenG.org

You could possibly edit the lv_new_vi.vi that is called when you select New VI so your new vi isn't called Untitled X.vi

I haven't played with this but sounds like the way to go.

Cheers Kurt!

I will take a look - at the moment though it will be for instantiated LVOOP methods - from the existing options create: dynamic, static, data member etc...

Hi

Does anyone know how to change the default save name of a VI.

E.g. you open a new VI, click Save, and the default name that appears in the file dialog is usually Untitled X (or Read/Write Data Member for a class).

I don't want to save the VI to disk, I just want to change the default save name so I don't have to edit it as much.

I tried writing to the VI Name property and changing the appearance name but it did not work.

I can't find anything on this searching.

Does anyone one know how to? A private property (scripting) would be fine too.

Cheers

JG

In that case, here's another iteration.

Awesome plugin - well done

Non-premium members can only edit their posts for a limited amount of time.

Cheers!

Sorry for doubleposting, but where is the edit button?

[edit]THIS post has edit button, previous one had not (even when it was the last one) [/edit]

Mines gone now too!

???

Sorry for doubleposting, but where is the edit button?

I'm not too convienced that it looks too much like BD and why it should not, but ok - what about this? (background color is same as current one)

Dude that is awesome - the mirror effect rocks!

I love the new-look Volcano.

Whoever designed it - Well Done!

(From reading the first post was it you, Vugie?)

[Edit button is near reply button over here]

Are you sure about that? I'm sure I've read that putting input controls inside a case statement prevents LV from making certain compiler optimizations. I can't find the reference at the moment though.

Here is a great piece of knowledge base from Adam Kemp. Twas posted on Info LabVIEW earlier this year.

It maybe the reference you are thinking of? The PowerPoint is a good read.

Subject: RE: Overhead of Sub-Vi-calls - was: Code condensing?

From: "Adam Kemp" <Adam.Kemp@ni.com>

Date: Wed, 6 May 2009 11:08:12 -0500

One way to make subVIs very expensive is to write them in such a way that

their inputs or outputs get copied unnecessarily. This is especially bad

if your inputs are arrays. Here are some tips to avoid copies and

otherwise improve performance of subVIs:

1. Make sure all indicators are on the outermost level of the diagram (not

in case structures or other structures). Putting them inside another

structure requires extra code to do things like set them to their default

value if that case is never executed.

2. Put controls and indicators on the connector pane. If it's not an input

and it's not a constant then we have to go to the UI to get/set the value,

which may mean a thread switch and always leads to at least one copy.

3. Mark inputs as required. This eliminates code to check whether they're

wired and use default data if they're not. Unwired inputs have to make a

copy on every run because they can never overwrite the default value. It

also avoids bugs when you forget to wire them (this has saved me many

times, and cost me lots of time when I forgot to do it).

4. Use shift registers for loop tunnels (especially For Loops, which

require special code on output tunnels in case the loop diagram never

executed and you need a default value). Even if you don't modify the value

it can still help prevent copies because left/right shift register

terminals are always "in place" to each other (meaning they must use the

same memory).

You can use the "Show Buffer Allocations" tool (Tools->Profile->Show

Buffer Allocations...) to see where copies are being made. They're shown

as little black dots (hitting the Refresh button makes them flash so

they're easier to see; yes, this could use some improvement). If you

modify your VI be sure to compile it (either run or ctrl+click the run

arrow) and then click Refresh to get an updated view of the dots/copies.

You can also use the Inplace Element Structure (introduced in 8.5) in some

cases to ensure that a value isn't copied. For instance, if you pull a

value out of a cluster, modify, and then put it back in the same cluster,

then you can avoid copying the cluster using the Inplace Element

Structure. Likewise, you can avoid copying an array element if you fetch

an element, modify it, and put it back in the same place.

There's a presentation online (just slides) that covers some of this with

some screenshots. You can view it here:

http://ftp.ni.com/pub/events/labview_dev_ed/2008/improving_performance.pdf

--

Adam Kemp

adam.kemp@ni.com

(512) 683-6058

When the VI executes as a subVI, LabVIEW has to put some value on the output indicators. regardless if the indicator is inside or outside the loop, the default values are used anyway right? So I think you have more control of the values if they are outside the loop, then you can place constants to define your outputs in the unused cases.

I agree. But as Crelf pointed out - if its a GUI then of course you are going to have FP objects inside the case structure.

But its not then, yes, I too prefer to have them outside for a couple of reasons:

I can define optional default values - or just select "use default if unwired". This is important e.g. on a basic SubVI with Errors I can pass the reference through the "in error" case, and not lose it (just like the LVOOP templates)

It is much neater and easier to read (for me) - I can see what goes in (LHS) and what goes out (RHS) as nothing is hiding anywhere.

Leads to optimised code (as per Adam Kemp's post)

It helps me maintain a standard interface to the code module. If I am not building a class, but a standard Multi-Functional VI (MFVI) I usually have 1 input and 1 output - normally type-def cluster (sometimes variants) to the module for data (and also the Command Enum and error in/error our clusters). This makes the interface flexible, maintainable and scalable. And I don't need to handle a bunch of default values. Wrapper VIs bundle the inputs into the interface and they also pull out the required outputs from the interface for that method call into the connector pane. So the API is just like a basic SubVI to use. Any used values are disregarded.