I have built a tester that controls relays through a USB based pcb (USBMicro). It came with a dll. I have successfully interfaced with the boards and it works fine.
I am also including a multi channel USB based voltmeter (EtherTek). It came with a dll as well and I have an applicaiton that talks to it fine.
The problem is that when I access the relay driver, it causes the voltmeter to quit talking. I can do a hardware reset on the voltmeter via a pushbutton and then it will work again until I call the other dll.
The voltmeter comes with a windows based application that uses the same dll and it is not effected by the relay board calls.
Is there a bug when running multiple dll's? Each time I open the dll for the relay board, I do a close before leaving.
The voltmeter manufacturer just sent me an updated source code to load into the onboard eeprom, to which they added a software reset, but I am having problems getting FLIP to run.
When the windows app runs, it is not going through the dll via labview, so I am wondering if there is an issue with multiple dll's.
This is really looking like a LabView bug. I can call the same dll for the voltmeter from windows and do not get it corrupted when I call the relay board.
I can close down the vi for reading the voltmeter and then open it up again and the communications are re-established. The dll for the voltmeter opens the connection, does the communications, then closes the connection for every dll call.
This is quite unlikely a LabVIEW bug. What is most probably the cause of this, is that both DLLs initialize the same system service or resource on loading for exclusive use. A conclusive proof would be to create a small C application that uses both DLLs.
The solution would be of course to get the manufacturers to modify their DLL to not initialize that resource for their own exclusive use on DLL loading. Another possible solution could be to use dynamic DLL loading in the Call Library Node (CLN). For that you configure the CLN to specify the library path through a parameter on the diagram. Then you execute that CLN each time twice in a loop, the first time with the library path and the second time with an empty path. Caveats are that this is a lot slower since DLL loading and unloading is a rather slow operation. Windows needs complete control of the process for the duration of the DLL loading, to make sure it does not run into race conditions when resolving links to other DLLs and system interfaces and updating its internal bookkeeping records. Also dynamic loading of DLLs in the CLN did not work as advertised in LabVIEW 8.5/8.6/2009 and I'm not sure if it does in 2010.
I was told that it was OK to use 32 bit Labview on a 64 bit machine. I believe this is the root of the problem. I have since installed the 64 bit version, but now the 32 bit dll's do not load. From what I have read, this is not allowed but most of the references are old. Has this restriction changed? One dll is written in masm32 and the other in c.
No! A 64 Bit application can only load 64 Bit DLLs and a 32 Bit application only 32 Bit DLLs.
But I don't think the fact that you are running 32 Bit LabVIEW on a 64 Bit OS is the actual problem. It is more likely an interaction of the two DLLs. Both accessing USB and most likely a similar or same USB device class is a strong hint in this direction. They or at least one of them assumes most likely that they can grab whatever system resource they use and have exclusive control of it. The other DLL doing the same then destroys the link the first has established so that it looses control of the resource.