AF SubPanel Messaging Not Working

[Be-lock-eh]

The problem is you can't highlight execution OR probe a wire in your actor core. It is one of the maddening things about using actor framework. But there are enough advantages I still prefer using it. Sometimes I feel a little blind though not being able to probe the core. I think the only standard debugging thing you can do in the core is put a breakpoint. If I had suspected an error in my helper loop, I probably would already have figured out the solution. I was looking in the wrong place and since my error handling wasn't very good in the core I was unable to see I had a problem there.

So here is what I've changed it to now.

[cbutcher]

You can probe the Actor Core, as Dr Powell described - if you right click on your subpanel (the empty panel) and tick "Allow User to Open Diagram" then when you run the VI and insert the subpanel, you can right click on the panel and choose "Open Block Diagram". This will open the specific clone that is running, which you can then freely probe.

An alternative I sometimes use is to place the following code somewhere near the beginning of my problematic shared-reentrancy VI. If it doesn't pause exactly where you want, you can place the pause before the FP.Open, but I have no idea how that works...

This requires that Scripting VIs be shown, under the Tools > Options menu (VI Server tab). Or at least, it requires that they be shown in order to select the blue node. Probably it still works even if you later hide them again.

[Be-lock-eh]

Oh awesome thanks! I had no idea you could probe the sub panel like that and see the actor core. That's a neat trick. Thanks and sorry Dr Powell I misunderstood what you were suggesting

[AristosQueue (NI)]

There's a far simpler way to open the reentrant clones!

View >> Browse Relationships >> Reentrant Items

For any reentrant VI, that will show you a list of all the existent clones of that VI. You can pick which one to open. It doesn't tell you which is which, but usually there aren't that many, and if there are, you can look at the call chain ring on the block diagram to figure out which is which.

[AristosQueue (NI)]

---

alsoACS wrote:

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.

---

alsoACS: Did we add a trace message to Drop Message? If not, should we to differentiate the case where the message was never sent from the one where it was sent but not received (because the receiver quit before that message arrived)?

[alsoACS]

---

@AristosQueue (NI) wrote:

---

alsoACS: Did we add a trace message to Drop Message? If not, should we to differentiate the case where the message was never sent from the one where it was sent but not received (because the receiver quit before that message arrived)?

---

Drop Message.vi generates a trace.  I should probably note that in the course.