crelf

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:

This means that If an error occurs on a terminal, the node stops at that terminal, returns an error, and does not execute any further terminals. You can right-click the node and select Ignore Errors Inside Node from the shortcut menu to ignore any errors and continue executing further terminals.

...Godwin's law...

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:

Now they hara*s my daughter in Canada:

Yesterday the owner of the company, a Jewish woman, said to my daughter to go home, because doesn

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!

Here's me, when I was just a runt.

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

I was mostly concerned about Control References (right click a control -> Create -> Reference). It seems that they do not change whenever they are read and therefore do not 'need' to be closed, so I don't need to go back and fix old code.

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!")

G'day, Chris! Actually, my set up is a 1600x1200 and a 1900x1200 -- only 60 pixels (wide) shy of 2560

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.

...the development environment crashes on me periodically when editing VIs.

Wow! I'd call that a shopperstopped

.

.

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 beg to differ. Case in point: we're happily debugging and adding breakpoints left-n-right as we go. We finally find and fix the problem. At this stage, I shouldn't have to go to each breakpoint -- some of which I don't even remember where I put them (may be in a false case which doesn't get exercised under normal operation, for instance) and clear them manually.

-Khalid

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

It will be nice to have a "Clear All Breakpoints" feature (from the menu). Just like MS Visual Studio, for instance.

-Khalid

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.

Of course let's not for get our own homegrown Star Wars kid from Quebec.

http://www.ebaumsworld.com/starwarskidv.html

3173[/snapback]

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

The demo "Language Translation Demo.vi" automatically sets the captions and tip strips to the correct language, and the lower level "Translate Language.vi" can be used on a case-by-case basis to translate strings/words/phrases as required (in all the projects I've used this technique, if I need to set the text in a string indicator, I'd just pass the English through this little VI). A few people bought up a couple of excellent points - my initial description would only change captions, and not other things like chart axis labels, table column headings, etc. I've added in the functionality for these components to be automatically changed as well, although it's not completely comprehensive (for example, it deosn't change actual data - text inside a string control or indicator isn't changed automatically, as it's data - not cosmetic). There are also a couple of limitations (including controls on tab pages not being updated), but I'll post a better version once I've gotten over my NI-Week jetlag. If anyone has any comments, I'd love to hear them.

Hope that helps

Cheers,

Christopher

Download File:post-181-1092849603.zip

Yeah - I had a look at that, and they all keep their front panels