cancel
Showing results for 
Search instead for 
Did you mean: 
Reply

Call Library Function worked in 5.1, but not in 2016

Solved!
Go to solution
Highlighted

Call Library Function worked in 5.1, but not in 2016

Hi! Back in 2009 I learned a tiny little bit of LV 5.1 and wrote 6 very simple VIs to read and write strings to 3 different hardware control DLLs:

  1. Write string to pipci.dll (library call, diagram, and panel)
  2. Read string from pipci.dll (library call, diagram, and panel)
  3. Write string to dacq.dll (library call, diagram, and panel)
  4. Read string from dacq.dll (library call, diagram, and panel)
  5. Write string to PiPatAuto.dll (library call, diagram, and panel)
  6. Read string from PiPatAuto.dll (library call, diagram, and panel)

The exported functions from the 3 DLLs are virtually identical. I write strings to the InputMsg of each DLL with a CString pointer, and it returns a BOOL success/fail. I pass a CString pointer and NumBytes into the OutputMsg, and it fills my string buffer and returns a BOOL success/fail.

 

All 6 VIs worked fine in 5.1, but when I attempted to re-created them in LV 2016, the PipatAuto library calls don't work. Regardless of how I set up the call, they return 0/FALSE, and the call doesn't actually do anything.

 

With the other 4 library calls to the other 2 DLLs, I can Send a string (such as "ID" or "STATUS"), and the Success indicator turns from 0 to 1. I can then Read a string, and I get the message from the DLL that I expect (such as "READY" or "No hardware found"), and the Success indicator turns from 0 to 1.

 

But with the calls to PiPatAuto.dll, neither Send nor Receive works. The Success/Fail indicator stays at 0/False, and there's no indication that anything has happened. 

 

One possible difference with PiPatAuto.dll is that it's actually a wrapper DLL that calls the corresponding Automation functions in our MFC-based application (hence the name), whereas the other two DLLs are just faceless DLLs that directly export those Input and Output functions. Do I need to do anything different in this case? My C++ programmer is away on personal leave for another week.

 

Thanks!

 

The exported functions are declared, thus:

#ifndef PIPATAUTOEXP_H
#define PIPATAUTOEXP_H


extern "C" BOOL PiPatInputMsg(char* pMsg);
extern "C" BOOL PiPatOutputMsg(char* pMsg,int nMaxBytes);
extern "C" BOOL StartUpPiPat();
extern "C" BOOL ShutDownPiPat();

#endif

 

0 Kudos
Message 1 of 3
(121 Views)
Solution
Accepted by topic author TheWaterbug
08-11-2017 07:03 PM

Re: Call Library Function worked in 5.1, but not in 2016

Are you sure that your MFC application that PiPatAuto.dll connects to, is properly installed and registered on your computer. From the name of the DLL it probably interfaces to the OLE Automation interface library (possibly Active X interface but could be also just a basic COM interface) and for that to work, the Automation server component needs to be installed properly on your system. It's unfortunate that your API only returns success or fail status without any further indication about what the problem might be if it failed. That would help when investigating such errors. 

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Message 2 of 3
(63 Views)

Re: Call Library Function worked in 5.1, but not in 2016

Ah, I think you're right. I just installed ancient LV 5.1 on this machine, and it also fails the same way.

 

I ran the 5.1 VIs on a system with a slightly older build of our software, and it works. So it's something recently broken in our software, and it appears to be independent of the LabVIEW version.

0 Kudos
Message 3 of 3
(37 Views)