Can't open an engine's USB port

[siiilverrr]

I have an engine that communicates via a virtual USB com-port and the 32-bit "moto_dll2.dll". I have Windows 7 64 bit, labview 18 32bit and "moto_dll2.dll" that have been successfully transformed in VIs, but the function "Enumdevice.vi", which considers the device, cannot find any of this. The OS installed the CP201x Silicon Labs driver, and even Silabs VI work well! The CP201x Get Num Device.vi VI finds the device! Also, the problem is not "moto_dll2.dll", because my colleague had access to C # and C ++. I tried to do something but nothing works 😞

Can someone help me solve this problem?

Thanks everyone!

[rolfk]

You need to provide a lot more structured information in order to let others help you. Right now you give a lot of little pieces but no really relevant information that gives the full picture.

Where is the moto.dll.2.dll from? Who did the VI wrappers for that DLL? Is this person really knowledgeable about creating such a thing or is all he/she did to start the import library wizard to generate a VI library for the DLL? Why do you know that the moto_dll2.dll isn't the problem somehow?

Where is the VI wrapper library to access the DLL? Where is the header file for that DLL?

[siiilverrr]

moto_dll2.dll from a russian engine manufacture. I downloaded this from their official website (look at "Moto_dll2_SDK.7z"). So, I did VI wrappers for that DLL, it wasn't difficult for me, because I did it many times before(import -> shared library -> ....and so on), or there is some issues with import dll? I did't meet that before...

My colleague imported moto_dll2.dll to MS VS by C# and C++, tried to use examples in "Moto_dll2_SDK.7z" and an engine worked fine (responses were received). 

[rolfk]

So AddParamToStream() you can't call from LabVIEW but you probably already found that.

You did first call InitParser() like in the documentation is mentioned? Wht code did it return?

Where did you put all the other DLLs in the lib folder? Your college probably put them all inside the build folder where his exe was build to and everything was of course smoothie. But unless moto_dll2.dll does some custom trickery in trying to explicitedly load these DLLs on its own from the same directory it is in, it won't find them in LabVIEW like that. While the Call Library Node can tell LabVEW where to load the direct DLL from, it's not the calling applications job to load the DLL dependencies of a DLL (since it can not possibly know of what the DLL programmer all needs to have loaded).

It may be necessary to put those DLLs in a location where Windows can find them when the DLL tries to load them by name.

[siiilverrr]

Yes, I cannot, and I do not need it.

Yes! I called it, and this function always returns the code “1”, which means that the library is initialized. After InitParser (), I call EnumDevices (), and it returns “0” - the device was not found.

I put all the files from the "lib" folder into a shared folder where moto_dll2, all VI, main VI and other files are stored. As you can see, the fact is that InitParser () returns the OK code, the WriteParam () and other functions return the code “-600” (ERR_INVALID_INVERTER is the wrong port number), so we can conclude that the dll works well, but USB does not can find the device.

And the last: most of the time when I use EnumDevices () LabVIEW returns an error when I close it, can this error be due to communication problems (I added a screenshot)?

[rolfk · Accepted solution]

Putting those DLLs in that folder will not allow Windows to find them. I have no idea if your moto DLL is smart enough to explicitedly try to load those DLLs from the same directory it is in. That's doable if the DLL programmer knows his stuff, but in 99.99% of the cases it's not done like that and the programmer just trusts that Windows will find the DLL when asked to load it.

So you can try to copy them all into the LabVIEW.exe directory for a test. Does it work now? Then the DLL is not smart enough and you have a bit of a problem. Windows only searches in specific locations for DLLs when asked to load them by name only. That search order has been discussed umtien times already here on the forum as well as on the internet. If this is the case you'll have to copy the DLLs in one of these locations:

- Your exes directory (simple and the best solution for a LabVIEW build application, an unmainataineable disaster for the LabVIEW development environment).

- The Windows system directory (you shouldn't put application private files there ever!)

- The Windows directory (slightly worse than the previous and you should not put application private files here ever!)

- Some directory on your harddisk and adding that directory location to the PATH environment variable (usually the best location for development in LabVIEW) 

[siiilverrr]

I put all these file stuff to labview.exe directory and dll started to work, as you recommended! I cant believe why that god damn dll programmer built so problematic library. I spent almost a week to solve that problem, and it was so easy.

Anyway, thank you so much for your help!