connectionID lvrefnum in dll

[kbarrett_72]

I have been looking for information about the LVRefNum data type, and how to translate them for DLL usage.  I have a network setup using UDP.  The protocol we have implemented we want to allow other users to interface with, hence the DLL for C++ and VB users.  I have created four basic VIs (functions): open, read, write, close.  My issue is the connectionID labview makes from the UDP open.  I want to pass this ID back to the C guys so they can handle the polling to the other functions as needed.  When I create the DLL, it tells me that the connectionID is a LVRefNum type.  From what I read on the other threads about file, visa, activeX refnums, etc., this is a real headache.  Some people say to type cast it to a U32, and that should work fine; others say these refnums are very specific and type casting doesn't work.  So what is the deal?  I would like a very clear answer what to do for my situation.  My goal is the have this connectionID as an output from the open function, and as an input to the read, write, and close.

[NathanK · Accepted solution]

The connectionID for the TCP and UDP primitives is an uInt32 identifier. You should be safe casting it to an uInt32 to pass in and out of the dll. Just make sure the callers know how limited that id is- it won't have any meaning in any other instance of LabVIEW and it won't persist after the connection is closed or LV is restarted. If you handle the invalid argument error (code 1) in your G code then you should be safe from callers misusing it.

Nathan

Message Edited by NathanK on 08-20-2009 11:57 AM

[rolfk]

Well, the refnum itself is an uInt32, but it is a LabVIEW private entity. If you want to abuse the refnum for your own library, that creates and returns it, uses and finally destroys it then you can do so but you should consider that a user of your library could try to connect it to LabVIEW UDP functions and that would certainly fail. A better approach for that is to use a datalog file refnum where you have put a unique enum in with one value consisting of an identifier for your library. This refnum will only be wireable to itself and not other LabVIEW refnums so you avoid that problem.

If however you want to use LabVIEW functions to generate the UDP refnum and then pass it to your C library you can not do that. The LabVIEW refnum is a LabVIEW private entity that has no meaning for other functions than the LabVIEW functions that operate on it. You can however retrieve the underlaying platform handle from a VALID network refnum by using the function invi.lib\Utility\tcp.llb\UDP Get Raw Net Object.vi and vi.lib\Utility\tcp.llb\TCP Get Raw Net Object.vi for the respective refnum type. This will return the socket handle that you can pass directly to Winsock functions on Windows, and Berkeley socket functions on other platforms.

Rolf Kalbermatter

[kbarrett_72]

Thanks for the help.  It seems to be working simply by type casting the value back-and-forth from a U32 to the udp lvrefnum type.  I think NI would help everyone by making a concise document about all the different data types and what is the best method to make them available to other languages.  Like I said, searching their site, the info appears very fragmented with nothing in stone.  Well, this a general statement about making Labview built DLLs overall, lots of people talking about it, but no formal document from NI.  Anyway, thanks for the help.

[rolfk]

---

kbarrett_72 wrote:

I think NI would help everyone by making a concise document about all the different data types and what is the best method to make them available to other languages.  Like I said, searching their site, the info appears very fragmented with nothing in stone.  Well, this a general statement about making Labview built DLLs overall, lots of people talking about it, but no formal document from NI.  Anyway, thanks for the help.

---

You are misunderstanding something here. The document you are asking for exists and is installed on your hardddisk when you install LabVIEW. It is called online reference manual. Check out your Help menu and then "Search the LabVIEW Help". In there you have a "Fundamentals->Calling Code in Text based Languages" section that tells you most general things about how to do that and what can come around the corner when doing so. Then there is "Connectivity VIs and Functions->Libraries & Executables VIs and Functions" about what functions you can use in your external code to interface back to LabVIEW. Then there is "Fundamentals->How LabVIEW stores Data in Memory", which explains almost any data type you can have in LabVIEW.

Yes it is not exactly concise, but your request for a concise manual and one that contains just about anything about LabVIEW's representation of data in memory and interfacing to external code are contradicting requirements pur sangue.

Last but not least LabVIEW can use DLLs but it is certainly not the authority to tell you about how to create them. For that you do need some good C understanding (something LabVIEW tries to help successfully for about 98% of its users not to have to have) and also a C compiler and it is really the task of the documentation for that compiler to tell you all and everything about creating DLLs (which that documentation admittedly never does) because many things can and do change for different compilers and versions thereof. 

And now an extra warning. Those network refnums were not made to be used for what you do. They work for your use case but NI is not promoting nor supporting that use case and there is always a chance that they will change the implementation of refnums at some point so that what you are doing now may not work in a future version of LabVIEW.

Rolf Kalbermatter

Message Edited by rolfk on 08-21-2009 09:12 AM

Message Edited by rolfk on 08-21-2009 09:14 AM