In the french part of NI Forum --> http://forums.ni.com/t5/Discussions-de-produit-de-NI/recherche-exemple-simple-sur-Actor-Frameworks/t... someone asked for a "simple example" of AF. For this purpose he asked to convert a QSM example (see attachment) in AF architecture. I've tried to do the job (see attachment).
It seems to work as it would but I'm encountering an issue that I'm not able to explain. Sometimes when I run Launcher.vi, data are not displayed in the graph despite of the fact that App.lvclassisplayData.vi receive data and no error occurs in the property node. When this behavior occurs the stop procedure doesn't work in App.lvclass:Actor Core.vi because StopSignal Val(Sgnl) event is not handle by the event structure. Nested actors are reserved and you need to close/open your project in order to continue to develop.
No issue video http://screencast.com/t/tOUuQPfb5
Issue video : http://www.screencast.com/t/UmzwHCqo
Message was edited by: Olivier Jourdan
I cannot fully explain what is going on but I have seen similar behavior.
It seems something gets messed up with the references to the controls when you make that change. So much so, that the Val(Sgnl) of the StopSignal control is not getting triggered. If you recompile after you make the change, it seems to be OK.
In addition, I would create a UserEvent for stopping the Event Loop in App.Actor Core.vi instead of using the Val(Sgnl) mechanism. I think that will get around the problem of stopping the actor.
I only know that forcing a recompile on the VI (hold control key and hit run arrow) will get around the non-updating controls. I have a feeling it is because of the clones left over in memory. Not sure how to destroy those progammatically.
Hope this helps.
This explains something I saw. In Actor Core, I wired a boolean terminal directly to the Loop Condition - and bundled the boolean reference into the actor. In Stop Core, a Value property did not always change the terminal's value.
Hopefully someone (read NI) can explain this or beter yet come up with a programatic way to avoid it like force a recompile of a VI on app startup. When I have Actors with UI's where I put the control refnums in the private data of the actor and I do not see the updates I expect, the first thing I do is force the recompile on that actor. I have not figured out what I do to cause the disconnect yet. Olivier's example was the first easy-to-replicate change to cause the failure. I had never seen the problem affect other non-related control refnums like his StopSignal boolean.
Kurt Grice wrote:
I would create a UserEvent for stopping the Event Loop in App.Actor Core.vi instead of using the Val(Sgnl) mechanism. I think that will get around the problem of stopping the actor.
I agree with Kurt. Using Value(Signaling) properties is not recommended as a way to send messages to an event loop. Sometimes I'll do it in prototype code, but I do my best to avoid it in any sort of real code. User Events are far better. (See Norm's post in this thread for one reason not to use them.)
As for the bug itself, I played around with it quite a bit and on rare occasions got it to manifest without doing anything to the front panel. The first time I launched a second parallel instance it failed. Another time when I started two instances as quickly as I could it failed. I couldn't reproduce either of them though.
Just chiming in to say I'm seeing the same behavior. In my case, it happens quite frequently though: I guess once out of 5 times I run my project, the front panel of my main Actor gets stuck — it seems the event loop doesn't respond to anything. I usually have to close and re-open the project to get things working again.
@daklu: LOL. True, that would solve the event problem, but the non-signalling update of the graph or any control is still dead.
@onnodb: I have not seen a total event loop failure. The control events from user interaction and user events have always worked. I rarely use Val(sgnl) and never to stop a loop in my actor framework.
I have seen similar behavior in Actor Core. One of the front panel indicators in the Actor Core was not updating. This indicator should have simply displayed a string by value, but it never updated! The issue was solved by renaming "Actor Core.vi" to "Actor Core.old.vi" and then copying the entire block diagram to a newly created "Actor Core.vi".
I would suggest re-creating the VIs which are experiencing these issues and submitting them to the forum so NI can investigate.
Um... at the risk of losing my CLA credentials... I think using Value(Signaling) is fine, especially when the property node is a statically linked propoerty node.
Here's my argument... please set me straight if there's something I've got wrong... events are neither my feature nor am I a full time G programmer, so there may be some pitfall out there that I'm unfamiliar with.
Value(Signaliing) didn't exist when we first added Events to LabVIEW. It was added later after a lot of debate because of its extreme utility in various situations. Can it be abused? Yes. But is it necessarily wrong? I claim no. Oliver, I have not looked at your code and I don't have time to do so today, so maybe you're abusing it there. Maybe it's a bad idea in this case. But a blanket ban? That's overkill.
When would I use Value(Signaling)? When *all* of the following are true:
1) The VI that has the control on its front panel is an actual end-user visible UI, so the panel already has a reason to load into memory
2) The VI that is firing the Value(Signaling) doesn't mind flipping to the UI thread.
3) The primary way of communicating with the target VI is already an Event Structure
The most common time when this occurs is when I have two loops on the same diagram of a dialog VI and one loop needs to signal the other loop. Doing this through a Value(Signaling) is easier than creating a user event, registering it, generating it and tearing it down again. I avoid dynamic registration when I don't have to have it because it creates a lot of code that just increases complexity. In the dialog VI case, there's no downside: most of the VI is already running in the UI loop, I'm not looking for high performance, and it doesn't risk open up a timing hole of having to figure out when to dispose of the user event refnum (something I've seen more than one programmer botch -- or they just leak it, which has its own downsides).