About LabVIEW DLL

[Youssef Menjour]

Hello LabVIEW community,

 

Is there a documentation about LabVIEW DLL functions. 

We would like to have a global view at our team in order to explore possibilities of functions (Maybe another topic already spoke about).

Thanks for your help

[dadreamer]

You can find the information about public Manager Functions freely available on NI website. Also read this Using External Code in LabVIEW very useful (but kind of outdated these days) manual. But note as well that LabVIEW exports a whole bunch of totally unsupported internal functions, which are not intended for any public/production use-cases. Of course, you may figure out how they work and even try to use them in your programs, but do that at your own risks and don't let those projects out of your lab.

[ShaunR]

There's not much. Some useful functions are documented (Moveblock, for example)

There is a file (extcode.h) which has many of the function prototypes which is located in the cintools directory. That and tribal knowledge about C and LabVIEW equivalence is usually what people use. Rolf knows a lot (I mean everything) about the underlying, opaque, structures used by LabVIEW but for most of the functions, C knowledge and extcode.h is usually all we have.

[hooovahh]

In addition to what others have said, these undocumented functions are undocumented for a reason.  NI doesn't want to support developers calling these functions directly, they might only work in small use cases, and the functions are subject to change.  Most obviously don't change, and NI themselves would need to update the places they call a function, if for some reason the prototypes for the function were ever changed. 

So when NI does call one of these functions from a VI they will password protect the VI, to discourage developers from calling it directly.  They'd rather you call the VI they provide (if there is one), and in future versions of LabVIEW they can change this VI's connector pane to force a broken VI, or just update their own calling of the VI to use the new prototype.  If you do learn some useful function call, please do share it with the community.  Members of LAVA are generally familiar with the undocumented, and unsupported nature of these types of things.  But they can of course have value, such as Moveblock.

[Rolf Kalbermatter]

As daddreamer pointed out, quite a bit of those functions are actually documented and always have been. The first multiplatform version of LabVIEW shipped with about 15 cm of printed manuals and reached at its top probably 25 cm. One of the many manuals was called the Code Interface Reference Manual. And while the name might have seemed to only be useful in Code Interface Nodes, those functions were always also available in shared libraries too since LabVIEW added official support for calling them. The information in that manual is for most of it also contained in daddreamers link, without the CIN specifics, which are nowadays useless and really have no advantage to shared libraries since about LabVIEW 7.1 but many disadvantages (and the 64-bit versions of LabVIEW do not support them anymore. Yes I'm aware that someone tried to hack them anyways into LabVIEW 64-bit and was partially successful. But it's an exercise in vain as it really has no advantages whatsoever to shared libraries).

This is the Code Interface Reference Manual from around LabVIEW 3.1 (Release September 1994). It is 16mm thick and there were about 6 or 7 other manuals like that, some of them more than double as thick than this one. Lot's and lots of trees being cut down for all those LabVIEW manuals!  It's for the most part the same as is also in daddreamers link, but there the CIN part is removed and few extra functions are documented that were added since then

Some of the undocumented functions could be useful sometimes but being undocumented, it is a bit of a problem as they could change at anytime or completely disappear, which has happened to many of them over the course of LabVIEW development. Some were exported in the past for the compiler to be able to create code to access them directly but are useless to be called from your own external code as you lack access to internal data that needs to be passed to those functions to be useful. Some are still there as a placeholder but simply return a notImplemented error as they were moved to other parts of LabVIEW and only the export remained to make external code that depended on them in the past not load up broken but instead return a runtime error. CINs that didn't load really could throw LabVIEW into a fit.

