05-27-2009 02:46 PM
Hi,
I'm using Labview 8.6 to create a DLL, and then I'm creating another Labview program that will call that DLL. Within the DLL is a function called Untitled2 that is your basic uninitialized shift register. It has a numeric input that can be put into the shift register and then I can read the number back. After I build it in to the DLL and call it from another Labview program it looks like the shift register values are lost. So, my question is whether Labview DLLs that contain uninitialized shift registers allow the shift registers to retain their values? I'm attaching a copy of Untitled2.vi so you can see my simple test vi.
Also - does anyone know of any good articles about building DLLs from Labview?
Thanks!
Steve
Solved! Go to Solution.
05-27-2009 04:05 PM
This works just fine here. Can you make an actual project with the built specifications so we can reproduce your problem?
Also...
05-27-2009 04:18 PM
altenbach wrote:It is also better to place all controls and indicators outside the structures.
Here are some references for this statement:
http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=191642#M191642
(read the entire thread!)
05-28-2009 09:29 AM
Thanks for all of the great info! I read that thread and learned a lot.
I also re-compiled my DLL so that I could post the vi's here... and now it works..... I'm not sure what happned yesterday. Thanks again for your offer of assistance.
I do have one additional question, on a similar thread - A lot of my vi's are very modular, in that they are grouped according to specific functions (one set to communicate to the function generator, one to my motors, etc). I'm considering compiling each group into a DLL because I think it will make my overall project smaller in size and easier to maintain. I can't find any documentation about the speed of calling a DLL versus calling a sub-vi. So, my question is: If I have a DLL (written and compiled in LV) and a sub-vi that both perform the same exact function, if they are both called from within Labview which will run faster? Or are they about the same speed? Does it matter if there are a lot of inputs/output, or there are large arrays involved? Finally (also about speed), I have a vi that is part of the user interface (a screen that users interact with). Will it run faster if called by reference from a main vi, or if I call it via a DLL?
Steve
05-29-2009 10:40 AM
Steve_G wrote:I can't find any documentation about the speed of calling a DLL versus calling a sub-vi.
There are all interesting questions, but I have never used any DLLs in this fashion so maybe you have to do your own benchmarks to be sure. 😉
Since LabVIEW itself makes excessive use of DLLs (e.g. all the advanced analysis functions), I suspects that there won't be a big difference. Maybe somebody from NI can give the definite answere her. 😉
05-29-2009 12:08 PM
The short answer is the fastest way to call a VI from a VI is with a direct call. Any other way of doing it is somehow wrapping this mechanism which means added overhead. If you want to hear some of the details, then you can read on.
When a caller VI loads, it is "patched" with its subVIs. This means it holds onto a pointer that it can use to efficiently call that VI. The caller also allocates a parameter list for each call. When the call executes, the only thing the caller has to do is fill out this parameter list with the locations of its data and pass the pointer to this table to the subVI's code.
When you call a VI that is built into a DLL, the call library node must first put all the parameters into the form expected by the DLL calling convention. This is different than LabVIEW's parameter list approach and typically means putting each parameter on the CPU's stack. The exported function in the LabVIEW built DLL, must first get a connection to the VI to execute. It accomplishes this by getting a VI reference from a cache of VI references created when the DLL loaded. Each VI reference has a parameter list which must be filled in the parameters for this call. It can then call the code. When the code is complete, there may be additional work to put any outputs into the form expected by the caller. The VI reference must then be returned to the cache.
So there will be more parameter manipulation when calling through a DLL and a couple of accesses to a cache that can cause overhead and additional jitter with parallel calls. Even a call through a strict VI reference a would be faster. With that you are in direct control of the VI reference so no cache is involved and the call puts the parameters directly into a parameter list the subVI expects so there is less manipulation there.
There are also several other limitations introduced by calling a VI through a DLL.
Hopefully all this doesn't scare you off using LabVIEW to build DLLs. When you need to communicate to other software, it is the way to go and all these steps are necessary to cross that boundary. But if you are already in LabVIEW this is not an ideal replacement for directly calling a subVI.
06-01-2009 08:53 AM
06-01-2009 10:53 AM
Greg,
Thanks for the detailed explanation - it clears up a lot for me. My software controls a lot of different instruments and the size of the built application keeps getting larger so I'm always looking for ways to get it smaller. I'll definitely use DLLs whenever possible, but will keep the limitations in mind.
Steve
06-01-2009 01:55 PM
I figured this was really great info, so I started a new "Behind the scenes" page on the LabVIEW wiki with this info. Chris, it's my first one, so its structure probably sucks (and I didn't edit the text at all). I would appreciate it if you could do something about that.