Debugging Actors

[SJ_Buddy]

Hi AristosQueue,

We are using 64-bit LabVIEW. But there is no DETT for 64-bit. So we are stuck.

We have to cancel our AF adption due few major issues:

1. No debug tool

2. No way to monitor the queue to cleanup clogging

3. Class Property Dialog timout all the time.

Could you have some suggetions on those.

Best Regards,

[David_Staab]

SJ_Buddy wrote:

2. No way to monitor the queue to cleanup clogging

3. Class Property Dialog timout all the time.

I'm not AQ, but here's my response:

2. This is a design issue. The message queue is not a job queue, and you should take pains to pop messages from it as quickly as possible. Defer long-running tasks to a secondary queue or to dynamically launched workers. Don't execute those tasks in your message handler.

3. The load time for that dialog scales quickly against the number of classes in memory. It definitely needs to be tuned for better performance. But I haven't seen actual timeouts/hangs/crashes in the dialog since ~LV 2011. What version are you working with? Maybe it only crashes/hangs in LV x64?

[AristosQueue (NI)]

SJ_Buddy wrote:

We have to cancel our AF adption due few major issues:

1. No debug tool

2. No way to monitor the queue to cleanup clogging

3. Class Property Dialog timout all the time.

Staab gave the best answer to #2 -- avoid the need to do this. But in LV2013, there is a way to provide such filtering. You can override the Receive Message.vi for your actor and have it implement code to drop messsages that come too frequently. Generally, this is a bad idea -- the work involved is *exactly* the same as just having a handler for the *specific* message that you're filtering and is waaaaaaay safer. But some people really want to implement a filter. We didn't add this method in order to support filtering -- we added it to support network proxying and wrapping -- but you can use it for a filter if you really insiste on it.

Regarding #3: Like Staab, I haven't seen any timeouts/crashes with that dialog in several LV versions. We thought we had all of those fixed. If you are willing to share your code that replicates it, please open a service request with an application engineer so we can diagnose it. I have seen the dialog take a couple seconds to appear. It has a performance issue that is unfortunately very hard to address. It is requiring a fairly significant refactoring to make that work better and that refactoring won't be finished for a couple versions of LabVIEW yet.

Regarding #1: There are several approaches to debugging AF, not just the DETT. For one thing, the whole of AF is just VIs, so anything you've ever done with any other VI system works. Likely if you drop AF because of the debugging, you'll find yourself having the same difficulties with any other multi-process VI hierarchy that you create -- it's the nature of the beast. But we (the AF community of users, of which I count myself as one) also developed ways to dig into the AF code itself. The best in my opinion is the "Monitor Actor.lvclass" solution that was just a couple weeks ago posted to this forum: https://forums.ni.com/t5/Actor-Framework-Discussions/Monitored-Actors/m-p/3391964#57884

-- AQ

[SJ_Buddy]

Thanks a lot AQ for the detailed response. I hope you can help me to convince our group to revice AF adption.

#2: We have few very high speed DAQ+signal processing tasks in number of our projects running on PCs. I recomeneded our team to insert RT+FPGA to be able to handle perfomance btter. But, as ussual, we don't have enough people. So we have to stick with PCs. Classically I design 3-level loop with 2 queues between them. Lowest level just does acquisition. The second just do data processing and send commands to other sub-systems. And the last loop does GUI handling. I need to monitor the queue btween the lowest level and the second level to make sure I don't loose any data. The queue between the second and the last I just need to get the last queue element and drop the rest. When converting to AF I would like to have the same feature. I may look into modify AF at some point. I will look into LV2013. I just installed LV2013 last week but I have a quite distruptive problem with that I will describe below. Maybe, you can help.

#3: This is on LV2013 Known Issues list (245148 — Class Properties dialog sometimes throws timeout error 123 when opening and must be restarted). This issue is reaaly annoying. You never know when it is timeout. When I demo my project to our group, I got it timed out several times, that the whole group just voted no to adopt AF, just because of this. I already talked with an NI engineer and they said there is no time frame for the fix. So we just postponed our AF implementation after I spend nearly 6 months to convert one of my large projects to see if AF is fisible for us. I am using 64-bit LV2012SP1 on 64-bit Windows 7. Maybe, it has something to do with it.

#1: AND HERE I NEED YOUR HELP. I have been using "LabVIEW Task Manager" (created by Ravi Beniwal and modified by you). On LV2012 this one It is a great tool. I can see all the clone VIs and pop up BD to hightlight them. But last week I load it on LV2013, I can see only the original VIs. There is no clone is listed. Have you tried that VI with LV2013. Are you aware of any change they made in LV2013 which may cause thsi to happen. I will try "Monitor Actor.lvclass".

Best Regards,

[fabric]

AristosQueue wrote:

Regarding #3: Like Staab, I haven't seen any timeouts/crashes with that dialog in several LV versions. We thought we had all of those fixed. If you are willing to share your code that replicates it, please open a service request with an application engineer so we can diagnose it. I have seen the dialog take a couple seconds to appear. It has a performance issue that is unfortunately very hard to address. It is requiring a fairly significant refactoring to make that work better and that refactoring won't be finished for a couple versions of LabVIEW yet.

Well, you'll be excited to hear that I just had another one 🙂

Running LV2012SP1 32-bit (win7), project contains about 5000 VIs, and at least 300 classes are in memory at any time. (Sorry, can't share...)

Based on a suggestion from this thread I recently turned compiler optimisations down to zero, and I am separating compiled code throughout. Seems not to have helped with the timeouts... I still experience them around once every week or two...

[AristosQueue (NI)]

fabric wrote:

Well, you'll be excited to hear that I just had another one 🙂

Your definition of "excitement" and mine differ considerably.

*sigh*

I'll flag the team.

[AristosQueue (NI)]

SJ_Buddy wrote:

Are you aware of any change they made in LV2013 which may cause thsi to happen.

Yes. I am.

Clones are no longer numbered starting at 1. There was already a chance of that tool missing a clone because they weren't necessarily tightly packed, but a few good heuristics had that tool working well enough. But as I said in the discussion about that tool, we were using a workaround that was not ever intended to work and was kind of shaky.

Well, in 2013, it shook. To close a major performance problem with clones, their numbers were moved away from 1 -- this caused them to have names that hashed better and gave us amortized lookup speeds... as it was, the vast majority of clones were ending up tightly packed in various hashes. Adjusting the hashing algorithms themselves wasn't really an option for various reasons. I knew it would break that tool. I worked with the teams that implemented the change, but there just wasn't any other solution. The performance boost for all of LabVIEW was worth the loss of a tool that shouldn't have worked in the first place.

This is why I was so excited by the Monitored Actor approach. It solved the problem of the scatterred names elegantly. Alas, it only does so for the AF, not for clones generally.

Message was edited by: AristosQueue

[AristosQueue (NI)]

SJ_Buddy wrote:

#3: This is on LV2013 Known Issues list (245148 — Class Properties dialog sometimes throws timeout error 123 when opening and must be restarted).

Yeah. We thought we had fixed it but we left it on the known issues list because we weren't sure. Clearly our hesitation was warranted.

[drjdpowell]

Hi AQ,

Two questions:

1) is this related to the increasing time required to create/destrroy clones?  Going from 5000 to 5100 clones takes a LOT longer than going from 100 to 200.

2) any chance of a replacement for the ability to find clones?  A "List all clones" property?  A description of the new numbering algorithm?

-- James

[SJ_Buddy]

Hi AQ,

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?

Thanks,