Jump to content

Call Library node calling "LabVIEW"


Recommended Posts

UbP3e.png

Exactly what library is this calling? I found it in one of the VI's that comes with LabVIEW.

What the name says: LabVIEW. Basically LabVIEW exports a lot of so called manager functions that can be called from C code, such as when you write a DLL (or shared library on non Windows systems). A lot of those manager functions are described in the External Code Reference Manual which comes as part of the help files in your LabVIEW installation. The LabVIEW library name is a special keyword, that tells the Call Library Node to link to whatever the current LabVIEW execution kernel is (LabVIEW.exe in the IDE, lvrt.dll in a built app). Note the case of the letters, which needs to match exactly with the official spelling.

And before you ask, LabVIEW exports more functions than are described in the manual such as the one you found. Some are used internally by LabVIEW VIs but they are usually password protected. Sometimes one slips through the cracks. Most of those undocumented functions make no sense to be called outside of a very specific context, and some are rather harmful if not called in a very specific way. A lot of them are really only exported so that LabVIEW can itself use them as a sort callback and they make not really any sense to be called from a VI diagram.

Link to comment

It's no different than calling any other DLL. It calls into labview.exe in the dev environment and into lvrt.dll in the runtime engine. We could have made it always call lvrt.dll, but that would effectively make two copies of the DLL in memory. For the record, the reason that we export functions is so that we can expose VIs that call those functions, so pretty much all of those functions are exposed as VIs already in the palettes. Those that are not exposed as single VIs are part of other VIs. Calling things like MoveBlock directly are particularly dangerous since they arbitrarily overwrite memory.

Link to comment

Oh, okay. In case you're wondering, it was in a password-protected VI, so that makes sense. Hmilch's VI Explorer is awesome. ;)

Is it? And what did you learn from this awesome look behind the curtains? Yes there is a function you can use to translate an error code into an error string. But the VI that you looked at does that already for you without the need to bother about correct calling convention, parameter type setup and a few other nasty C details. Not sure I see the awesomeness here, other than the desire to feed your own curiosity and find more ways to shoot in your foot.

Link to comment

Is it? And what did you learn from this awesome look behind the curtains? Yes there is a function you can use to translate an error code into an error string. But the VI that you looked at does that already for you without the need to bother about correct calling convention, parameter type setup and a few other nasty C details. Not sure I see the awesomeness here, other than the desire to feed your own curiosity and find more ways to shoot in your foot.

Just let him have his fun. It lets him feel like a leet haxor.

But seriously NI doesn't appear to have any thing to hide in those VIs, as demonstrated by this here.

  • Haha 1
Link to comment
For the record, the reason that we export functions is so that we can expose VIs that call those functions, so pretty much all of those functions are exposed as VIs already in the palettes. Those that are not exposed as single VIs are part of other VIs. Calling things like MoveBlock directly are particularly dangerous since they arbitrarily overwrite memory.

I'm curious (and maybe this is becoming OT) why VIs such as that which don't have much/any logic on the BD were just exposed as "native" nodes - no block diagram to even try to look at. Is there are a lot of overhead in nodes like that?

Link to comment

I'm curious (and maybe this is becoming OT) why VIs such as that which don't have much/any logic on the BD were just exposed as "native" nodes - no block diagram to even try to look at. Is there are a lot of overhead in nodes like that?

I'm not sure what you are asking here. Do you want to know why NI didn't make a yellow node of this function? If that is your question I can think of a few reasons.

It's much easier to add an "undocumented" VI in vi.lib calling back into LabVIEW than adding a new node to LabVIEW. A new node needs an icon, help and several more resources embedded in the executable. That is a lot of work in terms of extra work, testing and verifying. A VI is added easily to vi.lib, can be adapted, tested, modified and documented by non LabVIEW core developers, and if the need should arise and it didn't get documented in the meantime, changed, removed and whatever else. Adding a private export of a C function only requires the expertise of the LabVIEW core developer who works on that code, not the expertise of several people working on various parts of the whole LabVIEW core.

