Call Function Library Node used to control external hardware??

[Scandia.828]

I'm currently trying to figure out how a VI sent as a software package from a company is trying to communicate with the company's camera. We have an Andor Zyla sCMOS camera that came with a software development kit (SDK); in this kit there were controls and functions that LabView could utilize to interface with the camera. They also included a couple of examples VI's that show what the SDK can do with the camera. Well, they're examples aren't working very well, and I think it's because the VI isn't getting the right handle for the camera. There's a subVI that does this in the program, but when I go into the block diagram to see where the subVI is looking for the handle, there's really only a call function library node doing the work, and that's about it. I expected to see some sort of VISA reference or something that was communicating with the camera, but there isn't one. In fact, nowhere in the larger VI is there any VISA, GPIB, DAQ anything that i would normally expect would be utilized for interfacing hardware.

I'm wondering if it's somehow using the Library Node to communicate with the camera, but from what i read about it that's not what it does. Can someone possibly enlighten me as to what might be going on?

Also, I'm using LabView 2013 on Windows 7.

Thanks!

[nathand]

Yes, it's quite possible that the communication is handled through a DLL. Many manufacturers provide a DLL that can be used with multiple programming environments, and then add a LabVIEW VI wrapper around the DLL calls when they need to provide a LabVIEW interface. Even the NI DAQ hardware does this - take a look at DAQmx Read, for example.

[Dennis_Knutson]

All communication to hardware on a Windows pc will be using a dll - gpib, daq, keyboard, mice, Ethernet, video, etc so I don't understand why you are surprised by the use of a call library function node. The actual call to the dll may be hidden but it is still there. There is lower level code that is in the dll but you don't need to know about that unless you write kernel level drivers

You should contact the vendor about your issues. You have not provided any details here and it would be very difficult for someone to debug without your hardware.

[Scandia.828]

I see, I was unfamiliar with exactly how things like visa and daq actually communicate with hardware. Thanks for informing me.

I've been trying to contact the vendor, but apparantly 4 emails and a couple phone calls don't do too much 😞 Being that it's their camera, their computer and their software, I'd assume they'd want to help, but oh well, I'll keep trying.

[skress1]

Hi,

I'm with the Andor support team and I'm sorry to hear that you've had difficulty getting answers to your questions.  I'd be happy to help work through any issues you're running into with our SDK.

You can email me at us_productsupport@andor.com.

[billko]

If you have their SDK you should be able to generate a whole library of calls automatically.

options --> import --> shared library (.dll)...

[rolfk]

---

@billko wrote:

If you have their SDK you should be able to generate a whole library of calls automatically.

options --> import --> shared library (.dll)...

---

Camera interraces are usually not that trivial. They require at least some modifications to the LabVIEW VIs afterwards to provide the necessary data buffers for the functions that retrieve the image data and possibly other data. And more often then not they require special code to deal with asynchronous buffers between API functions. Last but not least you probably need to convert the raw data of those buffers into some image format that one can use inside LabVIEW.

[billko]

---

@rolfk wrote:

---

@billko wrote:

If you have their SDK you should be able to generate a whole library of calls automatically.

options --> import --> shared library (.dll)...

---

Camera interraces are usually not that trivial. They require at least some modifications to the LabVIEW VIs afterwards to provide the necessary data buffers for the functions that retrieve the image data and possibly other data. And more often then not they require special code to deal with asynchronous buffers between API functions. Last but not least you probably need to convert the raw data of those buffers into some image format that one can use inside LabVIEW.

---

Thank you for the info - I never would've guessed!  You are truly the guru of all things testing and instrumentation.  Truly.  I always pay close attention to your posts because they are really relevant to what I do.  🙂

[Scandia.828]

Wow, thank you for all the great input! Been away for a while and I come back to to some great stuff.

rolfk, definitely starting to realize how complex camera interfaces can be. There's a VI that has been used to operate a previous camera that i've been trying to adapt to work with this camera, and it's a bit of a monster. The VI not only takes and saves images, but it also has a background subtraction function built in that uses a MATLAB command to perform the subtraction.

Anyways, thanks again.