Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview freezing during Actor loading

Our application launches many Actors based on the request of the user. Each time the user requests a new Actor, whose class is not in memory yet, all VI's currently exciting appear to halt until that class and all related classes have been loaded into memory. This can cause serious timing issues for example, if the operator is currently running a script using the currently loaded Actors, when a new Actor is launched.

Other than deliberately loading all classes that could be called into memory when the first actor is launched, is there anyway of overcoming this? (i.e. is there anyway to load an Actor without freezing all the other executing LabVIEW code?)

Thanks,

John

Message 1 of 10
(7,447 Views)

John,

 

Without a good understanding of why LabVIEW is freezing, the only options that I can think of would be to load into memory all actors that you may need, as you have proposed already, or have some manager which would not allow these scripts to run at the same time a class is being loaded. If we can understand why LabVIEW is freezing (which I would say is not expected) we may be able to come up with a better solution. If that is something that you would like to look into, I would be interested in the following.

 

For starters, just to make sure I understand what you are currently doing, are you loading these actors using the Get LV Class Default Value.vi? If so, are you seeing LabVIEW freeze only when that VI is running and everything seems to function as expected afterwords? About how long is this freezing for? Do you see your CPU usage spike when this is happening?

 

In regards to the freezing behavior, are you sure that all of LabVIEW is freezing or could it just be that the UI thread is being held? I think that it would be interesting to turn on the AF Debug token and using DETT to see if messages are still being sent and received when a new actor is being loaded or if that is all stopping. I think if you were to try that it would a good idea to add a new user-defined trace right before you load a new actor and then add a simple time-delayed message which you can use as a sort of heartbeat. The time-delayed message is its own process so I wouldn't expect that to stop unless LabVIEW is actually hanging.

 

I also believe that we have some of your code which throws error 1003 when built into an executable. Would we be able to use any of that code to reproduce the same behavior that you are seeing here?

Matt J | National Instruments | CLA
0 Kudos
Message 2 of 10
(7,390 Views)

Hi Matt,

Thanks for the response and interest!

 

We have considered both of those workarounds, but neither is ideal. Loading all the classes at the beginning would defeat one of the goals of the architecture (to have a program that can do everything for the lab, but only load what the user needs at the time) and consume unnecessary memory, as well as significantly increase the time it takes to launch the application initially.

 

Preventing loading new classes during script execution would be quite easy to implement as we already have management processes in place that could be modified for that purpose. However, some of our environmental tests (which could be controlled by script) last for days, so we would be unable to launch any more actors in that time. So hoping for a better solution.

 

Yes, we are loading the actors using the Get LV Class Default Value.vi.

 

I am 99% certain that it is that VI that is executing when LabVIEW freezes. We stopped using DETT some time ago, as were unable to use it to debug our application once it was deployed as an executable and other reasons. Instead we have created a similar process that tracks all the messages sent/received, actors created, debug events, etc. It is using the output of this process (Event Manager), that I found this issue.

 

Generally we see between 20 - 1000 events per second depending on how many processes are running and what they are doing. Shortly after the message that calls the Get LV Class Default Value.vi is received (LaunchCmpnt Msg), all events stop and don’t resume until the new actor is launched (which is also done by the same message that creates the new actor object). When loading one component this took 14 seconds, with another (that has smaller classes) it took 9 seconds.

 

This problem only happens the first time the actor is launched after the application has started running. If we close the component actor (leaving the base application running – which would keep actor class in memory), and re-launch it, the time to create the actor object and launch the actor is less than 10ms. This tells me that this freezing is occurring when then class is being loaded into memory, not when the object is being created. Also, this problem only happens in the executable, not in the development environment, which supports this hypothesis since the all the classes are loaded into memory when the project is opened.

 

I have attached two snippets from our event file that show this. One is for the first time the actor is launched, the other for when it is re-launched within the same program execution. The second column is the output from the High Resolution Relative Seconds vi. In both I have highlighted the message that creates the actor object, and the event that indicates the new actor has been created. In both cases, there are many time delayed messages running initiated by other actors that are running at that time, and as you can see, everything stops.

 