A developer of a new tool in LabVIEW finding to need access to a specific internal data structure can either file a new proposal to add an (undocumented) node, and wait until the powers to be have decided that this is a good idea, developer resources have been assigned to work on that, and testing and documentation has had their say, or simply add that export to the exported LabVIEW functions, create a private VI to access it and be done. Sure such functionality might be an interesting candidate to turn into a node at some point, but chances are that nobody will look back once it's done and working.

So it's a shortcut to add functionality to LabVIEW that a new tool might require, without having to go through a hole bunch of modifications of the LabVIEW core itself. Since the password protection is now seriously broken and can't be used to prevent people to go into such VIs to shoot their own foot, they probably will change policies in the future and move a lot more into the direction of new (possibly undocumented) nodes, to expose such functionality. Undocumented, because once a function has been documented it can't really be removed anymore or even just modified, without a lot of hassle.

Link to comment

Is there are a lot of overhead in nodes like that?

Yes. A new VI takes a few minutes to develop. A new node takes a few days at a bare minimum for the simplest node: type propogation, compiling, marking which inputs are in place to others, adding documentation, potentially marking which versions it's available in, enumerating each of the terminals, potentially adding properties and methods, maybe making it support different types (do you have any idea how many numeric nodes support clusters of numerics?), building the intermediate representation for the compiler, building the compiler code for it, etc. Plus all the time it takes to actually compile LabVIEW. Plus time to check for type-safety bugs (e.g. dereferencing null), save for previous, etc. LabVIEW takes care of all of these things for VIs.

We have a document for creating new primitive functions that is 12 pages long because there are so many different things you need to worry about. Creating nodes (which are more complex than primitives) is much harder.

Link to comment

Thanks for the replies, rolfk and Mr Mike. Had I thought it through a little more, that'd have been obvious. I'm glad to hear that the application process for nodes is thorough, at least. The VI approach, while less controlled, does make more sense in these instances.

Link to comment

Yes. A new VI takes a few minutes to develop. A new node takes a few days at a bare minimum for the simplest node: type propogation, compiling, marking which inputs are in place to others, adding documentation, potentially marking which versions it's available in, enumerating each of the terminals, potentially adding properties and methods, maybe making it support different types (do you have any idea how many numeric nodes support clusters of numerics?), building the intermediate representation for the compiler, building the compiler code for it, etc. Plus all the time it takes to actually compile LabVIEW. Plus time to check for type-safety bugs (e.g. dereferencing null), save for previous, etc. LabVIEW takes care of all of these things for VIs.

We have a document for creating new primitive functions that is 12 pages long because there are so many different things you need to worry about. Creating nodes (which are more complex than primitives) is much harder.

I'm curious about that document. Any chance I (and the rest of the community, of course) can see it?

Also, hooovahh, I saw your post, and I don't feel like a "leet haxor" just because of something small like that. Don't jump to conclusions. :rolleyes:

Link to comment

I'm curious about that document. Any chance I (and the rest of the community, of course) can see it?

I can't speak for NI and don't know that document, but I'm 99.99% sure that it has a big watermark across the front page, stating:

"Company Confidential".

Quite possibly this watermark is repeated on every single page. Besides of that it would be of no significant use to us LabVIEW users, as it refers among other things, to various places in the LabVIEW C++ source code, where specific provisions need to be added for the new node, the internal daily unit test framework run that needs to be enhanced to test the new node, the fact that the documentation department needs to be informed about writing a new help section for this node, and probably a few other things, that leave everyone not working in the LabVIEW team flabbergasted. And that document most likely isn't the most popular bedtime lecture of any LabVIEW development team member either. :D

In other words, if you want to see this document you will need to apply with NI as LabVIEW developer and hope to be accepted. :cool:

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.