From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

AF SubPanel Messaging Not Working

Solved!
Go to solution

Hello,

For a project I'm working on I decided to give subpanels a try. I naturally thought the best way to use the subpanel would be to have different "panel" actors my main actor launches and then send a message to each nested actor when it is time to insert itself into the subpanel. When I do this, the overridden actor core of the nested actor indeed shows up in the subpanel but I'm having some problems. I have events set up for my nested actor in a helper loop in the actor core. These events at first seemed to be not responding but I found if I put a one button prompt inside the events, they were indeed firing. The messages though that I'm having the nested actor send itself in each event however for some reason are not being sent to the core. I am using MGI's monitored actor and when I enable logging I can see the messages are not logging (except there was one time I got a message to show but other than that I haven't seen a single message log. The fact I saw one makes me wonder if there is a race condition somewhere but I don't see how there could be.).

 

When I test the nested actor alone with its own launcher it runs perfectly, but once I insert it into the subpanel it doesn't seem to be able to message itself.

 

I put a simple error handler right before the "call parent actor core" inside my overridden actor core and there are no errors that could be stopping the core and if there where my user event should fire to let me know.

 

I don't know what the problem is but this bug is driving me crazy. Any help would be much appreciated.

 

I've attached my code. The "Scope Station Main" is the main actor that launches the "Config Panel" nested actor. Right after launching the Config Panel actor it sends it a message with the reference to the subpanel telling the config panel to insert itself into the subpanel. This lets the Config Panel initialize before inserting itself into the subpanel.

0 Kudos
Message 1 of 16
(9,536 Views)

