Debugging Actors

[AristosQueue (NI)]

SJ_Buddy wrote:

About the VI clone change, could you provide more infomation. It is pretty big change, how come it is not mentioned in the LV2013 release notes?

Don't know why it isn't in the upgrade notes. I'm guessing that this was classified the same as a change to behavior in a private scripting function -- we don't document changes to private features; we don't document changes to undocumented backdoors that weren't supposed to work in the first place. But that's just a guess.

I have attached a VI that, given an non-clone VI name, generates the Nth clone name. You can use that to restore the functionality of the debugging tools.

[LVB]

It would be nice if there was a VI server method that returned what VI's are "actually" running.

[AristosQueue (NI)]

Write a VI that gets all the VIs in memory and asks for their execution status.

[fabric]

Thanks.

Some observations that may help:

• When I first open my large project I don't seem to experience timeouts with the class properties dialog
• If I make "normal" edits to code then I don't seem to experience timeouts
• BUT - If I copy an existing class then the IDE thinks for a LONG time before finally complying, and then I often seem to experience timeouts
• Creating new classes also seems to encourage timeouts
• The timeouts seem to be persistent: Once they start, then they don't seem to stop. This generally leads me to reopen the project, which generally restores my ability to access the class properties dialog.

Gut feelings:

• Seems to occur after at least one successful access to the properties dialog (with dev work in between)
• May be related to unsaved classes in memory
• Exacerbated by nesting classes in lvlibs
• Not particularly repeatable...

[SJ_Buddy]

Hello,

Between previous and this message, I got LV timed out about 8 times, crashed 3 times 🙂 :-((.

Anyway, I agree with fabric on the failure conditions. But I am getting it sometimes just after loading my project.

Maybe, we need to have separate thread on this? It is realy killing my productivity.

Thanks,

[SJ_Buddy]

Hi AQ,

Thanks a lot providing the VI. I looked at the VI description:

USE WITH CAUTION.  The name returned by this VI can be used with the "Open VI Reference" function to open a VI reference to a clone VI. This is an unsupported feature of LabVIEW (i.e. opening an additional reference to a clone VI was never intended to work but someone forgot to disable it when clones were added to LabVIEW). Opening extra references beyond the one used to create the clone (i.e. the clone's "this VI" reference) is known to cause instabilities, including crashes, in some situations. However, such refnums are critical for writing certain debugging tools. Be careful.

Do you mean that this capability maight get disabled in the future without warning?

Thanks,

[SJ_Buddy]

Hi AQ,

I have another question about being able to highlight execution. Basically, you can say that we need to discourage developers to use highlight execution once we got in to AF. My team members are very much into the highlighting thing. They are very relactant to switch to anything which strips away that capability. When I found the Task Manager from Ravi Beniwal I thought I have found solution to win their suport in adopting AF. But as we are not sure that feature will be "supported" in the future. I have to find another solution.

Os there any other way for us to run VI with highlight code execution?

Best Regards,

[drjdpowell]

we need to discourage developers to use highlight execution once we got in to AF.

Highlight execution is a problem anytime you have independant VIs communicating with each other.  You slow one to a crawl while leaving the others at full speed and this will hopelessly mess up the system.  BUT, with independant VIs you also have the option of having "test harnasses" that start up modules and test them independantly.  Then you can use highlight execution, because you are only dealing with one process.  With the Actor Framework, you can also run tests on the Actor objects themselves (without "Launching" them into Actor Core).  Testing things in isolation before combining them in a complex system is good practice.

-- James

[AristosQueue (NI)]

> Do you mean that this capability maight get disabled in the future without warning?

Yes, although I would hope if it happens again it would be in the Upgrade Notes. But no guarantees that there will be a workaround next time.

The problem is that opening a secondary VI ref to a clone VI is totally not supported in LabVIEW. In fact, clones were designed on the assumption that there was no way to get such a secondary refnum. None of the people who worked on it thought about the Open VI Reference by name trick. Clones with multiple refs to them are unstable, and making them stable would require sacrificing a lot of clone VI performance (I don't know the details of why). Since it is undocumented and undesigned for, it is kind of slated as a "bug to be fixed", but I've generally convinced people to not make "fixing" it a priority because of its value for these debugging tools. But it is one of those areas where if a real issue arises (like the performance issue fixed in 2013), this might get impacted.

[AristosQueue (NI)]

SJ_Buddy wrote:

I have another question about being able to highlight execution. Basically, you can say that we need to discourage developers to use highlight execution once we got in to AF. My team members are very much into the highlighting thing. They are very relactant to switch to anything which strips away that capability. When I found the Task Manager from Ravi Beniwal I thought I have found solution to win their suport in adopting AF. But as we are not sure that feature will be "supported" in the future. I have to find another solution.

Why do you have to step away from execution highlighting? It works on all the member VIs of the AF. If you mean you step away from it when a message is sent from a sender to a receiver, that's true, but that's no different than trying to debug any other producer/consumer loop system.

Also, when you do your testing, don't try to spin up all your actors at once. Build yourself a good test harness for each actor independently, using the "Init Actor Queues FOR TESTING ONLY.vi" found in the Actor Framework >> Advanced palette. You can read about this VI in the white paper. That allows you to make direct subVI calls on your actor for the purposes of testing its behavior given different method calls, avoiding the enqueue layer.