Actor takes two launches to receive data

[seanohue]

Hey everyone, I have to jump back into LabVIEW land again and I'm trying to expand on the functionality of an existing program. In the attached project, I have two classes called Scanner and Flashman. Scanner is the old class that works, Flashman is the new one that has a really confusing bug.

In Scanner Test.vi, I launch the Scanner actor and then do a Send Set_BMS message. This works as expected: BMS in the Scanner Actor Core gets set to 1. In Flashman_Test.vi, I launch the Flashman actor and then do a Send Set Flashman Config message and BMS/BMS Code never gets set to 1/Latest in the Actor Core. When I launch it again from Flashman_Test.vi, it works fine. If I close and reopen the Flashman_Test.lvproj, it requires two more launches for the data to get set in the Actor Core.

Is it because on the first launch, the references get assigned to the controls on the front panel so they're available on the second launch? The actors are shared-clone reentrant  so that would make sense but the Scanner actor does not exhibit this behavior.

Thanks ahead of time for any help on this!

[justACS · Accepted solution]

Scanner:Actor Core works as expected because it is properly parallelized.

In Scanner:Actor Core, the UI handling loop runs in parallel with Call Parent Node.  That means that your message handler can receive the message that updates the BMS indicator.  For the record, you don't need (and should delete) the sequence structure.

Flashman:Actor Core is not properly parallelized, because you have wired Error Out from your UI handling loop to the Call Parent Node.  Flashman is blocked from receiving any messages until your UI loop terminates.  Since it can't receive any messages, your UI elements never update.

You need to remove the error wire connecting the UI loop to Call Parent Node.

Unrelated, but important:  You need to modify this VI so that your UI loop is stopped by the message handling loop.  The UI loop should never stop itself.  When the UI loop hits a stop condition, have it send Stop to itself, and then use some other method to stop the UI loop.  Since it's a UI, I'd recommend using an event structure, and stopping the event structure with a (user-defined) stop event.  You can generate this event in an override of Stop Core, or just generate it after the call to the parent node.

[seanohue]

Thank you, that was the problem!

[AristosQueue (NI)]

niACS wrote:

The UI loop should never stop itself. 

I wouldn't say "never", but the architecture niACS proposes is more robust for larger scale situations.