DLL call in sub Vl doesn't work when the sub VI is called from within event structure

[rolfk]

---

@MaSta wrote:

Bob, your intention to help in honor, but criticism doesn't help. It's sometimes not easy to visualize a problem. At first I didn't even think it could be the COM port that the DLL uses to open a connection to my hardware. That's why my description is simple and general.

A colleague had the idea to check out if something's wrong with the COM port and so we tried several things, still wondering what's going on. We saw the effect, but had no clue yet what it was caused by. The rest is explained above.   

---

In order for the property node to access the VISA resource to query its property value, LabVIEW has to implicitly open the VISA refnum which also opens the underlying port. And it doesn't automatically close that port afterwards as that would be a major performance problem if the port is continuously opened and closed.

Windows and most other sane OSes consider hardware ports a non sharable resource. So if it is opened by LabVIEW through NI VISA, it can't be opened by your DLL again. There is however a simple fix for this. If you want the port closed you can always explicitly call VISA Close on that resource!

In that context there is nothing wrong with NI VISA in this and most other respects. There is however something to be said about your DLL to simply failing silently rather than returning some meaningful error code such as what VISA does: Error 0xBFFF0072; "The resource is valid but can't be accessed at this time".

[semguigui]

Dear all,

I’m currently experiencing a very similar problem in one of my VIs. I’m quite beginner at controlling instruments with Labview and I don’t really understand how this VISA stuff’s work and what are the good rules to apply when dealing with it.

But at the moment, I have a project, with a main VI controlling a Hamamatsu camera with their API and their LAbview library, that essentially performs DLL calls. The same main VI also controls motors from thorlabs that are driven with VISA subvis that read and write ASCII commands to the motors controller trough a USB connection. The Main VI architecture is message producer-consumer state machine, with a separate consumer loop for each instrument.

Everything was perfectly working on a computer where I developed it, but then I had to run it on another computer (same Labview2019 and same Windows7 versions), plugged in the same USB cable from the same motors, the only difference being that I use another camera model with another frame grabber board on this computer (but the API controls all the cameras of the company). And THERE,  the DLL calls from the Hamamtsu API don’t work anymore. After I googled the problem and felt on this forum topic, I simply drew a “deactivated diagram structure” (don’t know the exact names, I’m translating from a French version of LV, sorry) around the whole message consumer loop that uses VISA (for the motors), and everything worked again with the DLL calls (for the camera). This is very repeatable : VISA loop activated= DLL calls not working and vice versa.

So it looks like the same than in the first post here, except that in my case, the cameras don’t even use the VISA functions, which are only for the motors. But if I use them, the DLL calls for the camera API bug.

(Sorry if I don’t provide a code sample but it would be a whole job to write a working one that demonstrate this and the complete project is big and anyway won’t work without the hardware…)

I don’t have a precise question, but is there “basic rules” with VISA I ignore?

For instance : should I systematically open a session before and close it after each time I interact with the motors? Should I take care of never having a VISA session open when performing any DLL call (sounds weird)?

Best

[rolfk]

How do you know that the camera interface doesn't somehow use VISA internally? It's a possibility inside those DLLs.

Without seeing those actual drivers and more detailed specifications it is hard to say anything conclusive. I use VISA a lot and in conjunction with all kinds of other drivers and haven't really seen such behaviour. As long as that camera driver doesn't somehow try to use VISA (or the OS COMM API directly) I really don't see an obvious reason why they should influence each other even in the slightest way.

[semguigui]

Thanks a lot for the answer,

Yes we can suspect it, the DLL could use internally VISA, I just didn't know if it was possible even in theory. But it makes sense. 

So if we suppose it is the case, what are the possible workarounds?  1- Calling hamamatsu explaining the problem and wait their solution. 2- what could be the nature of the conflict? Does it mean they both try to access the same VISA "thing"? (what could be "thing"  exactly : address? session? ...)