LabVIEW, TestStand, Packed Libraries, and Singletons...

[joshua.l.guthrie2.civ]

I'm writing a fairly large (for me) LabVIEW application (it'll probably be a couple thousand VIs) that uses NI TestStand as a sequencer.  Nothing exotic, just running it in a sub-panel using the dotnet calls.  The plan was to deploy the LabView application as a built .exe and use a suite of LabVIEW packed libraries for the LabVIEW calls from a set of TestStand sequence calls.  I don't want to have to have the full development version of LabVIEW on the production machine (especially in this Software as a Service concept).

Several aspects of the program lend itself to a singleton pattern implementation (controversy about singleton's aside).  I implemented the singletons's in the pattern shown at the following link (Data Value Reference (DVR) and provides access with a Notifier implementation):

https://forums.ni.com/t5/LabVIEW-Development-Best/Singleton-Pattern/ta-p/3529034

What's occurred to me, that calling the singletons from the packed libraries w/in TestStand will create new objects because of name spacing between the application and the packed library.  I confirmed this by generating the same objects in a main project and a packed library, flattening them both to strings, and comparing them.  As expected they compare different, and thus the Get Instance method will create two different notifiers and thus two distinct objects.  This is the worst case for me, as we now have one object that is being used some of the time and another other times, and will prove to be a PIA to troubleshoot.

The only thing I can come up with is to pull the singleton pattern objects out of my code, and create a separate object, compile them as Packed Libraries, and call the packed libraries from both the LabVIEW code and the TestStand Sequences.  This is more code than I originally planned on pulling out.  There are some inter-dependencies that will make it a PIA.  I suppose a que message system would work, but I barf in my mouth at the complexity that will add to what I'm doing.

Questions:
1)  Is there a better way to implement singletons?

2)  Is there a better way to call this compiled code from TestStand that avoids this name spacing problem I've backed myself in.

3)  Is there a best practice for this that I'm unaware?

Thanks in advance

[crossrulz · Accepted solution]

---

@joshua.l.guthrie2.civ wrote:

The only thing I can come up with is to pull the singleton pattern objects out of my code, and create a separate object, compile them as Packed Libraries, and call the packed libraries from both the LabVIEW code and the TestStand Sequences. 

---

Yes, that is what you will have to do.  That is the only way to ensure everybody is using the same code.  You might want to spend some time to fully evaluate your library structure, particularly when it comes to interdependencies.  For instance, you should not have two libraries that call each other, causing a circular dependency.  If you properly break down your libraries, it will not be difficult to understand, debug, and extend.

[joshua.l.guthrie2.civ]

LOL.  The sad thing was I originally structured my code as a bunch of sub-projects that built into packed libraries -- then called the packed libraries in the primary project.  I was starting to get mired in circular dependencies, so I pulled all the code into one project..

I think I can do a better job the 2nd time around 🙂

Just stinks doing the same thing twice..

Thanks for your help and best wishes

[crossrulz]

---

@joshua.l.guthrie2.civ wrote:

I think I can do a better job the 2nd time around 🙂

Just stinks doing the same thing twice..

Only twice?  You're doing pretty good.  I couldn't tell you how many times I have had to almost totally refactor my test framework, which also contains a lot of PPLs.

Here is something that might help.  It is a library that goes through all of the libraries defined in the project build specifications and builds them in the order based on dependencies.  It helped me a ton simplify debugging and building my test framework.

Solution Builder for LabVIEW