LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Separate VI instances for separate class instances

Solved!
Go to solution

I have a VI which has two instances a class which I have made. Each instance of the class collects data from a separate USB device. The class also has a pt-by-pt filter built into to its data collection VI.

 

The problem I have is that despite having two instances of the class there appears to be only one instance of the filter. For example, if I have instance A and instance B each collecting data (A1,A2,A3...) in a loop then I would expect the measurement VI of each instance to return the filtered signal of only A1,A2,A3,etc for instance A and B1,B2,B3,etc. for instance B. Instead both instances of the class are returning the same thing which is the filtered result of A1,B1,A2,B2,A3,B3,etc.

 

How can I make it so that each instance of the class has its own instance of the pt-by-pt filter?

0 Kudos
Message 1 of 7
(3,492 Views)

Presumably the data collection VI (aka method) is re-entrant?

0 Kudos
Message 2 of 7
(3,477 Views)
At first it wasn't reentrant. I changed it to be reentrant and didn't see any change in behavior. My understanding is that the ptbypt filter I'm using is reentrant anyway. I think I need to programatically create a new instance of the ptbypt filter each time an instance of my class is initialized. I have no idea how to do this though.
0 Kudos
Message 3 of 7
(3,433 Views)
Solution
Accepted by topic author nickexists

Interesting.  The first idea that comes to mind is to add a strict VI ref to your class definition.  The VI type should be the reentrant pt-by-pt filter vi.   During object initialization, open the VI ref using the reentrant flag (0x08 I think?) and store it in your object data.  Now each object instance will have a ref to a unique instance of the reentrant pt-by-pt filter VI.  And you just change your data acq method to use VI server and the object's unique VI ref to call the filter function.

 

Do consider adding a class method to close the VI ref to avoid a memory leak.

 

I believe this approach will do what you need, but it does "feel" a little awkward.  I'm reminded of an analogous thing I had to do to parallelize a For loop while supporting a unique reentrant instance of vi for each iteration (I was looping over DAQ channels and needed to maintain unique filter state for each channel). 

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 7
(3,425 Views)

That worked, Thanks! It does seem like such a clunky way to do things though.

0 Kudos
Message 5 of 7
(3,398 Views)

Kevin,

 

Could you post an example of how one does each of these steps. This is something that I have struggled with. And I'm in the process of changing my code to classes.

 

Just like you mentioned, I have several DAQ channels that I would like to loop over, but I need to maintain reentrant vi's which are specific for each channel. On top of that, the user at run time, can choose what channels they would like to sample. This sets up a situation where I have had to break the data into groups. Then I have created several case structures for all of the possible combinations of a channel type. I figured dynamic dispatch can take care of separating the groups of channels, but I still need reentrant vi's that are specific to each loop. Otherwise, I'm back to putting in case structures. The main point being that each channel is assigned to it's own reentrant vi.

 

Thanks,

Ben

0 Kudos
Message 6 of 7
(3,119 Views)

Here's a link to a post I made before on a similar topic.   Hopefully it gives you a decent template for getting started.

 

The upper loop is only there to store the unique reentrant instance vi refs that are opened on first call.  The value 8 (shown as hex, but same in decimal) when opening the vi ref creates a new reentrant instance of the processing vi.  The processing vi must have its execution properties marked for reentrancy as well.

   Thereafter, there's a 1-to-1 correspondance of instance # and index # of the "stations" array, which is simply a container to bundle DAQ data with some measures & attributes.

 

 

-Kevin P

 

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 7 of 7
(3,093 Views)