LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Running dll file on RT target

You need to add the DLL to your project - drag it from the 'dependencies' to your project (or add it manually) and then you should be able to add it to 'always included'. In this case, you would specify the dll as 'ali.dll' in the call library function node.

Another thing you can try - change the library function node to 'specify path on block diagram' and then wire the path into the library function node - you can also do a 'check file exists' on that path to confirm that the file is in the expected location on the RT target. If the file exists but still does not load - then I think there is a compatibility problem with the DLL.


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 11 of 57
(2,473 Views)

Hi Sam,

 

I have got the same issue. I am now trying to deploy my code containing DLL to RT target. I can build and deploy my code, but the code in RT does not work. Do you have any advice for me ? Thanks in advance.

 

Zhi.

0 Kudos
Message 12 of 57
(1,901 Views)

What DLL is it? Did you create it yourself and if you did with which version of Visual C? What is your RT target?

Rolf Kalbermatter
My Blog
0 Kudos
Message 13 of 57
(1,895 Views)

Rolf it seems this thread has run cold but I would like to fire it up again as I am having the same problem that I am going to summarize here:

1) DLL created using Visual Studio 2010, 32bit and it reports no errors on the DLL checker.  Trying to run it on PXIe-8840.

2) It is as simple as can be, only one exported function that only returns a constant.

3) It works like a dream on Windows.

4) I ftp'ed it to the exact same file location as on windows, I use the 'Check That File or Folder Exists.vi' to check that the path that is wired to the Call Library Function Node 'path in' control.  It returns true.  If true, the DLL function is called.

5) The call returns error 7.  Why?

So it can't be that it doesn't find the DLL, maybe it doesn't find the function? Is there any other way to probe this problem in more detail?  Is the garbled function name 'double ?DummyFunction@@YANH@Z(int32_t arg1);' a clue? Where does this garbled name come from?

I could post the .dll and .h file?

O forgot to say I am running it from the LabVIEW environment targeting the PXI via ethernet.

0 Kudos
Message 14 of 57
(1,809 Views)

Two things to check:

 

1) You did not compile a debug version of the DLL?

2) You installed the VisualC 2010 Runtime Library Support onto your PXI target?

 

To 1) there is no redistributable debug version of the VisualC runtime but a debug DLL tries to load that one rather than the normal runtime version.

Rolf Kalbermatter
My Blog
0 Kudos
Message 15 of 57
(1,801 Views)

Just to make sure: your PXIe is running Windows 7 or 10 right?

0 Kudos
Message 16 of 57
(1,797 Views)

Thanks for the speedy replies.  To the questions: I built Release and I did install the VisualC 2010 runtime support.  But I will double check that tomorrow.  I am running RT on the PXI and windows 7 on my development PC.  LabVIEW 2016.  

I actually realised that the thread referenced above Loading a DLL on RT was my own question posted way back in 2010.  We then solved it by using VS2003.  Sorry it has been a long time so I forgot about this yesterday when I had to update the DLL 8 years later.  But now I don't know where to get a copy of VS2003 so making it work with 2010 would be nice.  My old compiled DLL works, same cpp and h file.  So I am suspecting a compiler compatibility issue of course, but I was hoping 2010 would work.  

Tomorrow I will confirm the compiler settings, then hunt for a 2008 or 2003 compiler to see if it solves it.  I wonder if there is a web-based 2003 or 2008 compiler service somewhere.

0 Kudos
Message 17 of 57
(1,792 Views)

So let me try to understand it. 

You have a new PXIe 8840 controller running NI RT, and you want an old Windows dll to work on than PXIe? 

The PXIe comes with 3 OS options, Windows 7, 10 or NI Linux RT. Only the first 2 options can run your windows dll. 

 

Back in 2010, I think your controller was running either Phar Lap ETS or vxworks, and that is why your dll was working. 

You have to be sure what OS your PXIe is running before you start doing anything else. 

Making a windows dll for a Linux OS does not make any sense.

0 Kudos
Message 18 of 57
(1,784 Views)

You understand wrong. The PXI runs pharlap (supporting win32 dll's in a limited way) not Linux.

See http://www.ni.com/product-documentation/53636/en/

Or am I wrong?

 

0 Kudos
Message 19 of 57
(1,780 Views)

I'm not aware that NI has released an NI Linux RT version for the PXI controllers. It might be available but never heard of it and if it would be available it won't support LabVIEW versions that were out before this got released, so nothing below 2018 could possibly support it.

Rolf Kalbermatter
My Blog
0 Kudos
Message 20 of 57
(1,779 Views)