jgcode

Yes, that's Norm showing off LVSpeak.

[cross posted to ni]

Is the sequence structure package shown in the video available to download anywhere?

I would love to use that for a current project.

Currently OpenG Package Builder only supports the <temp> folder outside the LabVIEW folder.

And it is the Temp folder as specified by LabVIEW.

The OSData dir is not supported nor is the LabVIEW Data dir.

Adding such a feature would also mean VIPM needs to suppport it, and for such a thing you should deal with JKI et al.

Ton

Thanks for the info Ton, I have inquired at JKI.

Hi Sydney

You could try using the above FP Method to print only the visible front panel objects.

You should have the same or similar node in 8.5.

You may also like to check out the Report Generation Toolkit (RGT) if you have it.

I also like to make the dummy VI as Ton suggested.

Cheers

JG

Great idea! I don't have any tested solutions to the problem--here are a couple ideas for workarounds:

• Typing the symbolic path directly into the Group Target Directory path box rather than using the drop down box. (I doubt this will work but it's the first thing I would try.)
• I believe the default <temp> directory in Vista is a subdirectory of <osdatadir>. Entering a relative path from there might work as long as your users use Vista and don't change the defaults.
• Have the package deploy them to <temp>\Icon Templates\[my folder structure etc...] and write a post install script that moves them to <osdatadir>\Icon Templates\[my folder structure etc...]. You'd also need a preuninstall script to move them back. This should be pretty straight forward.
• Since the package installation is handled by VIPM it might be possible to edit the package spec file manually to install the files to <osdatadir>.

Thanks for posting.

I tried editting the SPEC file but that failed.

Typing in the symbolic path fails - it must do a check - it just changed it automatically to something else.

I have not looked at the post install scripts (I actually didn't know they are there - only the post package build scripts - e.g. hooks build into VIPM).

I can easily get the default directory from a LabVIEW primitive.

But it will be annoying as I would prefer VIPM to handle the installing/uninstalling of files.

<edit>

Just tried the following: The <temp> is not always a subset of default data in VISTA. E.g. my <temp> is C:\Users\ME\AppData\Local\Temp by my <osdatadir> is D:\ME\Documents\LabVIEW Data. This is because I changed mine so that my data is not tied up in the OS volume. Bugger!

</edit>

Just to report that I am running LabVIEW 2009 on 32-bit Windows 7 Ultimate and initially at least it seems to be also working. I haven't tried most of the feature though

We should be able to get Windows 7 RTM through our MSDN subscription soon (if not now) - I would like to look at upgrading so that's good to hear.

Damn work PCs Intel chips don't support virtualisation, will have to push the boss for an upgrade

It seems to me you are keeping all the data the states will work on in this shift register. This is in most cases not a very good idea as it ties the entire state machine implementation very strongly to the data of all states, even though most states will only work on some specific data on this. There is also a possible performance problem if your state data cluster gets more and more huge over time.

If a design is used for a SM with state information stored in cluster - but with the cluster being made up solely of (e.g. LVOOP) objects (so the cluster is only used as a container to pass the objects through the states to avoid multiple SR) - would that still be considered bad design?

Note: I ask out of an effort to seek information, not to debate any previous comments.

At the (fantastically awesome) LAVA/OpenG BBQ, someone (apologies to whoever it was, I forget who - sometimes I think I'm the Dory character from Finding Nemo) asked about getting more recent projects in the GSW. Stephen Mercer / Aristos Queue had provided modified versions of the VIs to do this in 8.6.

I added a config token for this in LV2009, so you no longer need the modified VIs. It's MaxGSWRecentProjects=10 (or whatever other number you want. We never display more than 10 recent files, though).

- Christina, aka "Miss Eyes on VIs," LabVIEW R&D

Thanks Christina, I added this to the wiki

so I put a VI Snippet.

Just out of interest - the VI snippet does not include the Tagged Test VI.vi - which is the VI being statically referenced.

Do people think it should or would be a good idea if it did?

As far as I know (and please correct me if I am wrong - I just remember someone else posting it) the OpenG forums are quite inactive so I thought I would post here

Hi!

I currently host my icons templates in the palette, this way I can quickly drag and drop them onto the FP then into the icon.

This was a pretty fast way to do it for me.

Now with 2009 I want to create a package that can install these to <osdatadir>\Icon Templates\[my folder structure etc...]

However, it seems that OGPB does not support this symbolic path?

So my question are:

1. Does OGPB support the <osdatadir> symbolic path?
   
2. Is there a better way to do this?

Cheers

JG

Half-Life played with real guns, and using LabVIEW, what more could you want:-

http://www.reghardware.co.uk/2009/08/07/halflife_played_with_guns/

Cool post.

I loved the bit where they jumped in and were hitting the screen with shovels.

Any easy way to add dynamic VI into a VI that is calling it is placing the VI inside a Static VI Reference Node:

.

This might be what you're after.

Ton

This is the way I normally do it.

Thought I would mention that Sciware likes to do it this way with the advantage being you will know straight away if the dynamic VI is broken - this way makes a lot of sense.

Jgcode,

thanks for the info!

This is very usefull. Could you share this code via OpenG or Lava CR?

Ton

No worries - it was a bit late, but I posted in case it helped.

I can't post the VIs but can you PM me your email and I will get them to you.

I also have been working on a build script that you might find useful (as I am guessing that is what you are doing?).

Its all in LV 8.6 - let me know what version you are using as well and I will try to convert down if needed.

Cheers

JG

Thanks! Maybe its the firewall that messup my installation.

At work we had "dirty" installs from the first 8.6 (or 8.6.1 - can't remember) dev suite installer discs. It seems Kaspersky on VISTA was to blame, along with some super long file paths that results when we stored the discs on our server.

Also, I have to turn Kapsersky off just to build an installer.

One of my clients calls it "Pipework" I keep telling him, wrong trade, they are wires.

Ha! Maybe he thinks it should looks something like this?

drag-&-drop programming

Is that what they are calling it now?

May I ask if you use English language package and what antivirus and/or firewall you use?

Certainly my good man!

English, with Norton 360v2 (hey its not that bad )

Hello Anders

I am running 8.6.1 and 2009 at Home on Vista Ultimate 32bit.

I am not running the others you mentioned.

The reason being, as far as I am aware 8.2 is not compatible with Vista.

8.2.1 was the compatiabilty changeover.

Cheers

In LV 2009...

If you want to add customizations to the new VIs that are created by New>>VI For Override and New>>VI For Data Member Access, you can open and edit these three VIs. These VIs are called at the end of their respective scripting processes and you are free to include any scripting code you wish to further customize the VI in question. Some common customizations you might want include changing the VI name (use "get" and "set" instead of "read" and "write"), modifying the icon, adding additional diagram logic, etc. You cannot edit the callers of these three VIs, but these three provide the hook you need to customize your new VIs as you want them.

Customizations for Override VIs:

<labview>\resource\Framework\Providers\LVClassLibrary\NewAccessors\OverrideRetooler\Custom User Scripting For New Override VI.vi

Customizations for basic accessor VIs:

<labview>:\resource\Framework\Providers\LVClassLibrary\NewAccessors\BaseAccessorScripter\Custom User Scripting For New Simple Accessor VI.vi

Customizations for 1D Array element accessor VIs:

<labview>resource\Framework\Providers\LVClassLibrary\NewAccessors\ArrayElementScripter\Custom User Scripting For New Array Element Accessor VI.vi

Customizations for multi-dim array element accessor VIs:

<labview>\resource\Framework\Providers\LVClassLibrary\NewAccessors\MultiDimArrElemScripter\Custom User Scripting For New MultiDim Array Element Accessor VI.vi

This is for the various LAVA folks who asked these scripting hooks be added.

I have been wanting to do this for ages - so I just wrote a RCF plugin that does this.

But this is great this has been opened up to the public.

Awesome!

Any word on when these will appear?

Yep Shaun is correct NI Rio 3.2.1 (Aug 09) is up on the ftp. We have just downloaded and are installed now.

Cheers

You can consider the 64 vs 32 bit application similar to building an app on Windows that will run on Mac. Essentially we would need to have the ability to cross compile VIs for a different OS (in this case bitness being the difference). I am not aware if there are plans to support building for the different OS's.

Thanks!

Thought as much.

I wanted to know, so I can plan ahead for the future

Cheers

JG

I am starting to use inheritance and am facing the following problem:

I would like to inherit from 2 classes.

Ton

Hi Ton

I am fairly new to OOP but would still like to suggest the following from my current experiences:

Using the verification statement for inheritance can help:

Ask yourself, or jot down on paper, if the subclass (e.g USB) IS A more specific type of the superclass (e.g. GPS)

USB is a GPS (makes sense from a DAQ-type POV)

Serial is a GPS (makes sense from a DAQ-type POV)

TDMS is a GPS (does not makes sense)

CVS is a GPS (does not makes sense)

Therefore TDMS and CVS should not inherit from GPS. You may want to create another superclass that these two classes inherit from - e.g. a Log Interface - and this class could be have a association with GPS (either through aggregation or composition relationship etc...).

I have been told (in other posts) that design pattern knowledge is the way to go to improve class hierarchy design - this is something I am trying to achieve at the moment.

I have had similar issues as you along the way learning this (as I am sure others have too). Its all part of the fun IMO

(Endevo) Mike H mad a recently great post regarding Interfaces in LabVIEW - it is work checking out. And of course AQ's Design Patterns Document on ni.com.

Thanks

You're Welcome!

Oh,Yeah, Nice, but Why it is an error as I run the vi ?

Guessing - is the VI you're pointing to idle?

No. 64-bit LabVIEW will only build 64-bit apps. 32-bit LabVIEW will only build 32-bit apps.

Hi Gmart

Will this ever change in the future (64bit being able to produce a 32bit build) or is it forced by the nature of the OS.

Cheers

JG