Using USB Camera without using IMAQ

[MarkGreally]

Hi Folks.

I am attempting to connect with a USB camera without using IMAQdx. Primarily because I dont have the license and it may be more beneficial to learn the nuts and bolts of it without always depending on a functional block. I came accross this discussion here which is kind of what I am after. The messages are similar to that of a C++ program I have used. However I cannot get it to work and there dosen't seem to be any camera selection or specified and the picture is just a black image. Is there anyone familier with this and know what I may be missing in order to get a picture and/or proper connection. BTW, the camera works fine.

Thanks,

Mark.

[rolfk]

Are you trying to run this in 64 Bit LabVIEW by any chance? That won't work as the original library has many 32 bit specialities and changing it to work on 64 bit LabVIEW is quite a bit more than modifying a few Call Library Node configuration details.

[MarkGreally]

Where would be a good place to learn up on how to do this?

[rolfk]

How much C programming do you know? Basically you need to understand how to call all these functions from C, and then also understand how a C compiler is actually working. Insofar it is more you need to know than just writing the C code itself. The C programmer only needs to know the functions he wants to call and usually doesn't have to bother about how many bytes a particular datatype would use and how it is placed in memory exactly.

So if you don't know C programming I would first start to learn that, then go from there. Honestly without a good and profound understanding of C programming itself it's bound to cause you a lot of pain and you will end up with code that after lots of work doesn't crash anymore but only by accident, but still does lots of things that are illegal and will bite you and others using that code at some point in a bad way.

[MarkGreally]

I actually have a few executables I can run in the background and I can call them with system exec. It would be nice for that window called from the exectuable to be displayed in the labview front panel. I doubt this is possible as labview has no control over the file.

[rolfk]

---

@MarkGreally wrote:

I actually have a few executables I can run in the background and I can call them with system exec. It would be nice for that window called from the exectuable to be displayed in the labview front panel. I doubt this is possible as labview has no control over the file.

---

It's possible to do that with child windows but requires quite a few low level WinAPI calls and it is a VERY brittle solution. Windows child windows accross process boundaries can sometimes work and was in Windows 3.1 days quite straightforward since there was no security and process memory isolation. In modern Windows systems each process is completely isolated from each other process and can't just peek and poke into another process. Some of the window messaging has been modified by the Windows developers to do proper marshalling of message data across process bounderies but that is pretty involved and not implemented for every possible message and data combination (and technically not even possible to do fully as the underlaying message system sometimes doesn't have enough context information to do this properly). The effect is that while it sometimes can work for simple integration it usually breaks pretty fast and catastrophally once you do anything more involved in either application. And LabVIEW definitely does internally a lot of very involved things in windows message handling.

I suppose that is why you have in your Edit VI a fixed window name "USBCamera" which is probably the window name to your external application. So in additiona to Windows 64 bit compatibility issues you also have added interprocess windows mssage marshalling troubles to the whole mix. That's definitely asking for trouble.

[Bob_Schor]

At some point, you need to ask how much is your time and effort worth, and what is the value of a fairly simple system that you build using IMAQdx, which maybe other people will be able to understand, use, and maintain/modify, as opposed to a system that you cobble together out of miscellaneous bits and pieces that involve C, C++, C#, B (well, if there's C and C-sharp, why not C-flat, which would be B?).

I'm currently mentoring a junior Biomedical Engineering undergraduate who has a little LabVIEW experience and is working on a project to study flow in the lymphatic system using tracers that fluoresce in the Near-Infrared.  She's picked up IMAQdx pretty quickly, and can rip through a folder of PNG images (since the flow is slow, we take single "time-lapse" images every few seconds rather than a 30 fps video in an AVI file).  We're now working on detecting fluid motion from such images -- IMAQdx lets us concentrate on the science (and, needless to say, the Math) rather than worrying about cameras and interfacing.

Hmm, bad analogy -- I forgot that we already have the Images.  But my colleague also wrote the Image Acquisition system using LabVIEW and IMAQdx, with IMAQdx being by far the simplest part of his code.  [He tends to go crazy with Bells and Whistles, to the point that the poor user is trying to figure out which button to push ...].  Getting the images into the PC was really pretty easy this way ...

Bob Schor

[MarkGreally]

Thanks guys. It was more of a curious question. I have a system that runs in the background that works fine. Bob, as you say "bells and whistles", I'm probably falling into that catagory. The user dosn't really need to see the images all we need is the data from that. If down the line it does become a requirement we could go for IMAQdx. And also, when there is a lot of stuff on the GUI it does make it more complicated so maybe no harm having it run in the background.