To be 100% certain it was the GetLV Class Devault Value.vi, I would need to rebuild all the components required for this (after adding debug event generation code around that vi), which would be hours of work, and don’t have the time just now. But for the next release I can add that.

 

There is a noticeable increase in CPU usage during this time, however none of the CPUs rail.

 

Regarding the old code… I would imagine it would show the same problem, but of course won’t know till that 1003 error is fixed that is preventing the executable from running, as this problem is only seen with the executable. However, I’d be happy to upload our latest code if you are interested.

 

Thanks,

John

0 Kudos
Message 3 of 10
(7,374 Views)

It might be worthwhile uploading any code which can reproduce this behavior. I took some time to try and reproduce what you are seeing with a very simple project which I attached but wasn't seeing all of LabVIEW freeze. I am seeing the UI stop updating, which is expected, but my other processes are still running.

 

In my test project I have a top level VI "Launcher.vi" which starts "Root Actor.lvclass" and will then wait until the user either exits the application or clicks a load class button which will get the default class object from a target path. All the root actor will do is send a time-delayed message to itself every 100ms which will just increment a FP indicator. I attached a .gif of the application running as well as the DETT log and you can see that while the FP will stop updating during the load process, messages are still being sent and received.

 

I am still suspecting that we're just seeing the UI thread being hogged and not LabVIEW freezing (which I don't think we can do anything about) but there could be something else in your application that I'm missing.

Matt J | National Instruments | CLA
0 Kudos
Message 4 of 10
(7,357 Views)

I tried running your code but unfortunately, we are still using LV2015 so was unable to open it. I suspect that the reason you didn’t see the same problem was because your classes are very small and very few, so are loaded very quickly. When we load a component, this involves several actors each of which has many methods, and dozens of message classes.

However, I managed to reproduce the problem in the development environment… simply by removing the dynamically called actors from the project (should have thought of that before!).

I have attached the DETT output and a screen shot of the DETT output at the time when the component was launched (it’s a big file, and most of the vi names are missing as they are buried in a PPL so a bit hard to navigate). As you can see, in this case everything stops for about 14 seconds.

Unfortunately, my company won’t let me share the code publicly so I can’t upload here, but I can upload to the NI ftp site and send you the password privately… perhaps I should start a service request?

I will be away on vacation for the next two weeks so my reply will be delayed.

0 Kudos
Message 5 of 10
(7,340 Views)

If you can't share any of the code publicly, it would probably be best to start a new service request when you get back from vacation.

 

Let me know when you get back and until then I hope you have a relaxing vacation.

Matt J | National Instruments | CLA
0 Kudos
Message 6 of 10
(7,325 Views)

Thanks Matt!

Vacation was great (but not relaxing... I have three kids!) I have put in a service request.

John

0 Kudos
Message 7 of 10
(7,269 Views)

Was a root cause / solution ever found for this case? 

I'm experiencing something similar in a large project that calls not into actors but just generally a class / ppl based project.

0 Kudos
Message 8 of 10
(934 Views)

I don't know if a root cause was ever found but I have seen dynamic actors being launched via the Get LV Class Default Value vi. that caused the application to hang if the actors were not already in memory.

 

One thing you can try is to set the option input on the vi to 20 hex.....this will ignore the dialog pop up that LabVIEW is searching for missing dependencies. 

 

It will not stop the dialog pop up asking for the path to the class if it cant find it in your project.

Steven Howell
Controls and Instrumentation Engineer
Jacobs Technologies
NASA Johnson Space Center
0 Kudos
Message 9 of 10
(914 Views)

I don't get that pop-up in an EXE, so that's not a huge concern.  It's more about the fact that LabVIEW just seems to hang when loading them... especially if it has a larger dependency tree.

 

Not a super pleasant user experience in general, and would even prevent something like lazy loading things you expect to be called in the background, because it just freezes everything while the load is happening.

0 Kudos
Message 10 of 10
(906 Views)