crelf

What's the next step in the hazing... I am not going to have to do any binge drinking am I??

Nope - you have to drink water and watch all of us binge drink instead Mmmmmmmm... Shiner Bock....

Hey! Colin's made us famous! Check out the link in his signature

Good catch. We have verified that this is in fact a bug with the ways in which paths are formed in certain situations.

Great - can you please provide a CAR number so we can track it here?

We don't mind. However be warned, we speak our minds here and the undesirable posts are not removed by NI, so carefull about what hornet's nest you poke a stick at.

Ouch!

...local and global variable reads do NOT cause a thread swap to the user interface thread

Local and global?!? Wow - this is completely the opposite of what I'd been previously told...

Thanks, crelf.

You're welcome! The tea must have been good this morning

1. Any ideas on how to get the green arc at the top?

This example shows two ways of doing it - the first one just have the green arc, the second has an arc that changes colours depending on whether the needle(s) are in the "zone" It's a real shame you're not using LabVIEW 8 - this would have been a great example of an XControl...

Download File:post-181-1143497662.vi

Download File:post-181-1143497673.vi

it should have been just ".\nidaqmx.ini"

After further research, it turns out that it needs to be a fully-qualified absolute path.

It appears to be a permission problem... if you copy the nidaqmx.ini file to c:\ and edit the "NI-DAQmx.ApplicationStorageFile" parameter in the apps .INI file to point to the c:\NI-DAQmx.ini , it should work.

Also from Info-LabVIEW: Thanks for the suggestion Dan - it cleared my mind! Actually, it's not a permissions issue, it's that the builder creates the wrong path in the application's .ini file - my NI-DAQmx.ApplicationStorageFile was set to "applicationfolder\nidaqmx.ini", where it should have been just ".\nidaqmx.ini" - looks like a bug to me!

1. Meter.jpg - This is a common Simpson panel meter

That one takes a little more work and a couple of customized controls (see attached VI)

Download File:post-181-1143487178.zip

2. Button.jpg - I thought I remembered seeing a push button Boolean control in the past. Cannot find it now.

Check out the "Classic Controls" sub-pallete - it's there under "Boolean"

3. knob.jpg - I need a knob that will 'click' to preset positions.

Drop a normal knob down on your front panel and change its representation from DBL (the default) to an integer

I'm having the same problem - I create a very simple VI (DAQmx read in a loop - output to a chart):

and I create the channel in my LabVIEW 8 Project. When run in the LabVIEW development environment it works fine

but once built I get error -200428 "Value passed to the Task/Channels In control is invalid. The value must refer to a valid task or valid virtual channels."

Anyone got any ideas? (I've attached the full project in a zip)

Download File:post-181-1143480404.zip

One wrong move and you might end up deleting a whole day's work.

So it needs a voice recognition component - whenever the user says "oh crap!" it automatically envokes an undo

...a real invitation to fingerprints on the display screen! :laugh:

...a good reason to do the demo in a darkened room

It had weight before.

I, in no way, was suggesting that it didn't - I have ultimate respect for Jeffrey and his books (I understand the pain of authorship) - that's why I said the Jim's inclusion lends weight, not creates it. Personally, I like Jim's attitude to LabVIEW development, and I think that it will add even more credibility. Congratulations guys - I can't wait to get it for my library.

Is it just me, or has there been more and more LabVIEW books for sale on eBay recently?

Over 100,000 write cycles...

That's not bad - not bad at all...

I can't wait to see LabVIEW development using this.

Awesome - add a multi-screen interface to LabVIEW and I'll buy it!

I just checked at Amazon, and they have it posted, so let me also plug:

LabVIEW for Everyone : Graphical Programming Made Easy and Fun (3rd Edition) (Hardcover)

By Jeffrey Travis and Jim Kring

Looks exciting, and the addition of Jim certinaly lends some weight to it. Although amazon.com is still using an old editorial review: "Now, completely updated for LabVIEW 6i"

Why not state retrieval from flash ram?

I hear ya - I usually just hibernate my laptop (it has real difficulty shutting down) - if only I could just hibernate it to flash then it'd start up much faster. That said, is flash more stable these days? (ie: how many read/write cycles can it go through before giving up? I vaguely remeber a rumour about it being very low... )

People always find things in the last place they look because after they find it, they stop looking.

That's got to be one of my favourites!

An optimist says the glass is half full, a pessimst says the glass is half empty, and an engineer says the glass is twice as big as it needs to be.

We eventually found that all o the timed loops were exeting prematuturly.

Oops!

Everything that Jim and Mike said - it's like Info-LabVIEW in a rich environment.

Just curious: why do you ask? Is it because you're aiming to make the NI discussion forums more like LAVA?

Switching all of the globals... over to LV2 versions has dropped my CPU loads from 75% and 50% to 4% and 4%.

Crikey! You must have a lot of global accesses in there - looks like most of your CPU was being taken up by obtaining mutexes and thread swapping A great demonstration of another reason why globals are evil!

But why bother building an XControl if you're only going to use it once? Isn't it just as easy (easier actually) to just build the functionality into the VI where you're going to use the control?

It's easier in terms of time and work to implement, but XControls abstract the data handling you use just to display it, so your code is more readable (eg: you're not cluttering up your main BD with code that just rotates an array and picks off a few values to get them onto a graph) and generally easier to debug. Sure, you could just have all the code on the BD or put it into a subVI and then into your FP node, but XControls really clean all of that up. I also agree that using them in different places and across different projects is certainly useful too...

Changing the world, one VI at a time.

That's just *sniff* beautiful!

Sorry, I should have been more explicit. I was not trying to detract from dqGOOP -- I was just answering your question about whether OpenG, or anyone else, could legally use a similar implementation. IMO, a pure G GOOP implementation is best if it is open. Stay tuned, interesting things to come.

Ahh - gotcha. Staying tuned with great interest...