LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Camera Issue

Here's the camera issue in short.

If you check \\server\nistsoftware\LV Camera Interfaces\Olympus Software
there is a testing VI. You must have the Olympus 3.2 SDK installed, the
registry key added (see manual p14), and the camera in PC control mode (also
see manual p14).

Everything works fine for reading the number of remaining pictures, erasing
pictures, capturing a picture, etc. You want to do a "Download Test" in that
VI. It passes a 1-D array to getPicture(). Check the variant output, which
is the exact same data that was input. My current theory is that LV copies
the array instead of passing a pointer, since there was a lot of related
discussion on news://newsgroups.ni.com/comp.lang.labview

I am stalled on talking to the SDK guy at Olympus (Chris Ke
mmer, corporate
offices) since he's away from his desk.

-joey
0 Kudos
Message 1 of 4
(2,964 Views)
Whoops I guess that path didn't come out correctly I cut and paste the local
one instead.

But the point still stands, is there any way to check if Labview is perhaps
not passing a pointer as expected?

-joey

"Joey Oravec" wrote in message
news:3e25b77c@newsgroups....
> Here's the camera issue in short.
>
> If you check \\server\nistsoftware\LV Camera Interfaces\Olympus Software
> there is a testing VI. You must have the Olympus 3.2 SDK installed, the
> registry key added (see manual p14), and the camera in PC control mode
(also
> see manual p14).
>
> Everything works fine for reading the number of remaining pictures,
erasing
> pictures, capturing a picture, etc. You want to do a "Download Test" in
that
> VI. It passes a 1-D array to get
Picture(). Check the variant output, which
> is the exact same data that was input. My current theory is that LV copies
> the array instead of passing a pointer, since there was a lot of related
> discussion on news://newsgroups.ni.com/comp.lang.labview
>
> I am stalled on talking to the SDK guy at Olympus (Chris Kemmer, corporate
> offices) since he's away from his desk.
>
> -joey
>
>
0 Kudos
Message 2 of 4
(2,964 Views)
I think that your best bet would be to create a wrapper DLL. I don't think that LabVIEW can handle this type of data. Here is one possibility. In your.c file, pass in the large array. Then, go into LabVIEW's structure for the Array Handle and return the address of that array. You can wire thisreturn value to your ActiveX call and I'm thinking this would solve it.
J.R. Allen
0 Kudos
Message 3 of 4
(2,964 Views)
There isn't a direct way to handle pointers in LabVIEW. The easiest way to handle this situation would be to develop a dll that you could call through a Call Library Function Node. You could pass the array into the node that will call a DLL that you need to write. In the DLL you need to get into the LabVIEW structure for the Array Handle and return a value that is the address of that array. You could then pass this to your activeX call.
0 Kudos
Message 4 of 4
(2,964 Views)