asbo

Make Queues use the value of the data type input as default output value in error conditions

I think you mean programmatically, but it depends on what interface your devices use.

Virtual machines are great for this!

Expanding on this, put all of the LEDs' Value Change events in one case. Wire the CtrlRef terminal into a shift register (or FG, if it's merited) and then you'll be able to use that reference to refer to the LED last updated.

Aye. However, I don't use queues often enough to justify either approach ... yet. Idea'd it, just for kicks.

We actually have a couple stands out in our shop that have touchpads built into their roll-out keyboards as well as touch screens. It'll be really handy in the field, but I almost always walk back to my desk to write any significant amount of code. I only recently stepped up to a dual monitor setup and I'm loving it. Yep, I get too accustomed to having all those niceties and it does make me slower when working away from my desk. The only thing I depend on to code these days is Quick Drop and Auto-Tool.

Congratulations! Unfortunately, this has been a reminder for me that I need to get moving on my certifications.

There's a couple companies that make micro linux boards, where the biggest component is the ethernet port, so it'd definitely meet your size requirement. However, I don't know about the power consumption. Sorry, I don't have any links off-hand.

I don't really understand what you're expecting. A terminal has to pass a value, like on a case structure: each case must wire out a value for every tunnel or you enable default value on unwired. It simply can't pass "nothing", how would LabVIEW know how to handle a wire that could sometimes be "nothing"? This is why the default value being returned makes sense. You can either implement error handling to skip the dequeue if there's an error or use code that will catch when it's been passed a default value. As an aside, I wish that the Obtain Queue node would use the value of the data type wired in as the default value for that specific queue instead of the default value for the data type.

Not necessarily. Consider an example scenario where you have a 2D array where columns are UUTs and rows are DAQmx channels to read. This array is wired into a For loop to handle reading each channel for all UUTs in a single task. For some reason (plot device, in this case), you do filtering on the rows and could end up with an array of dimensions 0xN. This is perhaps not a "special use" but it certainly has functional significance in this csae. The explanation of default tunnel value makes sense, but I understand the scenario you're in and don't have a knee jerk epiphany to handle it gracefully.

TIL. For a while, I was using a programmable Logitech trackball mouse becuause it's my personal preference, but more and more I found that the shortcuts I had programmed for the mouse wrecked my productivity when I was integrating on test stands. I got tired of having to code in two different styles so I use a normal optical mouse as much as possible.

I noticed it passes an array of ranges, but I didn't have a chance to make the correlation to channels. Did you figure it out?

Sure, use a DAQmx Device Property Node:

This is a good explanation of what my prescribed "best practice" is really looking to prevent. I fully support using GUI controllers as long as event refnums aren't being created and destroyed at different levels of the architecture (I updated my first post to not encourage this).

Upload the VI.

Thanks for being the exception to the rule, Ben.

Aleesandro, you should post your VI so other developers can try to reproduce the error you're seeing. Also, what version of Skype and Skype4COM are you using?

I'm mostly poking fun The two are functionally equivalent, Inf+ is just pretty and more self-documenting, IMO.

You can wire control references into a Register For Events node to create a dynamic event refnum that can be passed into a subVI. Once in the subVI, perform the registration for your dynamic event refnum. In general, though, it's best to leave a UI-related event structure in the VI it responds to.

I haven't looked at any VIs in this thread, but if you're not wiring an Inf+ constant for your "crazy large number", you should be.

I agree, this is the time to handle all the design considerations. I can't give you any specific recommendations about relays, but NI has an article you might find useful: How to Choose the Right Relay.

I think the fundamental functionality of this VI (split into single elements) is the way it should stay. Once the data is broken up, it's relatively trivial to reassemble it into desired chunk sizes.

Don't forget to whore it! This post made me realize you program without dots on wire junctions... you're crazy, man.

You'll need to cast that GetSAPObject variant to a LabVIEW ActiveX reference. You already do this with the Connection variant, you just need to figure the right type of reference to cast the GetSAPObject output as.

Greg, thanks for your reply. Using subroutine priority is somewhat inconvenient for development, but so far it appears to be doing the job. I don't think that corner case will ever apply to this code, so it looks like I'm in the clear. Thanks!