crelf

Can you reporduce the issue with a smaller subset of your application? Maybe narrow it down to the VI or a group of VIs that the documentation generator is bugging out on? If so, can you post the Vis?

The library has to know that an item is a friend to grant it access to the community scope. Granting a particular other VI access to a particular VI within the library is something we could have implemented, but fiddling around with that level of declaration is usually noise -- if a VI not in the library is closely bound enough to the library to need a friend relationship, then it frequently wants access to multiple community scoped VIs, and you've already said that you know this other VI well enough to trust it with general access.

That's fair.

So it was all touchy-feely then and about trust awhh.....

Sounds like the progression of most relationships. Or is it the opposite?

No, not a touchy-feely post about love amongst mankind, but a philisopical question about access scope. I have two classes: Class1 (contains MethodA) and Class2 (contains MethodB). When I set MethodA's scope to community, and I want to put it on the block diagram of MethodB, I need to make MethodB friends with Class1. Why can't I just make MethodB friends with MethodA?

I learned something today. From the LabVIEW help:

Note: You can set individual instances of a polymorphic VI as private and set the primary polymorphic VI as public. The polymorphic VI does not break even though instance VIs are private. Setting instance VIs as private is useful if you want users to access instances only through the polymorphic VI selector, so you can edit instance order without causing user problems.

Thanks for your input everyone - the time has come to bite the bullet and get it done. I think I'll start with InnoSetup and see how that goes...

Does the control to be routed to already exist? If not, replace the old one with the new one - much more straightforward.

Edit: SuperS_5 got there before me

I have tried simply passing a reference to the graph to the sub-VI, but I've had no luck.

That should work fine - post your code and we'll take a look at it for you.

Check your LabVIEW.ini file for fonts. You can also just select the offending controls and ctrl+- (that's hold the control key and press -) a few times to get it back to where you want it.

I hope i explained the diagram correctly.

Can you upload the code? Much easier for us to comment and make suggestions if we can play with the code.

Is there a way to create a SubVI with a real "poly" input?

Well yes, but no. LabVIEW can't do run-time polymorphism, so somewhere the poly child needs to know explicitly what the data type is so it can act on it. That said, you can acheive what you're looking for with limited functionality with variants (as mje already suggested) or you could put together an OO architecture that uses inheritance. Either way, you're still just kinda pushing the strictness down the line to somewhere else (which is totally fine, if that's what you're trying to do).

I'm not going to give you a template, but you can make your own from an online resource or two. I like this list of what should/could be in a SysAD/SysDD/SSysDD - it goes into sufficient detail on what each section should contain. Note: I often break what's listed under "Detailed System Design" into SubSystem Design Document(s).

Confirmed (LV PDS 2010).

I am miffed by this behavior, which is not how all other "normal" variables behave when you pass them to a Sub-VI.

You can be miffed all you like, but it's actually *exactly* how it works with all "normal" varaibles - when you pass something on a wire into a subvi through its' connector pane you're passing the value of the data on the wire, not a reference to something that was the source of the wire. The connector pane of a VI goes to a front panel node (like the graph you put on your subVI's front panel) <- there's nothing fake about that graph - it's a real graph, it's *not* a reference to the graph in the caller VI. ShaunR's right - if you want to pass a reference to something in a caller VI, then you need to do exactly that - pass a reference to it, not it's data.

There's something wrong with the link - I get "Page Not Found" back from NI's server.

We've got some big changes in what's running behind the LAVA Code Repository coming soon - hopefully they will fix this issue. Stay tuned...

So the problem is, without knowing exactly when the rollover occurs, I don't know how to accurately calculate the dt at that rollover.

That's *exactly* what your problem is - if you don't know when the rollover is, then you don't know when the rollover is I'd try to talk to the vendor to find out the exact rollover value. Yair's right - you can approximate it (and the more times you run it, the closer ou'll get), but if you can find out the exact value then you're golden.

Use the Control Value Set method to pass data to the controls and then run the VI with the wait until done flag set to false.

Right - that what I was trying to get at. Thanks for posting the screenshot.

What you see in the image on the screen is a combination of the image and overlays. When you perform measurements (like finding edges), LabVIEW doesn't change the pixels of the image - it instead includes the new information as an overlay, which doesn't form part of the image at all (so the original image isn't corrupted). What you want to do is use IMAQ Merge Overlay - it merges the overlay stuff destructively into the image.

I used the call by reference so I could wire in an input to the utility - so I can't use the "run" invoke method and tell it not to block...

You can call the VI dynamically using a loosely-typed invoke and then set the inputs on the FP, then use the run method in non-blockling mode...

InstallJammer - the most intuitive and friendly of free installers I have found.

Thanks vugie - I'll check it out. Just a note: I'm not necessarily looking for someting that's free - if there's an app out there that you recommend that costs $, I'd like to hear about that too

I had some strange issues when integrating LV created installers within the main build, but it was quite long time ago, so maybe they went away.

What kind of issues?

So I'm creating a suite of software that will have several components (some of them will be built in LabVIEW, some not), and I'm looking for something to build that final setup.exe that will include all of my components as well as be able to write registry keys. I'd like to show custom logos on the UIs and windows that display license files, but they're secondary (the components will have their own installers, I just need this supervisory one to install them all in turn). I also need the ability to allow the user to select components (although some of them need to be installed). I sued to use InstallSheild for this (but that was long ago), as well as Setup2Go. Anyone got a favortie installer app that they've got personal positive experience with?

I wanted to bump this thread, as I'm having the same issue right now. Please vote!

Can you upload the file and the code that you used to write and read the file?

If you can't get to lavag.org and you're not sure if the issue is on our side or ours, follow @lavag on twitter - that's where we'll post updates on our site's health while it's down. We also post links to hot lava topics there, so go follow us here!

There's more info on what to expect on the @lavag feed here.