Can not find frame grabber in Call Library Function node

[cq2017]

Hi guys,

I am using C++ dll to control a frame grabber. Everything works fine in my C++ applications using the dll in VS2017.

Then I created a VI wrapper using Call Library Function Node to the dll. However, when I try to use the wrapper VI to control the frame grabber, the function inside the dll says there is no connected frame grabber, with no syntax error. It is really strange because it successfully finds the device using exactly the same function in the dll in VS  but in LabVIEW it doesn't.

I wonder if LabVIEW needs additional driver to talk to instruments inside C/C++ dll whose driver is already installed on Windows.

Could anybody help me on this?   

[ikaiser]

Hello cq2017!

Is the same computer? (I assume VS2017 is Visual Studio and not VeriStand, please confirm.) If it works with Visual Studio by calling the DLL, then it should work the same way with LabVIEW. I have some ideas on this:

• How do you call the dll with the Call Library Function node? Can you share your code here (the VI itself, not a screenshot)? And, in case you can share it, also the dll?
• Does the dll need elevated execution rights to be able to find the camera? Say, your VS program / compiled exe is executed with admin rights, whereas you execute LabVIEW with normal, limited user rights?
• What bitness (32/64-bit) does your dll have, what bitness have you configured in your Visual Studio project, and which version of LabVIEW are you using?

Apart from that: Is the dll an original driver dll by the manufacturer of the camera, or did you create it?

[cq2017]

Thanks for the reply ikaiser.

I am afraid I cannot share the vi or the screenshot. However I can answer the questions.

1. Everything works fine in Visual Studio 2017 64bit debug/release and the function/dll itself works correctly in LabVIEW 2017 64bit using Call Library Function node, i.e., I get expected return value and error code using both my own and manufacture's API dll.

2. Though no admin right is needed, I did tried but got  the same response.

4. The frame grabber is a Perkin Elmer Digital XRD-FGE Opto Frame Grabber X64. 

3. Using VS 2017 or its generated exe, I can use the manufacture's finding sensor's function call to find the frame grabber board. The problem is that inside LabVIEW the same function returns that no board can be found.

[ikaiser]

Hello,

As far as I can tell the Perkin Elmer Digital XRD-FGE Opto Frame Grabber X64 is a PCIe device. So there is no TCP/IP or similar involved that the Windows firewall could block.

Without being able to look at your code, it's hard to tell if there is maybe a minor bug in it. Have you tried building a minimal working example (in this case: minimal example, that shows the "no connected frame grabber")? This VI should not have more that the one Call Library Function node and supporting nodes. A typical mistake with Call Library Function is when the dll needs pointers as parameters. Check that you are using the correct size in LabVIEW, that should be 64 bits in your case.

As this minimal working VI would have no other code in it, is it possible for you to share it? In case the names of the dll/function/parameter(s) are confidential you can conceal them by putting random, different names. Of course I understand in case your company has a "no data leaves our network" policy. But in that case troubleshooting will be really tricky.

[cq2017]

Thanks. However the current minimal passes several test cases and get desired response and error codes. The problem for someone else to run the code is that even if the dll is loaded correctly, without the physical hardware the same response indicating frame grabber card is not detected will be received. 

[ikaiser]

However the current minimal passes several test cases and get desired response and error codes.

---

Now THAT is interesting, and is a very important finding. It shows that the dll generally works when called from LabVIEW, and that the problem is either in your code, or your code and the dll interfere.

Have you tried adding pieces of your bigger application to the minimal one until it did not get the desired response anymore? Or is it erratic?

One idea I have is that the dll is not thread safe. What is your Call Function Node (CFN) configured as (this is an example for a thing one can easily spot having your code)? Is it "Run in UI thread" or "Run in any thread"? Test switching to the other, and notice how the color of the CFN changes. Does this change the response you get from the dll in the non-working case?