asbo

The stream API is not supported on the USB-8451 - I don't remember exactly where I read this, but I'll try and find it for documentation's sake. I'm actually using the USB-8451 right now (and might be moving to the USB-8452 for the higher clock rate), but I'm happily using 8-bit transfer sizes. I haven't scoped my clock to see what it's doing, but I'm reading and writing 256 bytes arrays at the speed I expect. Perhaps if you use the scripting (it's on the advanced palette), you can control the clock better. I didn't see any immediately benefit to using scripting so I never looked into it - seemed a little heady to try and set up, though there may be examples. The documentation they have on these devices and toolkit (NI-845x Hardware and Software Manual) is pretty meh - the hardware descriptions between the 8451 and 8452 are pretty inconsistent, for one (for example, the USB-8451 doesn't list a transfer size at all). Any chance you have a stack of 8452's sitting around you can't use? I could use a few. If I had had more visibility into this project at the bid stage, I might have opted for the FPGA route as well, or maybe found a gang programmer before investing time in the NI-845x toolkit. My target device supported up to 75MHz, I'm stuck with masters that go up to 12 or 50MHz, and I have 8 devices to program. Ah well, we live, we learn. Edit: A couple of relevant docs, but they're probably no longer useful for you. Streaming 16 Bit Transfers Using the NI-USB-8451 Does the NI-8451 have SPI Stream API access?

I think the "right" solution is something like that latter that you mention. It's a more formal handshaking process and it guarantees that the data has reached its destination. IMO, polling the DOM is always a bad idea.

If you don't always want to debug, add a context menu item or an off-panel button with a hotkey set. Bury your breakpoint in the event handler of that object, and tada! On-demand block diagram!

I wish the US would catch on to more environmentally-friend waste handling. When I lived in Europe for a few months, *everywhere* had segmented trash bins with sections for recyclables, bio-degradable waste, and whatever else. I thought that was awesome and got accustomed to throwing things away into separate containers. Maybe they just dumped it all into the same incinerator when I wasn't looking, but at least I felt better about it, and that's what's important, right?

I'm not very familiar with the Windows Message scheme or the library you mention, but it is absolutely possible to implement your own messages for communication. There's some insight in this StackOverflow post, but I suspect that the library you're using does not support sending messages. Whether this functionality should be adding to the DLL or if it can be done directly from LabVIEW is unknown to be, but from the work I have done with Windows Messages, it should be pretty straightforward to do unless you want to pass complex data structures. However, Rolf brings up a good question - there already several constructs in LabVIEW which already facilitate this kind of messaging, and natively to boot. Are you trying to overcome a process barrier or something else? What is your use case?

I agree that property nodes force everything into the UI thread, but I hadn't heard about the "black box" bit before. Is there substantiation to that and, I guess, is it even relevant since everything will be in a single thread anyway?

You cheeky devil.

I'm not sure what the "Display Format" setting for a gauge refers to, but it's definitely not the digital display. I played around with it a bit and reproduced what you're seeing: even with identical formats, a numeric indicator behaviors correctly (e.g., 4 digits of precisions, do not hide trailing zeros). That said, I can't think of a single time I've seriously used gauges, so I'm not terribly experienced with them.

Because the retry works, the mount can't actually be gone. I think there's stock in something (ala antivirus) locking up the partition. I agree that's low-level addressing, but evidently the circumstance is such that the OS can't distinguish a missing partition and one that's be locked; though, it's entirely possibly an AV solution could accomplish that goal in a very sleazy way.

It looks like there's a lot of resources on the web for the HC-SR04 and components like it to be used with Arduinos - like this one - that you should use for reference. You didn't link to a real datasheet, but it did itself link to a library. You should use these to better understand on how you have to interface with the sensor in LabVIEW. It looks like you'll need to apply power from a 5V+ pin, ground via a ground pin, and then a digital input and digital output pin for echo and trigger, respectively. The distance sensor counter85 VI requires two counters - having skimmed the SensorDAQ manual, it looks like you have two counters, but you download a copy of Vernier's LabVIEW toolkit to use it. "The SensorDAQ has two counters as part of the hardware. One counter is available on the screw terminal, and the other is hidden on the DIG Channel. To access the hidden line, connect the DCU to the DIG Channel; line 1 of the DCU is the pulse output line. These counters can be used to provide a pulse output or a pulse train. The examples demonstrate how to do this."

If you knew specific files to look for on the hard drive, it'd be very easy to use a batch file. However, if you need to check versions, or something in the registry, it gets more complicated. Actually, I don't know an elegant way to check file version information (ala the Properties dialog) from the command line, and I'd be surprised if it's that easy in every case for NI software.

I hadn't heard of this before, but I'm hazarding a guess that this dialog isn't generated by LabVIEW so much as Windows itself - based on the title bar, verbiage, and button choices. Of the machines which experience the problem, is anything about the hard drive configuration common? Same motherboard chipset, same HD manufacturer, same RAID configuration? Another obvious question is, of course, what changed a month ago? Of the times that I've seen a dialog like this, it often pointed to file system corruption, but since the files in question do eventually load, I guess that's not the case. Still it wouldn't hurt to run a Scandisk (maybe checking for bad sectors, if you have time to kill) and checking the SMART stats for your drive(s).

Well, at least now you have a specific question to ask NI Support. I suggest something along the lines of, "WTF, guise?"

USI is NI's Universal Storage Interface. Of the other items in the list, I'd be more interested in the Deployable Licenses entry - are you using remote panels? A missing license will break the VI as well. Both of these "should" be available under Additional Installers. Is it possible to distribute debug-enabled applications through the installer and then attach to them after install? I've never tried, but it'd be really awesome if you could.

If it the solution doesn't need to be used in an executable, this may be possible with scripting methods, but that's just a guess - scripting's not really my bag.

I thought I had read somewhere that I/O to the protected Program Files folder was supposed to failover automatically to a mirror ProgramData directory. Anyone know what I'm talking about?

As far as I know, that's only if the paired device exposes a serial interface. I haven't ever seen a literal COM-to-BT mapping, but I'd be interested to be proven wrong.

Man, you are on fire with the transparent tricks.

Beautiful, in a way.

That could be true - I was looking at it from the perspective that LabVIEW wasn't properly acknowledging the launch and Windows was launching it again. Thinking back, though, I've never actually seen Windows retry a command like this, especially many times. On the contrary, I have seen it display a dialog stating that the command failed with particularly slow-launching on multiple occasions. Not I'm not sure where the blame may lie. Without a repro, it's very tough to guess.

Hmm. Sounds like a LabVIEW bug, rather than an implementation bug. Any chance you can repro it?

Did you select 50-60 associated files and try to open them all at once? On a related note, I know that Win7 won't let you "multi-open" over a certain limit (which is pretty annoying sometimes).

Haha, for me, it has very little to do with knowing my windows are more to do with being able to see all my code at the same time as my spec documents, notes, calling code, callee code... Try a multi-monitor setup and you'll never want to go back. That doesn't mean you can't cope, though. All of the testers I work on are single monitor and I do just fine.

It's incorrect to say that UDP is a "faster" protocol. It is more lightweight than TCP, but that doesn't inherently make it faster - especially in the use case you have, where you'll basically need to handle everything that TCP does automatically (and at a lower level). Speeds far in excess of 2Mbps are feasible using TCP, so you probably need to take a look at your implementation and maybe talk to your teacher about what you can do to optimize it.

It's bittersweet, but we take what we can get.