LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Photometrics/Roper Scientific

Has anybody had any experience building VIs to control Photometrics'
(Roper Scientific) cameras? How easy/difficult was it? Better yet,
does anyone know if there are such VIs available for the downloading?

Thanks,
eric
0 Kudos
Message 1 of 41
(12,259 Views)
Yes, I dit it a few months ago. It is now working perfectly, but I had some problems. The main one was that the "PI Labview VIs" manual from Roper Scientific was quite old, and did not include any reference to my new hardware. I fetched the "Controller Type" id and "Detector Type" id in the Windows registry ! (before I discovered the RSDiag32 program). I had to get also a new PI.lib from Roper Scientific.

Not too difficult as the included examples work well.
0 Kudos
Message 2 of 41
(12,174 Views)
In article <506500000005000000CF9B0000-1027480788000@exchange.ni.com>, "Dominique.Lovy@chiphy.unige.ch" wrote:

> Yes, I dit it a few months ago. It is now working perfectly, but I had
> some problems. The main one was that the "PI Labview VIs" manual from
> Roper Scientific was quite old, and did not include any reference to
> my new hardware. I fetched the "Controller Type" id and "Detector
> Type" id in the Windows registry ! (before I discovered the RSDiag32
> program). I had to get also a new PI.lib from Roper Scientific.
>
> Not too difficult as the included examples work well.

That's good to hear. So how did you do it? Did you use the Call Library
vi to hook into the camera's .dll?

Thanks,
eric
0 Kudos
Message 3 of 41
(12,174 Views)
Yes. Like the examples included.

The interface to the camera is in fact a couple of DLL (pixcm32.dll being the main one), and all the acquisition programs I've seen use these DLL.
So the Vi's have to use the DLL. I don't know any
other way to do it (and I'm quite sure that there is no other way)

The DLL are the same for all the possible cameras and controllers. You have to specify your real hardware in the first calls (an autodetection feature would be nice)

Approximately two dozens of DLL calls are sufficient for simple applications (initialize, get an image, control the temperature of the sensor, the shutter open time,...)

Dom
0 Kudos
Message 4 of 41
(12,175 Views)
Time to bump the five-year-old thread!

I am currently working on the problem of interfacing a Photometrics camera with LabVIEW via PVCAM.  And I have indeed have had some luck with Call Library Function Nodes, so far.  Unfortunately, a lot of the functions have void pointers (and pointers to void pointers!) and I am not completely sure how to deal with them.  Has anyone else been working with PVCAM lately?
0 Kudos
Message 5 of 41
(11,771 Views)

I haven't worked with the PVCAM libraries yet, but I'm interested in doing so.  Did you make any progress?  I am (most likely) willing to do some work on this, although it would take me some time to get up to speed.

Marcus Collins

0 Kudos
Message 6 of 41
(11,708 Views)
While I did make some progress, I'm afraid I never succeeded in making a program that wouldn't cause LabVIEW to crash badly after some use.  I started some other threads about void pointers and MoveBlock that you can probably find by searching.

Fortunately, there are a few alternatives.  There's the Scientific Imaging Toolkit endorsed by Roper Scientific, and apparently this program called SIDX will also give you control of a Photometrics camera via LabVIEW.  Both of these unfortunately are very expensive.

Right now, I am using Micro-Manager which is free and open-source.  While it can't be controlled directly from LabVIEW (it uses C++ classes), I've been able to use some MATLAB script nodes to control it through LabVIEW.  It sounds a bit convoluted, but in the end everything runs transparently.  Of course, you will have to know a bit of MATLAB to get started.

I suppose the ideal would be to have some sort of C "wrapper" code for the Micro-Manager DLL which could then be called from a LabVIEW CLN, but I wouldn't know how to begin to program something like that.
0 Kudos
Message 7 of 41
(11,700 Views)
Hi,

I am trying to do the same thing in Labview on Linux. But what I cant uderstand is how to write the parameters in the CLN node which have datatypes defined only in the header file.
Any help?

Thanks,
Yatin
0 Kudos
Message 8 of 41
(11,269 Views)
Well, good luck with that. I made numerous notes about my attempt:

LabVIEW can automatically create a set of VIs from a DLL such as pvcam32.dll, where each VI will contain a CLN corresponding to one function in the DLL, with the relevant input and outputs. This facility is available through the Tools menu of LabVIEW, under Import -> Shared Library (.dll). This import operation also requires a header (.h) file; to import pvcam32.dll, it is necessary to specify a single, temporary header file made by combining master.h and pvcam.h (in C:\Program Files\Photometrics\PVCAM\sdk\Headers). This file can be easily created by opening pvcam.h in Notepad, pressing CTRL-A and then CTRL-C, followed by opening master.h in Notepad and pressing CTRL-End and then CTRL-V.

This automatic import operation is not without problems, however. Specifically, some of the functions will take arguments of the "void_ptr" type, which LabVIEW may not interpret correctly. In general, a "void_ptr" should be a pointer to an array of unsigned 16-bit integers, although this may change depending on how the camera is configured. LabVIEW also completely fails to interpret the "void_ptr_ptr" type and will replace it with a cluster.

Unfortunately, the automatic import won't help you at all with the parameters. Let's look at this one as an example:

Function: pl_exp_setup_cont()
*/
enum
{ CIRC_NONE, CIRC_OVERWRITE, CIRC_NO_OVERWRITE };

This line indicates that a value of 0 is associated with CIRC_NONE, a value of 1 is associated with CIRC_OVERWRITE, and CIRC_NO_OVERWRITE is associated with a value of 2. Just supply the appropriate integer when calling the function. (Alternatively, you can construct a LabVIEW enum constant manually.)

Another thing you might be confused by is something like
#define PARAM_PREMASK ((CLASS2<<16) + TYPE_UNS16<<24) + 53)

In this case "<<" is the "bitwise shift" operator. You can find the LabVIEW equivalent on the Numeric palette somewhere. Earlier in the header file you'll find something like

#define CLASS2 2 /* Configuration/Setup */
#define TYPE_UNS16 6

So, take the value of 2 and shift it by 16 bits, take the value of 6 and shift it by 24 bits, and add 53 to the sum of those two values to get the number you'll use in functions to access PARAM_PREMASK.

Message Edited by kehander on 06-12-2008 09:30 AM
0 Kudos
Message 9 of 41
(11,263 Views)

That was a quick reply.. Smiley Happy

Thanks for the info. Lets see how much i can use. Neways i'll definitely give it a try. Smiley Wink

Will get back if I face any problems

Thanks again,
Yatin.
0 Kudos
Message 10 of 41
(11,255 Views)