LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FGV as part of a Class

Howdy!  Basically, I'm writing an "Output" class for a generic control program. I wanted to attach a PID as part of the class, but the VI is a FGV and it doesn't work.

 

To test what was going on, I built a very simple class with a FGV in it and set the access scope of the FGV to "Private".  Regardless of this, the data inside the FGV is shared across multiple instances of the class. I fiddled with the VI Reentrancy properties and nothing seemed to help - it was either shared or it didn't work at all.

 

Short version:  should I give up having the PID as part of the class and change my architecture, or is there something else I'm missing?

 

 

Edit:  Oh, and before someone says "Just feed an array in to the PID, it accepts them", I am fully aware. The point of this was to be able to have PID as part of the Class, and then the outputs basically be an array of this class.

0 Kudos
Message 1 of 4
(2,830 Views)

Yep, if you include the FGV inside your class it, by definition, exists ony once irrespective of how many class instances you create. This is one mechanism for creating static class data that is shared between objects. If you make it re-entrant than you are simply making clones where-ever you are calling it inside your Output class (and thus multiple copies of your PID state) which also defeats the purpose.

 

If I understand what you are trying to achieve, the simplest approach is for you to store the same data that is saved in the FGV as part of your class private data and then extract the actual PID logic into a static dispatch VI that uses that private data to execute the PID. 

 

Something will need to execute the PID at regular intervals of course so that the state is updated. There are complicated ways to do this (some sort of Active object) but I presume you already have a caller that can call a method of the Output class and in doing so will update the PID state.

 

EDIT: I forgot to mention that I have done this previously by manually implementing the bare-bones PID algorithm.

Message 2 of 4
(2,818 Views)

You might want to consider putting the 'variable' portion of the FGV into the private data of the class instead of storing it in the FGV vi itself.  That way, your vi takes the old values in from the object, does whatever manipulation your FGV would have done, and then passes the new data back to the object to store until the next iteration.

Message 3 of 4
(2,816 Views)

Thanks. I figured that was the case, but wanted to make sure. I had considered storing the FGV data as part of the class and then feeding it in to the PID each call, but the default "PID Advanced.vi" has such high coupling to start with (not to mention 18 different uninitialized shift registers) that I didn't really feel like messing with it. 

0 Kudos
Message 4 of 4
(2,806 Views)