Loading modules into and unloading modules from memory

[Rafal_Kor]

When I run the Tester for any module in development mode, I see that the module gets locked out, even though I have not run a single instance of the module from within the tester yet. Does the lock on the module mean that all of the module gets loaded into memory as soon I run the tester, or is the lock placed on the module simply because, the tester makes use of the request VIs from within the module. Is it any different in compiled application, when I compile the tester into an .exe? The reason why I ask, is because I'm working on an application using non-NI hardware with very poor drivers/API. It seems like the drivers/API for this hardware do not clear and clean up things internally, such that for example in case of an error in the hardware, I cannot get hardware to subsequently reset itself. My application continues to run, the module communicating with the hardware continues to run. No issues there as DQMH is ROCK-SOLID at least for what I need it to do. It's just that unless I shut-down and reload the application completely, I cannot get the hardware to start going again.   

[Darren]

---

@Rafal_Kor wrote:

When I run the Tester for any module in development mode, I see that the module gets locked out, even though I have not run a single instance of the module from within the tester yet.

---

I assume when you say "locked out", you mean the module lvlib has a lock symbol on it? This happens because there are VIs in the library (namely, the public Request VIs of the module) that are reserved for running because they are called as subVIs in the tester. You cannot edit a library that contains VIs that are reserved for running.

---

@Rafal_Kor wrote:

Does the lock on the module mean that all of the module gets loaded into memory as soon I run the tester, or is the lock placed on the module simply because, the tester makes use of the request VIs from within the module.

---

The lock on the module lvlib means that the library cannot be edited while any of its member VIs are running or reserved for running.

---

@Rafal_Kor wrote:

Is it any different in compiled application, when I compile the tester into an .exe?    

---

This scenario doesn't apply when the code is built into an EXE, as the EXE contents cannot be edited. The only reason the library is locked when you run the tester is because you are not allowed to edit it.

---

@Rafal_Kor wrote:

The reason why I ask, is because I'm working on an application using non-NI hardware with very poor drivers/API. It seems like the drivers/API for this hardware do not clear and clean up things internally, such that for example in case of an error in the hardware, I cannot get hardware to subsequently reset itself. My application continues to run, the module communicating with the hardware continues to run. No issues there as DQMH is ROCK-SOLID at least for what I need it to do. It's just that unless I shut-down and reload the application completely, I cannot get the hardware to start going again.   

---

Are you saying that the hardware gets into a state such that a restart of LabVIEW/your EXE is required in order to get it working again? This sounds like an issue with the hardware API more than with DQMH. Can you wrap the hardware API such that all the hardware subVI calls are performed dynamically? Or perhaps you could have a parallel VI that performs all the possible hardware operations, and launch that VI dynamically? And if the DQMH module detects the hardware is in a bad state, it can close the dynamic VI (so that it leaves memory), then launch it again?

[Rafal_Kor]

---

 wrote:
Are you saying that the hardware gets into a state such that a restart of LabVIEW/your EXE is required in order to get it working again?

yes, even though I'm certain that the application, in this case compiled tester, and the module it launched continue to run and respond to my commands, as I can orderly shut down the module and close the tester without resorting to brute force termination of the compiled application.

---

This sounds like an issue with the hardware API more than with DQMH.

---

yes, that is my suspicion too.

---

---

Can you wrap the hardware API such that all the hardware subVI calls are performed dynamically? Or perhaps you could have a parallel VI that performs all the possible hardware operations, and launch that VI dynamically? And if the DQMH module detects the hardware is in a bad state, it can close the dynamic VI (so that it leaves memory), then launch it again?

---

Yes, that is exactly what I tried doing initially. I just don't know how much "venting-of-my-frustration" with the "labview-factory-pattern-operation-in-compiled-executable" I can do here, this being the DQMH forum, and I have no problems with DQMH - I love it.