Your code has too many third party dependencies for me to easily load it (I'm not keen on installing all of the MGI packages).  Can you pull out a subset that doesn't have the dependencies, but still shows the problem?

 

I was (briefly) able to get something running, and I inspected the message traffic using the Desktop Execution Trace Toolkit.  It looks like the message handler in your Config Panel actor core (the Call Parent Node) is no longer dequeueing messages.  That will happen if it hangs on a message or just quits (likely due to error).

 

Get me a clean copy that shows the problem, and I'll take another look.

0 Kudos
Message 2 of 16
(9,489 Views)

I also see that messages are being sent to the Configuration actor but nothing is being dequeued.

 

However, if you send messages from the root actor into the nested Config actor, those will be dequeued and handled properly. You will also see the same behavior if you change all of your actors to inherit directly from Actor.lvclass instead of Monitored Actor so there's no funny business there.

 

2017-09-05 16_23_40-Config Panel.lvlib_Config Panel.lvclass_Actor Core.vi Block Diagram on Scope Sta.png

 

The above shows the Config Panel actor core in case ACS is having trouble opening anything. In this case Config Panel inherits directly from Actor and hitting cancel will send a message which isn't received. Meanwhile the root actor can keep on sending the same message to this actor which gets received. The Init function doesn't touch the actor's enqueuer.

Matt J | National Instruments | CLA
0 Kudos
Message 3 of 16
(9,478 Views)

Thank you both for looking at my code. This is stumping me pretty hard. I've attached a version with the MGI library removed. I also added a case to the main actor where if you press the "Start Test" button it sends the "insert into subpanel" message to the Config actor and via message logging I can see it is sending successfully. I don't understand how the Config enqueuer could be failing to enqueue. I don't see any errors or anything hanging the core.

0 Kudos
Message 4 of 16
(9,470 Views)
Solution
Accepted by topic author Be-lock-eh

Wow I found my problem.

First my error handling of the helper loop was wrong. I needed something to catch the error and stop the helper loop and actor core so I added an or statement to the stop button on the while loop feeding it the event wire and put a case structure after the event structure to send a normal stop if an error is encountered. Because I wasn't stopping the top loop with an error I didn't see that I had an error on the wire in the top loop preventing any of the messages from being sent.

Now to the source of the error:

I have two events in the Config event structure to handle a "Mouse Enter" and a "Mouse Leave" to change the cursor to a pointer finger when the user has their cursor in the table. For some reason this is not playing nicely while in the subpanel. This worked perfectly launching the Config Panel actor alone, but when in the subpanel it throws a null window error on the built in "set cursor.vi" used to set the mouse cursor.

 

 

0 Kudos
Message 5 of 16
(9,466 Views)

@Blahe

Good catch. As always, it seems so obvious after the answer is found.

 

@ACS

Would you consider it a bug that a message sent trace is generated in the error case where no message is actually sent?

Matt J | National Instruments | CLA
0 Kudos
Message 6 of 16
(9,451 Views)

@Blahe wrote:

Wow I found my problem.

First my error handling of the helper loop was wrong. I needed something to catch the error and stop the helper loop and actor core so I added an or statement to the stop button on the while loop feeding it the event wire and put a case structure after the event structure to send a normal stop if an error is encountered. Because I wasn't stopping the top loop with an error I didn't see that I had an error on the wire in the top loop preventing any of the messages from being sent.


 


Instead of doing that, consider using the Report Error message to pass any error to the message handler, and then deal with the error in Handle Error.  Typically, helper loops shouldn't self-stop.  You can find Send Error Report.vi on the AF palette.  It's a normal message that any actor can receive.  It takes an error cluster as data, and merges that error onto the error wire in the message handling loop.  Handle Error will catch that error and stop the actor (or whatever you specify in an override of Handle Error), which should then stop your helper loop.

0 Kudos
Message 7 of 16
(9,436 Views)

@Jacobson-ni wrote:

 

@acs

Would you consider it a bug that a message sent trace is generated in the error case where no message is actually sent?


The "actor sent message" trace gets sent when Enqueue is invoked.  You should see a corresponding "actor received message"  trace.  If the second trace is absent, then the message wasn't delivered, and you can assume a failure in the message transport.  But the sender *tried* to send the message, which is what the trace means.

 

So no, I don't think it's a bug.  I might concede that it isn't the most inclusively worded message, but we don't want those trace messages to get too long.  And since there are only a two possible causes for not seeing a receive trace (queue is bad, or queue is seriously backed up/recipient has hung), I'm not really worried about it.

Message 8 of 16
(9,434 Views)

@Blahe wrote:

Because I wasn't stopping the top loop with an error I didn't see that I had an error on the wire in the top loop preventing any of the messages from being sent. 

 


Question: why didn’t you see the error via probing the wires?   If I had this problem, my first actions would be:

1) right-click on subpanel and “Open Block Diagram"

2) turn on “Retain Wire Values"

3) exercise the UI a bit

4) hover over the wires in the event loop and look at the values

5) see the error

 

This seems a much more direct and quick way to debug LabVIEW code than consulting any kind of logging, so I am wondering what prevented you from going this route.

0 Kudos
Message 9 of 16
(9,427 Views)

@alsoACS wrote:

@Blahe wrote:

Wow I found my problem.

First my error handling of the helper loop was wrong. I needed something to catch the error and stop the helper loop and actor core so I added an or statement to the stop button on the while loop feeding it the event wire and put a case structure after the event structure to send a normal stop if an error is encountered. Because I wasn't stopping the top loop with an error I didn't see that I had an error on the wire in the top loop preventing any of the messages from being sent.


 


Instead of doing that, consider using the Report Error message to pass any error to the message handler, and then deal with the error in Handle Error.  Typically, helper loops shouldn't self-stop.  You can find Send Error Report.vi on the AF palette.  It's a normal message that any actor can receive.  It takes an error cluster as data, and merges that error onto the error wire in the message handling loop.  Handle Error will catch that error and stop the actor (or whatever you specify in an override of Handle Error), which should then stop your helper loop.


Thanks for tipping me off to the "Send Error Report.vi". I went ahead and implemented that and just tested it with a dummy error and it works wonderfully. I'm always open to learning new/better ways of doing things.

0 Kudos
Message 10 of 16
(9,414 Views)