jgcode

What are people doing with Friends Classes?

How do they fit into the LVOOP paradigm?

Just keeping this thread alive.

Please do!

Hey Kurt

I missed your posts on this thread so I have just downloaded your code. The code you posted is quite cool. And very similar to a current project I am working on - I have/had to model a furnace for a client and decided to go with an Active Object - the client runs from source (don't get me started) in LV8.2 so I couldn't use any licensed toolkits when hacking his system. But I basically used your Active Object from Endevo as the template with a LVOOP-SEQ framework and it is working really well. It seems that the DVR would slightly simplify this process.

I implemented the process.vi using the JKI State Machine which worked really well, so instead of having a finite State Machine, I had a queued State Machine that could except arguments using a syntax that I am familiar with. I used dynamic registration for the messages coming back. It worked nicely - so good job on the Endevo AO stuff.

I actually have to give a user group presentation on this DVRs and stuff, so I have been playing with them all day today. They seem robust, I guess I have to keep using them to figure out how to do this stuff the best. But if anyone else can keep posting up what cool stuff they are doing with them that would be awesome.

One thing I did pick up - and correct me if I am wrong - it seems that the reference goes out of memory along with the owning VI. I had a launcher.vi that created the LVOOP-DVR refnum and then passed this to the launched VIs. By the reference seemed to die when the launcher stopped running. I don't have this issue with SEQs.

Dear All,

I want neural net VI's for training and validation Labview 8.0, so can build my own neural network

Pande

I have seen these links, don't know if they will help?

http://decibel.ni.com/content/docs/DOC-5381

http://decibel.ni.com/content/docs/DOC-4139

Cheers

I wish I had a link to that original post from long, long ago - it was a real eye-opener.

Check out from around slide 52

improving_performance.pdf

Check out from around page 10

17 - Managing Performance and Memory.pdf

Do I need to close the reference, say everytime I update the value through a property node (pass the ref num through the property node to a close ref vi)?

Hi Pete

Any VI Server reference you explicitly open - you should close. That is good practice to avoid memory leaks.

I am pretty sure tho that AQ posted somewhere here, that with property nodes, the references are closes when the owning VI goes out of memory.

I love my media center and media extender!

Damn straight!

I got the PS3 connected to the server via wifi running some open source software to browse my media.

I don't think I could live without it. That and torrents of course!

The only problem is that the router is on my desk and it jiggers with my wireless mouse.

This is a problem when my misses is watching stuff and I am trying to LabVIEW

I do not believe you can FTP files to and from the module.

(Haven't used it for a while) but I believe this is correct too

My solutions usually come to me in the shower.

I find the can is a great place to think and to solve problems as well.

You can link tunnels so they're automatically wired when you add new cases. Right-click on an output tunnel and select Linked Input Tunnel and then Create or Create & Wire Unwired Cases.

Its worth a mention that, that feature is only available in LV8.6+

Jcarmody is right - If you want to update values on a case by case basis, then pass a single cluster via a Shift Register (or feedback node) and bundle the changed value per case into the cluster. Wiring all those values out through the structure as you have, is just plain ugly and is why you think you will need to add more wires when adding more cases - this is incorrect.

the LabVIEW case structure is much less convenient to use than the other programming languages, image if we get more cases, we'll have to add more wires.

LabVIEW used correctly is very elegant.

Thank you very much, it is just what I mean. but I wonder why my solution doesn't work, the output is always the number of the hits for the last random number, the other hits are 0. As below:

The output of each numeric is always going to be the default value of a double (DBL) - which is zero, as you have use default if unwired selected on the output tunnel of each one on case structure. You will only return the correct number for the case that iterates last in the for loop.

that is: with 10 possible values, generates a set of random numbers(the number of the random numbers is specified via input, say 100), and counts how many times each of the 10 values is hit.

If I read the problem correctly - this may work?

[cross posted to ni.com]

Is this related to how the new plots are implemented in 2009?

Are the FP Objects here, associated with a default class (or in this case an array of classes)?

Or is this totally different?

You can all sign up to be lead users for this and all the other cool technologies presented at niweek here. I would hurry before NI shuts down that page.

Cheers for the link

I installed a R&S CMD60 driver in my PC, and i can use its vi by select add vi, but i am wondering how can i select this vi in control pane directly? Just like we can select DAQ, Motion...... VI. That will decrease little workload to search the path where the driver is.

Hi Levin

{by control pane I am assuming you mean functions palette)

If the drivers did not come with a palette file you make your own.

I recommended sticking the driver folder under the LabVIEW hierarchy e.g. <user.lib> (or where ever) and create a palette menu for them by selecting Tools>>Advanced>>Edit Palette Set from the LabVIEW menu.

Alternatively you could use VIPM.

Cheers

Actually it's A-ish. Files that are under the LabVIEW directory are "bucketed" in a LabVIEW folder. So from the example:

Adam and Gmart

Thanks for clearing that up.

By far, my favorite keynote demo:

http://zone.ni.com/wv/app/doc/p/id/wv-1700/upvisited/y

This was very cool.

But I am of the understanding that it was a sneak peek not a 2009 feature - is that correct?

This is indeed fixed in 2009. VIs in a built executable or DLL are now stored with the same directory structure as they have in the development environment. This also makes code to handle path differences for call by reference in built apps unnecessary, and there's a new VI (Application Path) that returns the directory containing the executable so that you can find files outside of it. Overall I think handling of paths in executables is much easier in LabVIEW now.

Hi Adam

I was under the impression that just the files that have name collisions are remapped to folders inside the exe. But from your post and rereading the help documentation, it seems the entire exe structure is mapped as the development environment folder hierarchy.

Is this correct?

Where do vi.lib, user.lib files outside the (top level) src directory go?

Cheers

Time for some playing!!

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

Want to ask if it's solved in LV 2009 ?

Thanks, eg

Hi Eugen

You will be pleased to know, as I am, that is has been

Check out the release notes or I posted details here

Whooo Hooo, it came through!!

I'm really happy to be at this point, its a new direction for me but one that will be a lot of fun, and bloody hard work. Thanks to the guy's at NI Australia for your support

Well done mate!

Added request to Ideas Exchange

I did several cosmetic improvements on the new icon editor that ship with LabVIEW 2009.

Looks good

It has taken a while to adjust to the toolbar on the RHS.

Annoying? I'll bet you've spent more time typing up the response than it would take to implement it. It's really simple and once you set it up (taking all of 2 minutes) it's transparent during package install and uninstall.

Save this vi as MoveToOsdatadir.vi to the same place as your .ogpb file. Swap the constants and save another vi as MoveFromOsdatadir.vi. On the OpenG Package Builder 'Script VIs' tab, type 'MoveToOsdatadir.vi' in the PostInstall VI path dialog box and 'MoveFromOsdatadir.vi' in the PreUninstall VI path dialog box. Done. Build the package and install it.

I must clarify annoying - one of the features I like about VIPM is its ability to install and uninstall packages, upgrade versions etc.. All this is quite transparent to the developer.

If I have to manually handle this, then yes, I see it as annoying. As for quickly solving my problem, I cut and pasted the icons in the directory before I started the topic

I just want a clean way to do it

Anyways thank you very much for replying and the snippet.

I am trying to post to Ideas Exchange about the public folders. But it is coming up with Post Flooding - wait 900 seconds

By the way - its seems you have posted some interesting Ideas on LVOOP - good job

PJM just made a cool post editing the Icon Editor! Maybe I could give that a go!

Iam new to this LAVA Lounge. The current project which iam working involves a lot of FP screens (modal). I am searching for a better navigation systems for the screens control. Right now iam using buttons in every screen to jump to next screen. is there is any better way of handling this situation? Please let me know if u have any solutions.

Hi John, welcome to LAVA.

If the screens need to interact with each other then I would go a different route - but from what you are describing with the modal screens - the user can only use one screen at a time so the following may work for your application:

Would using a main screen containing a subpanel with a common toolbar and run time menu sound like it may suit your GUI?

Similar to what you would find withe LabVIEW Options dialog.

I like using this for most of my applications that have multiple screens and can share common buttons/menu items.

Cheers

JG

If you have ever given Aristos Queue a Kudo or been helped by one of his post then here is your chance to give back.

Happily done.