There are various additional managers to the documented Memory, File and Support manager functions in that manual but most are not really helpful. Things I have experimented with in that past and I would have liked to have more official access too, were the MagicCookie handler (all LabVIEW refnums are under the hood MagicCookies), UserDataSession (a more functional wrapper around MagicCookies), (which with the help of something called ObjectManager allows to add special crafted shared libraries through a descriptive text file, directly into the LabVIEW refnum system and access the shared library functions through property and method nodes), Thread, Mutex and Event manager (which basically offers a common interface to the underlying platform threads, mutexes and events), and it even has a Window manager, which abstracts the underlying OS windows into its own window API. But that Window manager is for modern requirements with multi monitor virtual desktops a bit arcane and one of the reasons that LabVIEW isn't that great on such setups. But it is very involved and hairy in some parts to make the various windowing systems such as Mac Quickdraw, Mac Cocoa, Windows GDI and Unix XWindows all map into the same common API. That makes any attempt to change something on one platform a really taunting exercise as it has a great chance to break one of the other platforms. There are also things like a Text manager (a VERY arcane attempt to abstract fonts and text handling into a set of functions), a Dialog manager, which allows to create dialogs in C code that use a LabVIEW VI front panel as resource for the user facing GUI but the entire handling is done in a compiled function from C(++). A Resource manager handles all the binary file formats in LabVIEW that are very much modeled around the old Macintosh resource file format. These are all things that were mostly present in LabVIEW 3 or 4 already, with the exception of the Thread, Mutex and Event manager, which was added in LabVIEW 5 when LabVIEW got true OS supported multithreading, and the UserDataRefnums which were around LabVIEW 7.

I have very little knowledge about the interna of things that were added after around LabVIEW 7.1, as that was when I stopped to really dig into the LabVIEW internals. There is an extensive LVVariant interface that gets also exported since around LabVIEW 8.0 and which would allow to also work with Variants in external code, if it was documented. There was some header file downloadable in the past as part of the CUDA toolkit that contained some of these declarations and with it it would be possible to do some experimentation, but without real documentation it is rather cumbersome.

Now before you start and scream that NI has kept all these nice cookies from you, consider that most users even struggle with the documented functions already and that are the more simple APIs. Much of what I described above would require several centimeters of printed manuals for each of them! It would also mean that these APIs are absolutely carved in stone and never ever can be changed again, which is something NI has kept to in all this time, unless there was an obvious bug in one of the documented functions. The undocumented functions allowed a much more lenient handling when something needed to be changed. The only people going to scream and show up with a rocket launcher because something broke, were either NI internal people or someone bold enough to hack around undocumented functions, where the LabVIEW developers simply could say: Bad luck! You were not supposed to play with those rusty nails!

[Youssef Menjour]

ok thanks guys for all of these feedback !

 

It's for our HAIBAL project we will soon start optmisation of our code and i'm exploring différent possibilities.

We continu the work of Hugo  

Always on our famous stride ! And our dream now is to finish on xilinx platform fpga.

I want to prove that we can be efficient in calculation also with LabVIEW. (Maybe we will have to precompile as DLL a numerous part of our code to make it more efficient)

 

Edited April 15, 2022 by TDF

[dadreamer]

2 hours ago, Rolf Kalbermatter said:

Yes I'm aware that someone tried to hack them anyways into LabVIEW 64-bit and was partially successful.

It was me. And not partially. 64-bit CINs do work absolutely the same way as 32-bit CINs. I successfully managed to call all the entry points and later adapted three examples from Code Interface Reference Manual to 64-bit CINs. Moreover, I managed to make LabVIEW load external subroutines, that was impossible and unsupported in versions 8.0 to 2016. But in fact all this extra knowledge gave me nothing for my real work but wasted time and efforts. I stopped experimenting with CINs in around 2015 or so and never really came back to this legacy tech.

[Rolf Kalbermatter]

On 4/15/2022 at 9:34 PM, dadreamer said:

But in fact all this extra knowledge gave me nothing for my real work but wasted time and efforts. I stopped experimenting with CINs in around 2015 or so and never really came back to this legacy tech.

Basically the point I was trying to make also in previous topics about CINs. 😀

[hooovahh]

On 4/15/2022 at 3:34 PM, dadreamer said:

