From 11:00 PM CDT Friday, May 10 – 02:30 PM CDT Saturday, May 11 (04:00 AM UTC – 07:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 11:00 PM CDT Friday, May 10 – 02:30 PM CDT Saturday, May 11 (04:00 AM UTC – 07:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
07-19-2015 01:35 AM
Hi Siana,
When I started building the example, I didn't put ParentActor and I didn't see the bug. As I do have a parent actor in my code, I added it and the bug appeared, so I assumed it was necessary. However, removing the parent actor did not cause the bug to disappear, so I don't know why I didn't see it to begin with.
It didn't occur to me to block Launch nested actor until Launcher is done, thanks for the tip!
Thanks for looking into this
Danielle
10-28-2015 11:11 AM
We are working on this CAR. We have some questions:
When you are not using any PPLs, you say that everything works. We would like to know... is your Plugin1.lvclass in your project or not when you try this? We have started to suspect this morning that there's a weird interplay between dyanmic loading of classes and the ACBR node and automatically released VI Refs -- potentially the PPLs having nothing to do with it. If Plugin1.lvclass is listed in your project when you try this then it is *already in memory* and no dynamic load happens.
We are building our own test case this morning, but if you get a chance to try this yourself, please generate an all-source version of your project (i.e. no PPLs) and make sure that the plugin class is not in the project and then see if you get this same bug. Please post here if you get a chance to try this out.
10-28-2015 03:16 PM
Hi AQ,
I didn't try this with uncompiled plugins. However, if plugin1.lvclass was loaded before from a PPL, it is in memory, so the second run should have no problem as it doesn't dynamically load according to your post, yes? However, as I remember, it always caused this problem even if plugin1 was in memory, so maybe I don't understand correctly.
I'm sorry, but I've changed job and no longer have access to the code (it was proprietary). But I'll let my colleagues know
Thanks,
Danielle
10-28-2015 03:30 PM
Definitely does not occur if the plugin is already in memory... we've verified that several different ways. Two workarounds:
a) Don't let Launcher quit
b) Let Launcher start Coordinator and then wait for Launcher to quit before Coordinator loads Plugin.
10-28-2015 03:34 PM
Thank you!
So far we are using the first workaround - not letting the launcher quit. But it's good to know there's another option.
Thank again for looking into this!
Danielle
10-28-2015 03:42 PM
Have you (or anyone else) tried this in LV2015? We're doing our initial dive in 2014 but figured I'd ask just in case this has been fixed. There are a couple of bugs fixed in 2015 that might be relevant (though admittedly none that are directly on point).
10-28-2015 04:05 PM
I haven't and I'm sure my colleagues haven't either. Sorry.