Correct way to create objects from a loaded class

[GoKu25]

Hi,

I'm doing some LVOOP. I load a NiDMM plug-in class dynamically using the factory pattern and save the object(dmm1) in a Variant FGV using the set variant attribute . I want to create many objects of the loaded class. The way I am doing it right now is I am making copies of the loaded class by Getting the saved object(dmm1) by it's name and Setting it again under a different name (dmm1_obj1).

The copied objects, on writing new values to it's private property, retain the data, have diiferent properties on reading from the FGV and is working fine now. But  would like to know if there is a right way of doing this

[wiebe@CARYA]

---

@GoKu25 wrote:

But  would like to know if there is a right way of doing this

---

Try working by wire.

Storing everything in a universal (global?) container might be really convenient at first. It's also probably much more complicated then needed.

Any time I have an array of objects, I have either an array of objects (duh), or a child containing an array of objects.

I know all those required wires seem like a terrible idea. But storing objects by labels doesn't scale well. At some point (parts of) your code needs to be started twice. All labels would need to be modified. It could be disastrous.

How would concurrency (two loops working on the same objects) work? Well, it should be avoided. When one loop needs (results of) another loops object, send it with an event. More work to program (maybe), but easier to comprehend and debug IMHO.

Parallel access to shared objects seems fun at first, but sooner or later you'll need to add interlocking\synchronization glue code. That usually spoils the fun for me.

All in all it's not a terrible choice. Lots of people use it all the time, I assume. Just know the risks.

[Kevin_Price]

Based on your other threads, I'm figuring this relates to your integration with TestStand.  What you show was the kind of thing I did reluctantly because I didn't find a reasonable native-to-TestStand way to make an object with a live comm connection persist from one TestStand sequence to another.  I made an object repository much like you appear to have done.  I also launched a background LabVIEW process containing an instance of the FG I used as the object repository.  This simply existed, idle, in the background throughout the entire suite of TestStand test sequences we need to run on the device.  It was the async background process that kept the FG in run state and prevented garbage collection on the comm connections at the end of each sequence.

That was several years and versions ago, plus I was new to TestStand.  Maybe there was a better way then, it's even more likely there might be a better way now.  But if not, I can at least confirm that you're on the same track I was.  But bear in mind, I was a TestStand noob and a LVOOP novice at the time.  I can't say whether my track was a particularly good one.

-Kevin P

[crossrulz]

---

@Kevin_Price wrote:

I also launched a background LabVIEW process containing an instance of the FG I used as the object repository.  This simply existed, idle, in the background throughout the entire suite of TestStand test sequences we need to run on the device.  It was the async background process that kept the FG in run state and prevented garbage collection on the comm connections at the end of each sequence.

---

I have not needed to have this idle process.  As long as the modules do not get unloaded by TestStand, the Action Engine/FGV keeps its memory in tact.

But, yes, I do something similar with my TestStand code.  I have libraries to act as wrappers for my driver classes and they keep the objects stored either in a Global Variable (if I know for sure only 1 of that instrument will be in my rack) or an Action Engine using a string lookup to get a DVR to the object I want to use.  Couple that with PPLs and you will start to understand the web I have weaved in order to make a plugin HAL.

[Kevin_Price]

Just to clarify.  I think I also didn't have a problem with the HAL device objects *themselves* going out of memory.  It was that certain live comm connection references contained within the HAL device objects were automatically released when the FG ceased tobe in "run state."   

A couple of the types of connections were pretty slow to establish (in the order of seconds), in the same order of magnitude as the time to perform several of the individual tests.  For the sake of test throughput it was important not to let auto-cleanup release those connections until the device went through its whole suite of tests.

So with that further background, was/is there a way to configure TestStand to keep those comm connection references alive between sequences?  (Thinking back, it may have even been that I had a problem keeping them alive between steps *within* a sequence.   Not sure anymore.  And again, my familiarity with TestStand was, and still is, quite low.)

-Kevin P

[crossrulz]

---

@Kevin_Price wrote:

Just to clarify.  I think I also didn't have a problem with the HAL device objects *themselves* going out of memory.  It was that certain live comm connection references contained within the HAL device objects were automatically released when the FG ceased tobe in "run state."

---

Ok, I think we are on the same page now.  For instance, Windows like to automatically close out Ethernet connections if there was no activity for X amount of time (amount seemed random).  So I have had to have threads to perform "ping" every so often just to keep that connection alive.  I usually make that a Queued Message Handler with a timeout on the queue to perform the ping on timeout but also perform all of the sending of commands as commanded.  TestStand then just has access to the message VIs.