But in fact all this extra knowledge gave me nothing for my real work but wasted time and efforts. I stopped experimenting with CINs in around 2015 or so and never really came back to this legacy tech.

I don't know much about CINs, CLN, or DLL calling in LabVIEW.  But don't be discouraged.  Our history makes us what we are.  There's several projects I started and spent a lot of time on just to do nothing with, but I feel like I learned stuff or grew as a developer and a person just because of the journey.  Maybe that time could be better spent elsewhere.  But with that mentality I'd never do anything for entertainment.

[Youssef Menjour]

On 4/15/2022 at 9:34 PM, dadreamer said:

It was me. And not partially. 64-bit CINs do work absolutely the same way as 32-bit CINs. I successfully managed to call all the entry points and later adapted three examples from Code Interface Reference Manual to 64-bit CINs. Moreover, I managed to make LabVIEW load external subroutines, that was impossible and unsupported in versions 8.0 to 2016. But in fact all this extra knowledge gave me nothing for my real work but wasted time and efforts. I stopped experimenting with CINs in around 2015 or so and never really came back to this legacy tech.

 

Sorry guys if i feel to be a newbie but what is a "CINs" ?

Another question : I remember during 2011 to see that LabVIEW had a C code generator. Do you know why this option is no more available ?

 

[dadreamer]

52 minutes ago, Youssef Menjour said:

Sorry guys if i feel to be a newbie but what is a "CINs" ?

They are Code Interface Nodes. This is an obsolete and no longer supported technology, that was superseeded by Call Library Function Nodes. If you want to know more about CINs, take a look at Code Interface Reference Manual.

52 minutes ago, Youssef Menjour said:

Another question : I remember during 2011 to see that LabVIEW had a C code generator. Do you know why this option is no more available ?

You still can download C Code Generator package and install it onto LabVIEW (2017 is the latest version), but it's not actively maintained these days and I even suppose, that it was deprecated from LV 2020. If you want to dig this deeper, that thread may be useful for you.

Edited April 20, 2022 by dadreamer

[Youssef Menjour]

11 minutes ago, dadreamer said:

They are Code Interface Nodes. This is an obsolete and no longer supported technology, that was superseeded by Call Library Function Nodes. If you want to know more about CINs, take a look at Code Interface Reference Manual.

You still can download C Code Generator package and install it onto LabVIEW (2017 is the latest version), but it's not actively maintained these days and I even suppose, that it was deprecated from LV 2020. If you want to dig this deeper, that thread may be useful for you.

Thank you very much !! I will have a look it will be very usefull for us about the optimization of our execution code !

[Rolf Kalbermatter]

6 hours ago, Youssef Menjour said:

Thank you very much !! I will have a look it will be very useful for us about the optimization of our execution code !

If you want to build a product, even a free download, around the C Generator, think again! It is discontinued and will not come back ever and almost certainly doesn't work in the latest LabVIEW version without trouble. It can anyhow not officially get installed beyond LabVIEW 2017. The resulting code is, let's say "interesting", but trying to understand it is another matter. And if you end up trying to solve a problem with it, you are very likely simply ending up with at least one more problem than before, rather than one less! 😀

Edited April 20, 2022 by Rolf Kalbermatter

[Rolf Kalbermatter]

17 hours ago, Youssef Menjour said:

Sorry guys if i feel to be a newbie but what is a "CINs" ?

If you want to get some more background information (including pretty much useless historical details nowadays) you may also want to read through these blog posts: https://blog.kalbermatter.nl

Edited April 21, 2022 by Rolf Kalbermatter

[Youssef Menjour]

3 minutes ago, Rolf Kalbermatter said:

If you want to get some more background information (including pretty much useless historical details nowadays) you may also want to read through these blog posts: https://kalbermatter.nl/blog

It seems your page is not working Rolf.

[Rolf Kalbermatter]

1 hour ago, Youssef Menjour said:

It seems your page is not working Rolf.

You were to fast. I typed a wrong URL 😀