crelf

Can you post a copy of your VI here and include a couple of images so we can be a little more clear on what you're trying to acheive?

Shhhh! Don't give them any ideas!

Hey Paul, The red glyph means that someone has set the node to ignore internal errors (righ click on the glyph > Ignore errors inside node). From the LabVIEW Help:

It had to happen eventually (by definition ) - for those unaware of Godwin's law click here Also, by definition, that means that this topic is now closed :laugh:

You might want to contact Neo Vista System Integrators (www.nvsi.com.au) - they were recently doing a bunch of GPS work with PCI and serial devices (using LabVIEW of course), and could probably point you in the right direction...

...all we need now is a bunch of "Powered by LabVIEW" stickers, hats and shirts! Wikked!

Gr8 photo sk8r boi (it almost looks fake - just like this one of me on my traillie...)

G'Day All, A client of mine has upgraded their test system from 7.1 to 8, and found something curious - one of the tests that worked fine in 7.1 yields no results at all in 8. A little probing (literally) uncovered that the point-by-point polynomial fit wasn't returning any values - there are no errors, just empty outputs. Has anyone else seen this? <p> Download File:post-181-1138143550.vi

Yep - that's my interpretation as well. The control reference is created (it's not very big as it's just a reference to a control, not the data within it), so I wouldn't bother closing it. (I can hear my old programming teacher who'd worked on ENIAC spinning in his grave: "Every bit is sacred!")

so close, and yet so far! :laugh:

Have a look at this recent post on the NI Discussion Forum - it answers exactly what you're after (and more). In summary: "VI-Server "Static" references (this App, this VI, Control-references) allocate memory (once). If memory's an issue, close them, otherwise they close automatically when Application exits." As for them being bad practise - I suppose it's like anything else - it depends on how you use them Control references are great, and can open up a whole lot of control (pun intended) that was previously either unavailable or really messy to acheive.

Wow! I'd call that a shopperstopped

. NOTE: This is a cross post from Info-LabVIEW . G'Day Everyone, I work for a fairly large System Integrator, and we're considering the migration from LabVIEW 7.1 to 8.0. Recalling the considerable hardship the 5.1.1 to 6.0 route caused to just about everyone, I'm being a little cautious. I'm not one of those that swears not to migrate until software is in the x.1 phase, but I also recognize that significant changes were made between 7.1 and 8.0 (I was a member of the beta programme and liked what I saw, but the beta software wasn't anywhere near finished so I couldn't test a lot of what I wanted to - it just wasn't ready. I have used the 8.0 release dev environment as well, but not extensive enough to consider it on a full-blown project as yet). I've used a number of methods in the past to evaluate the time to move from one version of LabVIEW to another, and probably the most reliable that I've found is Info-LabVIEW itself: perhaps the number of issues reported here are directly proportional to the number of issues I'll have with it? I've also noticed that the number of posts generally increases after a new version is released. But it doesn't seem so this time - whilst there have been a handful of issues reported here since 8.0's release, I have seen anything that would be a show-stopper, and I was wondering if that is because everyone is more than happy with 8.0 (I certainly hope so , or people aren't happy with it and are keeping their mouths shut, or maybe you're like me and are waiting to migrate your new projects once its' been proved robust? In short, my questions are: for those who've used 8.0 on projects - how's it going? What sort of projects are you doing? Are you finding any issues that make you wish you'd stayed with 7.1? PLEASE NOTE: I am not interested in license issues here - if you wish you'd stayed with 7.1 because you think 8.0's license is restrictive then you've probably already been represented on this list, and I sure don't want to hash through that can-o'-worms again Just the technical aspects please. Thanks! Chris

Another fairly common term that I've come across is "VI Global" or "VIG"

Don't be too hard on yourself Pete - I had exactly the same problem with an XY graph about a month ago and I hadn't opened it in the control editor - I still have no idea on why it happened (I made a lot of changes to the graph and didn't notice it immediately, so I'm not sure what change caused this to happen...) PS: how's the weather mate? bloody cold over here! (those temps are in F )

I see this as more of a philisophical issue - my interpretation is that you're asking for is a strict-type where you can specify which parts of the type are strict...

"that's almost as good as two 1600x1200's side-by side" - are you saying that from personl experience It'd be great is it just had two side-by-side inputs, so you could use a dual monitor card or two separate cards and let your OS handle the placement of the virtual screens...

see here: http://forums.lavausergroup.org/index.php?showtopic=286

I understand your situation, but using this function could just as easily clear a breakpoint in an area that yo're not working. Also, if you're in a multi-developer team then you could be clearing breakpoints put in by other coders that you're not even aware of. I just think that you'll have to be careful when using this tool - it's like hitting ctrl+B to delete all broken wires: sure, you'll get your unbroken run button back, but you could be doing a whole lotta damage without even knowing it (and with no indiscation that you've done it)

I agree - my block diagrams are usually 1024 x something - I think scrolling in one dimension is fine, especially if you're working on a VI that uses parallel loops...

I don't think I'd use a "Clear All Breakpoints" function - I use breakpoints for a reason (debugging code), and I'd like all my co-developers to have to clear them manually after they've assesed that the code has been properly debugged...

Yep - in fact, it's not limited to OO: you can make any VI in a group private to another public VI, meaning that if you drag a private VI from one group onto a VI that's not allowed to access it, the run button will break.

Looks like you can also include debugging in a built application - app builder saves diagrams with VIs and you can use execution highlighting + stepping on a "built" app.

That's got to be one of the funniest things Iv'e ever seen