Need help building a DLL with USB Raw communication

[InfiniteNothing]

I've been able to successfully establish communication to a USB instrument using the VISA wizard and the VISA read and write functions. I am trying to essentially repackage the VISA read and write commands into DLL form callable from a system without Labview.  To this end, I've made subVIs that simply call the read and write VISA functions with more or less the same connector diagram. I have to convert the VISA reference to a string to keep the model of the DLL call as standardized as possible. This works fine as VIs but once I compile it and try and use the DLLs, I get no response out.

I suspect the reason for this has to do with each DLL call closing all its references at the end of the call. That is, after the write happens, it closes the windows USB buffer and then when Read runs, there is nothing on the USB buffer. To test that hypothesis, I ran the Write VI and then the Read DLL and I was able to get good results out of the DLL.

Is there a way to accomplish what I am trying to do here?

[RobBoyer]

One quick question: are you trying to avoid needing to install the LabVIEW runtime on the target machines?  If so, I don't believe packaging it in a DLL will accomplish that.  (Correct me if I'm wrong, but I think LabVIEW created DLLs still have dependencies on the LabVIEW runtime.)

In general though, I agree with your suspicion as to why it isn't working.  One test you could perform to clarify the situation would be to added another VISA write and DLL read in line after the second form in your attached JPG.  If the resource is hosed up after your DLL read also, I agree, it would point to the DLL calls causing the resource to hang.  Perhaps the process of translating the VISA resource name from a string to the actual resource object causes the VISA session to be tied to the scope of the DLL function call (hence automatically releasing when the call is completed)?  If so, maybe passing the actual VISA resource name would help.  The VISA resource is really nothing more than a pointer to an object (a LVRefNum).  From the perspective of language independence, I think that probably amounts to a 32-bit integer.

Also, perhaps you could just avoid building this level of granularity into the DLLs?  The idea of creating a DLL is to abstract away some complex task.  I'm not sure what benefit you get of creating DLLs out of such basic functions.

Anyway, good luck.