So to describe my application a little. I have a hardware cloneable module, 2 instances of which get launched. I then set identity for each instance. what I mean by that is that I originally had a factory pattern implemented to execute in the set identity case of the MHL, invoked via the appropriate request message, where in each module the appropriate hardware child class was getting loaded dynamically from the hard disk, any time the specific instance of my cloanable module got the message to set its identity, such as upon initial launch or in the case of hardware error. Anyway, that set up worked flawlessly in development, I mean it was a thing of beauty. The factory pattern worked exactly right in the development. Then I complied my tester into an .exe, to see how it worked then, and the factory pattern simply wouldn't load the correct child class on the parent class wire when I ran it in .exe. So in great frustration, I placed a giant diagram-disable structure over the factory pattern, and in the enable case I placed a case structure where in each case I placed an instance of each of my hardware-children classes. The case structure is then driven by the set identity message and it loads, with no problems, the appropriate hardware child class on the parent wire both in development and it .exe. The unintended consequence of this solution is that now my hardware child classes are immediately loaded into memory and stay there unless I shut down the executable. So that is what i was trying to find out, how much the tester compiled into an executable would load. Meaning, does the tester load its tested-module if it runs as .exe, even though not a single instance of the module has been launched? you see, I though my quick-fix for the factory pattern problem, I though, would be innocuous because even though the hardware child classes were hard-code instantiated in the module, if the module wasn't loaded... or could be reloaded... I thought, there'd be no harm. Now about the factory pattern, I admit my initial problem with it was caused by the fact what I wasn't stripping the .exe name from the path, when running in .exe.. But even if I correctly build the path to my hardware child classes when running in .exe, the "to-more-specific-class" call, just keeps return a generic labview object, when in .exe, yet in development it somehow knows to return the correct hardware child class. 

[FabiolaDelaCueva]

Hi Rafal,

This is definitely not a DQMH issue... still, let's see if we can help you out. 

Can you post your implementation of the factory pattern, please? Also, describe where you put your classes in the file structure of your executable. There might be something we spot by looking at the code.

Regards and thanks again for your trust on DQMH.

Fab

[Rafal_Kor]

yes, I would like to post my hardware module here. this will have to wait until a little bit later, I'd like to say over this weekend. In addition to posting the labview code here, I'll need to give you the executable for the hardware drivers/API. you'll need to install it first before opening the labview project in order to set up the labview environment correctly.

[FabiolaDelaCueva]

Rafal,

If it is too much trouble to share the entire code, you could also just share the snapshot of the Factory pattern section of the code and where the classes are with respect to the executable on the final distribution.

Otherwise, we will wait for you to get a chance to post the whole thing.

Regards,

Fab

[Rafal_Kor]

Fab,

Thank you again for taking the time. I have isolated my project to just one module and within it, just the factory pattern. Please excuse the messy code. Also what's in the module has been stripped and so at first glance may appear to be a complete nonsense. The factory pattern is there, complete and working in development and not working when compiled. You'll have to compile the code on your end. The path to the child classes is relative to the "application directory". When I ran the code on my end I placed the child plug-in classes at the following location application directory\Libraries\Hardware\Hardware Classes. In the project my hardware classes are a part of the Hardware.lvlib of the hardware module. I'm not sure if it matters but for the compiled application i just copied the top-level folder containing the generic hardware class, and all the subfolders with the all the child-classes, and placed them in the application directory with the compiled .exe. thank you again for taking the time

[FabiolaDelaCueva]

Hi Rafal,

I am looking at the code now. 

Observations: 

* Good idea on using the one button dialog to display the class name and the path. I would suggest you use the Status Updated broadcast instead, that way you can see the path in the API Tester Status string. 

* From reading your description of where you place the classes, I was wondering if the issue might be that the classes are namespaced within the library in dev mode as opposed to out on their own in the exe. 

* Unfortunately, I was not able to test my theory because I get an error when I attempt to build the executable:

I will try a couple of things to fix the build error. If you can try building on a different machine than you normally build, you might be able to help me narrow down the issue with the build.  

[FabiolaDelaCueva · Accepted solution]

I mass compiled all and was able to build.

The way I got the exe to work was by adding the parent class to the Always included list in the build specification. 

I am getting errors but that might be due to not placing the children classes in the right place. The factory pattern is reporting the correct load path and class name in the exe via the one button dialog.

When I tried to move the classes outside of the library, I realized that the children classes are calling Private VIs from the Hardware library. When the classes get copied to the destination library, they no longer have access to the private VIs within the Hardware library. I would suggest you move out any calls to the Hardware library that are currently inside the class methods. 

I hope this helps. Let us know if you are able to figure it out.

Regards,

Fab