asbo

Then in that case, I would argue that what we're talking about here is not a data name, it's a wire name. A data name would be a label I'd expect to follow a given instance of data through its lifetime, with some nuances if it's value is modified. Going through a terminal into a subVI, though, isn't a modification.

The point was raised that the Get Data Name VI in the OpenG Labview Data package doesn't quite live up to its name in an intuitive sense. In the same VI scope, it correctly gets the name of the data on the wire, but in a subVI the terminal changes the name of the wire, and so the output changes: FWIW, the Flatten to XML node behaves the same way, but I think Get Data Name would more aptly be Get Terminal Name. Anyone think it's worth changing?

Yes, have a look at the Disabled property of your string control. You can use the Value property of the numeric control to decide the disable state of your string control. The KeyFocus property will move the cursor to the string control.

Have a look at DAQmx Trigger, you probably want to use the Reference Digital Edge mode. You may need to have trigger lines on the same card as the counter task, but even if you're using quadrature encoders you should have a couple lines left over on the 9401.

My impression was that setting only did anything if DHCP failed, not necessary any TCP/IP connection.

Except for when I install something and NI Update gets re-enabled, I forget it's even there. It seemed a little half-baked to me, and I haven't seen it get much attention or publicity from NI. I think he rather meant post the images of the DVDs, so we could burn our own if we wanted. Are the packaged installers also a few steps behind individual releases?

Write Std Out with Redirection.LV8.0.vi

Out of curiosity, is anyone using NI Update?

Generally speaking, I feel that if I have to use a local, things may not be structured well. Typically, I keep my actual data disconnected from the FP. If it's a control we're talking about, I use an event to update internal state data and then reference that where necessary; if it's an indicator, internal state data will occasionally be pushed to the front panel. I use locals over property nodes if I don't need to enforce execution order, but to be honest, everything has its place. I didn't mean to hate on locals, necessary, but they just leave me feeling icky. I expect that you still bend or break your rule, though... That's what rules are for.

I thought it was a little weird to have a display loop, but I'll admit I don't commit too much to design patterns. Producer-Consumer-Display seems like its beginning to encroach on Model-View-Controller, but in a different order. I'm not sure why P-C always seems such a popular choice for practice problems. It's one of the most obvious patterns, I suppose, but I agree that the problems are not necessary apt to it. I think a queued state machine (waiting for Daklu to swoop in ...) would have been my inclination here. K.I.S.S. In any case, for P-C-D I would put all control terminals/references in the producer, none in the consumer, and all indicator terminals/references/property nodes in the display. Control property nodes could probably go in the display loop as well, depending on which property they dealt with. In general, I avoid Locals.

I had to approach this problem last week (I was searching for a text string in a folder of VIs which didn't have an easy ancestor to force them all into memory) and used the method GregR mentions about keeping the UI running. It was brain-dead simple for me, just a blocking event structure while I ran LabVIEW's normal Find tool so LV wouldn't try to cleanup all the references. I didn't realize that it would do so, even if I didn't close the references AND left them in an USR, which is a horrible realization after spending 5 minutes loading several thousand VIs...

This doesn't have much to do with LabVIEW at all. You can interface with Excel using ActiveX automation. LabVIEW has no built-in support for the xls/xlsx/xlsm formats. If you familiarize yourself with the Excel ActiveX interface, you may be able to find methods or properties you can access from LabVIEW to discover the value of the checkbox. Personally, I've only worked with spreadsheet data from an XLS, never VBA controls, though I feel confident saying there's probably a way to find what you're looking for with enough research.

You are correct about the behavior of the simple example you describe, but your consumer loop is not the same as that example at all. As soon as the consumer while loop begins a new iteration, your control values are read. Then, whenever the dequeue finally gets an element, all of the input values (probably with the exception of "Flame Sensor Value(%)") will be stale. I haven't looked any further into the logic because I'm not familiar with the requirements of this example, but Todd is 100% correct about the behavior of the controls in the consumer loop. I don't understand why you put the "Flame Sensor Value(%)" terminal after the case structure in a sequence structure, or why you have a 50ms delay in a blocked loop. Wrapping the controls in a sequence structure, for example, will will ensure the correct values are passed into the case structure: Personally, I think that your consumer should not be interacting with controls at all. The producer should read values, and pass the data with the command to the consumer. Since you have a display loop, the consumer loop shouldn't have any terminals, references, locals or property nodes in it. For example, you have a subVI which uses a references to change the blinking property of the Pilot boolean.

What implicates "have to"? Do some controls not report/respond to/whatever relative scrolling?

That's just what they want you to believe... Yeah, that could be. I went back to re-watch (~0:34-0:38) and I don't see the target, and the slug just goes into a hillside? That makes much more sense. On the prior shot, where you actually see the muzzle, it looks much more stable.

Cat has been MIA for a while. Abort!!!!! Haha... Looks awful unstable in that first video, but I guess at 5600 MPH it's more about brute force.

I finally watched this tonight and holy crap is it cool. With each example, I was both impressed at his insight and disappointed I didn't think of it before he said it. Goes to show how entrenched I am in my current methods.

I'm using the USB-8476 on a LIN bus to talk back and forth with my DUT. As I develop in LabVIEW, I've been using CANalyzer to monitor the bus as I test new messages. Everything was swell until I started implementing a full frame message, as opposed to a header frames. With CANalyzer running, I consistently get a 0x2011 framing error after every full frame I send. As soon as I stop the measurement in CANalyzer, I stop receiving errors and my DUT responds correctly to my full frames. I have the CANalyzer measurement configured with master mode OFF and the master resistor OFF, which is why I thought I was in the clear. Having written this up, this is probably more of a CANalyzer question than anything, but can anyone offer some guidance? Cross-posted to NI forums.

It sounds more like you need to learn the DSP theory than about the VIs specifically. For whichever VIs you're interested in, use either the name of the VI or whatever documentation there is for it as a jumping off point for your Google searches. Yes, NI examples make it a lot easier, but sometimes you just have to learn the hard way.

It's only a workaround, but why not lift the portion of your software that needs registry access into another EXE? When you need to modify the registry, call that EXE, you get the just-in-time UAC prompt and everyone goes home happy, but most importantly: it's easy. You should link to the example code. Most API calls can be implemented in LV, if you have the patience and know-how.

That is a great palette. Thanks for your hard work, jg!

I would assume so by now, but do you know if it's actually been reported?

I'm surprised that it even works at all, since the properties are in a different order. I take that to mean LV maps its property nodes in a somewhat intelligent way, but for speed's sake, I hope it's not via reflection... My expectation would be access violations, or corrupted data at the very least. You are both reading and writing?

Yes, I rather meant that prev/next would be indices in a parent array, where data would actually be the data cluster. The indices would be used for lookup, which could make traversal a little more work (thus my legwork comment). So, as a C programmer would write: cluster data { ... }; cluster node {int prev, cluster data, int next}; (whatever metadata is appropriate, this is really more of a linked list) cluster[] tree; I should have warned in my first post, I didn't look at your implementation. I don't consider myself experienced enough to critique LVOOP methodologies, I was just throwing an idea in the ring. I'm not an OOP nay-sayer, but if you can't get the performance you need there may be other options. I'm certainly interested in what implementation reaches your goal for you.