justingruenberg

Here's some more info on Windows 10 for IoT devices. This is basically the RT version that they were pushing before -- as in the Ars article it's "Windows without Windows applications." Basically, to get LabVIEW running on this or deploying to it, is going to take support from NI.

Since the rPi 2 is still running on ARM, nothing really changes.

What you're looking for is an analog frame grabber that supports DirectShow (which works out of the box with NI IMAQ like any webcam) or otherwise provides an API thats easy enough to integrate into LabVIEW. We've had good luck with ImperX and their analog frame grabbers designed for laptops. They have DirectShow drivers and their own API which gives some additional control over acquisition (and a LabVIEW driver). It doesn't look like your PC supports a Cardbus card, so thats probably out of the question. There are a number of inexpensive analog USB frame grabbers which might suit your needs. We've tried some of them and have found all of them to have some quirks (nothing serious). Most of these are pretty cheap, so you might as well try a few. Since these will all appear like a webcam, they'll directly work with IMAQ... so write the code once, try them all. We've been looking at another product from Pleora, but they have an analog frame grabber that works over GigE.

We've been using ImperX frame grabbers for a while. They work well, and ship with LabVIEW drivers. Unfortunately, they only have laptop cards (Cardbus and ExpressCards) for their analog cards, so you would need an adapter card to put it in a standard PC.

I've seen this. This has also happened to me when I've deleted a property of a class and LabVIEW takes a guess at what it should replace it with. I don't have any real advise for how to mitigate it, but if you can at least track down where it is... deleting the node and inserting it again seems to fix it. I'm almost tempted to give up on using property nodes. I had an issue a while back where some property nodes would just take down LabVIEW or the built executable they were in. There wasn't any complicated code behind them (most of the time this occurred, they were auto generated with the wizard). At least now it's only corrupting VIs instead of taking down executables.

That frame data looks like an error frame. What's the value of IsRemote in the return data from ncReadObj? "IsRemote" is deceptively named and can indicate an error (look into the docs for the function). Remember that when you send your request, the next frame may not be the response. It might be an error or unrelated frame (or a previous diagnostic response that wasn't cleared out of the RX buffer). If you're reading ncReadObj that will only read the first frame on the RX queue. I suggest using the function to read multiple frames (ncReadNetMult, but don't quote me on that... I don't have LabVIEW on this computer). Look into the examples to see how to use it to grab everything on the RX buffer.

I doubt that's the issue--using a unicode main() is the default for Visual Studio. Many quick and dirty examples I've seen shipped by a vendor keep that (instead of changing to main and char*). If you want to test this out... change their example's main to: int main(int argc, const char* argv[]) { Initialize() accepts a char* as it's first arg, so I'd doubt thats the issue.

I agree. An option would be nice. What I do to avoid this is not set any of the UI settings in the VI that would prevent me to close it in the development environment. I make those changes in the build specification, so they happen only in a deployed executable. The downside is if you reuse that VI in multiple executables, you need to duplicate the settings multiple times... but I think it makes my life, overall, easier.