Passing a VISA resource to a DLL created in C or LabVIEW

[Marc_A]

So if I kept the call library node parameter as adapt to type so that the LabVIEW DLL works, and changed the C code so it calls viOpenDefaultRM() and then viOpen() and gets a session, it should work?

I was trying to avoid this as it seems inefficient to open and close the session in every function.

[BTC_Admin]

Are you able to post at least a snippet or code for a subVI which is included in your LabVIEW DLL and the function prototype in Library Call for the same when you're trying to call it?

You really shouldn't have to open/close sessions in every function - you're correct, that would be a bad design.  We had developed some DLL that utilized VISA communications ( for CANbus) in LabWINDOWS/CVI and almost a copy of it developed in LabVIEW, both of them were based on a DLL from a third party design (for a Microchip PIC that had CAN in it).  That original C-based third-party DLL was made using non-LabWindows/CVI/non-LabVIEW IDE. I don't recall encountering any such issues even if we loaded any of them from the same subVI, although also I don't recall there being any U32 VISA reference numbers that needed to be passed.

-DP

(Have you looked at this?)

[rolfk]

---

@Marc_A wrote:

So if I kept the call library node parameter as adapt to type so that the LabVIEW DLL works, and changed the C code so it calls viOpenDefaultRM() and then viOpen() and gets a session, it should work?

I was trying to avoid this as it seems inefficient to open and close the session in every function.

---

No! Adapt to type will pass a 32 bit integer that references LabVIEW private data and only makes sense within the LabVIEW process that created the RefNum and only to API functions that you have normally no access to. You would have to pass it as string.

And DP didn't encounter any issues since he did not want to use LabVIEW DLLs AND C generated DLLs from within LabVIEW in a way that their interface is identical. The LabVIEW VISA nodes in the LabVIEW DLL need a VISA refnum. The VISA calls in a C DLL need a ViSession. You can let LabVIEW pass the inherent ViSession in the VISA refnum to a C DLL by configuring the parameter as integer. But if you do that you can not easily recover the VISA refnum from that inside the LabVIEW DLL to be passed to the VISA VIs.

There is one function in LabVIEW.exe (and lvrt.dll) that could maybe help. It is called VCookieToSesn(). It does basically what the Call Library Node does implicitedly when you connect a VISA Refnum to a Call Library Node configured as integer. If you configure the Call Library Node to adapt to type, place this function in the C DLL to convert the passed in LVRefNum to a ViSession and pass it to the VISA functions, then you could keep the DLL interface identical for both the C and the LabVIEW DLL. But import of a LabVIEW manager function (you also need to link in labview.lib from the cintools directory into you C DLL) means that your C DLL only is executable if it was called from within a LabVIEW context (LabVIEW IDE or LabVIEW executable).

The prototyp of this function is MgErr VCookieToSesn(LVRefNum refnum, ViSession *sesn);

[Marc_A]

I don't want to have to rely on LabVIEW for this, as it's for customers that will be using a built LabVIEW application on a system provided by us. They may do driver development on another system entirely, so I'd like this as standalone as possible.

So basically there is no way to do what I want. My other thought now is to pass both the refnum and ViSession integer to every function call. It's not ideal, but I'd rather do that then have to figure out what type of DLL it is every time I call it.

[rolfk]

Your approach to pass the LabVIEW refnum AND the ViSession integer to the DLL is in fact the most pragmatic approach. Each DLL grabs then whatever suits its needs better.

[Marc_A]

I actually just decided to write my own drivers in C so that the templates can be made simply and customers can just alter the command that is sent. This way I only have to worry about one type of DLL. If I hit a snag doing this, I'll fall back to using the two input idea.

Thanks for your help.

[BTC_Admin]

This maybe too late, but take a look at this thread, That gentleman is trying to do something related and a few minutes ago I posted a project there which shows how it could be done.

Hope that helps...

-DP

[DavidBoyd]

May be too late, but the attached snippet contains a primitive which might be applicable.  I believe it is undocumented/unsupported - use at your own risk.

Mostly I'm just curious if Rolf has seen this and knows more about it.

Dave

[rolfk]

I've seen it but am not sure about its implications as in which LabVIEW version and all this is supported. But in fact it is superflous in the sense that a Call Library Node parameter configured as integer will in fact do this conversion implicitedly anyways when a VISA refnum (and also some other refnums) are wired to it. And I'm pretty sure that this implicit conversion of the Call Library Node works at least back to LabVIEW 7.1 (and probably even earlier) so I never investigated this node further.

[Marc_A]

I did find that when I was looking around, but it's the opposite of what I need. My DLL takes a VISA session, so in the LabVIEW DLL I would need to convert from session to refnum. I couldn't find a way to do that.

I remade the drivers I have in C++ anyway, and It'll make things easier as I won't have to worry about recompiling them when upgrading LabVIEW.