Variables and Building DLL

[teodor_blaga]

Hi,

    After I collect all usefull informations and making all necessary VIs, I tried to organize them into a project which in the end will export some functions to a DLL. The parameters inside will be access by variables. So everything goes well if you do not try to build a DLL. When I will perform that none of the variables will be seen by that dll. Could be multiple reasons. Trying to combine lvlib, llb, vi, variables and virtual folders in the same time can put the builder in the possition that is not able to see those global variables. If you put everything in the same place it will work fine but the project will not look in a very professional way.

    Another topic are the created vi's for each variable. Where I can configure that to put those files into a llb or to do not create them at all? If you will put them in a llb manually it will take a few days to reconfigure everything because each variable must be updated manually and in the end you will be full of conflicts solved or unsolved.

    So the last question is if you know a way that works to group my variables and these to be seen during execution of the DLLs?

[RobBoyer]

Hello,

Unfortunately, I suspect nobody knows what you are attempting to ask.  Maybe if you have some specific issue, you may get a concrete answer.  In general, the actual location of you VIs has no effect on the process of building a DLL - regardless of whether they are global variables, or regular VIs.  If you organize your code well, there should be no reason that you can't build your DLL.

One thing that I suspect is complicating things for you: it sounds like you are using global variables extensively.  This is not a good idea (regardless of what programming language you are using).  My suggestion would be to spend some time organizing your code and getting rid of as many global variables as you can.

Rob

[teodor_blaga]

The problem is when I use Project explorer features like vilib llb and variables I will have this effect. When you run a vi it will work fine. When you will use a second vi to use these variables values  from the first execution of the first vi, it will work only if first vi is not closed. If you close the first vi, the second vi will see those variables like they are uninitialized. If you leave it open then the second vi will see the values from previous one. In my opinion it must work because the variable is defined in Project explorer which is opened during these two tests.

If you do a dll from these two vis and you call one of those this is running like a function or like a vi? The behaviour tells me that is running like a function. So one time that the execution was finnished is like you will close the vi.

So could be a bug (with updates) or a certain setup for the variable which is a Shared one not a Network one.

I cannot do it without variables. I know that this is not the style but this time they are really necessary.

[RobBoyer]

I know that some object-oriented features have been added to newer versions of LabVIEW, but I'm not sure that there is an elegant way in LabVIEW to do what I think you are trying to do.  It sounds like you want to create a DLL that exports some functions that all operate on some shared data (your globals).  In most modern programming languages, you would create an object class with some shared data members and call the methods on the same instance of the object to share the "global" data.  To simulate this in LabVIEW, perhaps you could write an abstraction layer (a VI) to unify all of your DLL calls.  That way there is always one VI running that keeps all your globals active and provides a way to retrieve and update them as necessary.  I'm not sure how you'd go about doing this in LabVIEW and I'm not sure that LabVIEW is really designed for this kind of coding.

Alteratively, maybe you could write an interface for your globals that doesn't stay open the whole time, but instead abstracts away serializing and deserializing the data to a file?  You'd have to be careful about race conditions either way.

If anyone else out there knows a good solution to this please chime in.  I am curious as well.

Anyway, another thing to consider is whether you really need a DLL - I've seen a lot of people lately trying to make everything into DLLs without a good reason why.  What benefit are you trying to get by making it a DLL?

Rob

[teodor_blaga]

It is not about classes. There are parameters that must be chaged from time to time and read from time to time ant they will affect the future exectution.

Your idea to that vi will eliminate the problems of corse. I was thinking yesterday to that and I will not need variables at all only a while loop full of shift registers which replaces the actual variables. But I could have problems with some NI DAQmx functions that are working in different way for different polimorphic values especially when you apply those changes in the same time.

Another idea is to try to put all the files in one place and to skip those project good lookings (llb vlib virtual folders). As I saw this could be a solution. But I will try it today.

[RobBoyer]

I wasn't saying you should use classes.  I was just pointing out how software engineers would typically solve this kind of problem given a decent set of development tools.  If you do not have the skill, or the tools do not support an elegant solution, I am saying that you should expect the solution to be nothing better than a work-around.

Regarding the "skipping project good lookings", the fact that you have some VIs bundled into LabVIEW libraries, etc, has *nothing* to do with the global variables losing their values between DLL calls.  If that is not your concern then you need to be more clear.  If you put all of your VIs into one directory and build a new DLL, it will suffer from the same weakness as your current solution.

If you want a relatively easy solution to the problem of your globals losing their values between DLL calls, you will need to consolidate all the code into one function call.  Otherwise, the caller will need to keep the LabVIEW runtime alive between calls.  I doubt that is a particularly big deal, but it probably would involve a little digging into the LabVIEW application API.  Good luck,

Rob

[teodor_blaga]

It is true it seems that is not depending on Project Explorer.

I expected those variables defined in this Project Explorer to be independent than a function call, because they are special VIs. From a dll perspective I could see that a data memory area that can be changed using interface functions and this area to be lost only together with the ending life of the loaded dll.

I can change it without using the variables, this is the way how I was working till now. But seems that I trusted too much in these variables for this architecture and they are not working as I expected to be linked to the project not to a certain VI.

Thank you for your help and I will update something here if I could see some good work arounds.

Teodor 

[teodor_blaga]

After I tried a work around of the problem which works in LabVIEW seems that is one conclusion. Don't use Variables and especially with DLLs. The NI DLL Builder is not capable after five or six years to work corectlly with them. Serching and researching continues on my side.

One thing is shure these variables are working not as expected and they behaves differentlly from a case to another. Till yesterday I had the problem when I close the front panel of the VI the variable value disapear sudenlly from memory, and after the workaround seems that when I close LabVIEW, the variable will actually disapear, and till then the same area can be used by the DLL too. But the DLL is not capable to create by itself this data area. I'm wondering which magic combination of DLL setings will solve the problem if there is one.

About builder DLL I could add one more thing. I lost for several times previous settings of the making dll, so how can I be shure that it works how I was setup it every time?

[RobBoyer]

Believe me, I understand the urge to blame NI for all of your headaches - it is a powerful, though fruitless, temptation that is further exasperated by poor documentation and quirky software that exudes proof of bad architectural decisions.  But I think, in a rare turn of events for me, I will have to side with NI on this one.  I think that the root of the problem you are facing is not specific to LabVIEW.  If you created a DLL in C++ that utilized global variables, you could not expect the value to persist between calls there either.  The fundamental problem is that you have nothing tying your DLL calls together - the calling code, (regardless of the language), is ordinarily responsible for keeping static information in memory.  I could be wrong - I'm still quite hazy on your exact situation, but I think what you want to do can be done.  You just need your global variables to be kept alive.

As far as saving setup for the DLL, there is a way to save the build info (kind of like a makefile).  That should do it.

Rob 

[teodor_blaga]

The test procedure it is simple. Not using any other language only LabVIEW to create and test that DLL. So no other languages involved.

Create some VIs in LabVIEW and test the created DLL using 'Call library node' the same VI. The idea is if it is not working in LabVIEW it will not work also for other purposes.

So I took a small part of the project and tried to save by using a file function a debug information on the disk. What I saw?

The info will be written on the disk only in some cases. So looks that the function will not call everytime this file function inside the DLL only if you do it once in LabVIEW with the same function. So LabVIEW and DLL share the same area, but DLL cannot handle its own area only helped by LabVIEW.

If you want I can send a small part of the project and you will see how it is working. The idea in not to change the architecture. I know I cand do it in four or five ways, the idea is to fix a problem on my project if it is a project related one or to fix the language if the language has a problem.