From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Identical reentrant FGV's? How to tell them apart?

Solved!
Go to solution

Ahhh I should have mentioned - I did build it first the way you showed in the link as I've attached - it appears to work, but actually is broken in a strange way.  I can run the Initialize action, but then incrementing/decrementing don't work properly - they work the first time, then they don't.  Hmmmm - as I tell this story I begin to suspect that the problem isn't in the 'Test' setup, but in the Little VI.vi instead.  But when I run Little VI standalone/static it works ok... Confusing

0 Kudos
Message 21 of 25
(374 Views)

I think the problem you are having is "conceptual".  Your example, where you have a "Little VI" that does simple operations on a "Register" (such as Initialize, Increment, Decrement) doesn't need a Clone, but rather a Register built around an Array instead of around a Scalar.  You define how many "Registers" you want, initialize an Array of size "Register Size" (and call it "Register"), and when you do an Increment, you say which Register (meaning which element of the Array "Register" you are affecting, remembering that Array indices start with 0, not 1) you want to manipulate.

 

I'm just noticing (just shows how observant I am!) the "FGV" in your title.  I don't think of "Clones" as FGV, but as full-fledged sub-VIs that run asynchronously with respect to the main VI.  The "trick" with asynchronous VIs is that you may need to get data into and out of them while they are running.  In your case, your Little VI needs multiple inputs of Action to be meaningful, otherwise (as you notice) it only runs once, but that's because "you told it to".

 

When LabVIEW 2016 was released, along with Asynchronous Channel Wires, I went to town and started using the Messenger Channel to tie together my Parallel Loops (or Asynchronous VIs).  The only problem (at the time -- this might have been solved by LabVIEW 2020, or possibly will be solved in LabVIEW 2021) is that you cannot pass an Messenger Channel Reference into a VI started as a Detached VI (which is how you want to launch identical re-entrant Clones).  OK, so you "cheat", and fall back on using a Queue to get the Message into the Clone (and use Messenger Channels thereafter).

 

Bob Schor 

Message 22 of 25
(366 Views)

I'm trying to wrap my head around several concepts here.  First - the "Register".  My understanding is - a "persistent" piece of data that's stored as part of a VI's data, available for subsequent calls.  So my implementation of that is, in the example case, a trivially simple FGV that performs operations on a number.  In my application, this would be a state machine that stores controller state data in a "Register".

 

But Wait, There's More! I have a bunch of controllers whose states I need to keep track of.  So I figured I'd make a reentrant FGV state machine that corresponds to each particular controller, set for pre-allocated clones.  Actually we have a few different types of controllers, so that would maybe lead to a Dyno-Dispatched set of methods... but I digress.

 

So the idea of One FGV State Machine To Rule Them All sounds good - maintain an array of controller states instead of a Plethora of clone FGV's.  So the 'Action' would need be accompanied by some identifier 'Which Controller' telling me which controller the Action needs to act on.  Nice.

 

Now, for me to stray away from an FGV architecture strains my brain a bit - I can't think of any better way... RE "Channel Wires", I have to run this code on some LV2015 -equipped machines sometimes, so I'll have to wait till we buy some new licenses before I dig in to those, I'm afraid.

 

Yes, indeed I do know that an Actor Framework is perfect for all this!  But I have to ship this system before I can learn that.  I promise - next project!

 

Again, a bazillion thanks to all of you guys who are so generous with your help! paul

0 Kudos
Message 23 of 25
(357 Views)

I suspect a *different* conceptual problem.  Each time you run your "test" vi, you're making new & different reentrant vi's for you to call by reference.  Instead, your test vi needs a loop so you can keep applying a series of actions to the same vi.  See attached.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 24 of 25
(346 Views)

OUCH! I'm desperately searching for a button that says "Forget I ever posted this, and wipe the memory of anyone who saw it".  Thanks Kevin, OK now forget! paul

0 Kudos
Message 25 of 25
(340 Views)