Skip navigation

Community

1 2 Previous Next 4211 Views 24 Replies Latest reply: Jun 15, 2012 11:01 AM by Q7 RSS
Olivier Jourdan Calculating status...
Currently Being Moderated

Mar 23, 2012 11:41 AM

Event issue

In the french part of NI Forum --> http://forums.ni.com/t5/Discussions-de-produit-de-NI/recherche-exemple-simple-su r-Actor-Frameworks/td-p/1921915 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.lvclass:DisplayData.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.

 

  1. I'm not sure that this issue is AF related
  2. Does anyone can reproduce it (the easiest way I found to get the issue is to modify the AutoScaleX property in App.lvclass:Actor Core.vi before runing Launcher.vi )
  3. If so what I am doing wrong

 

Thanks,

 

Olivier

 

 

 

No issue video http://screencast.com/t/tOUuQPfb5

 

Issue video : http://www.screencast.com/t/UmzwHCqo

 

Message was edited by: Olivier Jourdan

Attachments:
  • KuGr Calculating status...
    Currently Being Moderated
    1. Mar 23, 2012 2:50 PM (in response to Olivier Jourdan)
    Re: Event issue

    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.

  • Todd_Lesher Calculating status...
    Currently Being Moderated
    2. Mar 23, 2012 4:31 PM (in response to KuGr)
    Re: Event issue

    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.

  • KuGr Calculating status...
    Currently Being Moderated
    3. Mar 23, 2012 5:02 PM (in response to Todd_Lesher)
    Re: Event issue

    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.

  • Daklu Calculating status...
    Currently Being Moderated
    4. Mar 24, 2012 1:03 AM (in response to KuGr)
    Re: Event issue

    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.

  • Daklu Calculating status...
    Currently Being Moderated
    5. Mar 24, 2012 1:05 AM (in response to KuGr)
    Re: Event issue

    Kurt Grice wrote:

     

    or beter yet come up with a programatic way to avoid it

     

    Don't use Value(Signaling)? 

  • onnodb Calculating status...
    Currently Being Moderated
    6. Mar 24, 2012 1:44 AM (in response to Olivier Jourdan)
    Re: Event issue

    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.

  • KuGr Calculating status...
    Currently Being Moderated
    7. Mar 24, 2012 7:13 AM (in response to onnodb)
    Re: Event issue

    @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.

  • LVB Calculating status...
    Currently Being Moderated
    8. Mar 24, 2012 7:24 AM (in response to KuGr)
    Re: Event issue

    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.

  • Currently Being Moderated
    9. Mar 25, 2012 3:24 PM (in response to LVB)
    Re: Event issue

    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).

     

    Comments?

  • Currently Being Moderated
    10. Mar 25, 2012 3:26 PM (in response to LVB)
    Re: Event issue

    LVB wrote:

     

    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.

    I would *strongly* agree. Please package up your VIs and send them in to an AE to open a bug report. (Normally I'd accept them through this channel for an AF bug, but this doesn't sound like a bug with AF but a more general panel-not-updating bug, and so that needs to go through the AEs who may already know a workaround and/or know who the right person to send that bug report to.)

  • Daklu Calculating status...
    Currently Being Moderated
    11. Mar 25, 2012 8:13 PM (in response to AristosQueue)
    Re: Event issue
    AristosQueue wrote:

    Comments?

     

    Well... if he *hadn't* used Val(Sgnl) he would be done with the project and we wouldn't be having this discussion.    In the world of tight timelines and fixed bid projects that seems like a pretty big reason to not use them.

     

    I know there are a lot of people out there using Event based messaging systems.  I've seen enough discussion about problems with Events I'm not comfortable using them for critical messages (like "stop.")  There are just too many ways to shoot yourself in the foot with them.  Plus they tend to create a lot of dependencies I don't want.

     

    Queues are easy to understand.  They're predictable.  I can trace the wire.  I can drop a Status function if I want to see what's going on in the queue.  I can check queue refnums to make sure they're the same.  I can work through almost any problem I might encounter.  Events--even user events--don't offer nearly the level of debugging capability or extendability as queues.

     

    Labview doesn't have a great way of sending messages to an Event loop.  This is what I do when I need to send a stop message (or any number of arbitrary messages) to my Event loops.  It's not as nice as queues, but it's the safest way I've found to connect Event loops with the rest of my system.

     

    AppActor.lvlib_App.lvclass_Actor Core_BD.png

     

     

    AristosQueue wrote:

     

    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

     

    I agree 1 and 2 are required conditions before I'll consider using Value(Signaling).  I'd also add two other conditions:

     

    3) The control being signalled is already on the UI for the purpose of user interaction.  (Olivier's code has a hidden control on the fp just so there is something to signal.)

    4) The Event loop doesn't have a message receiving system and I can't spare 3 mintues to implement it.

     

    As for the item I scratched out, I don't make events the primary way to communicate with *any* parallel VI for the reasons I stated above--only queues.  If an Event loop needs to receive a message from an external source I'll use a mediator loop to receive the external message, package it in a user event, and forward it to the Event loop.  Normally the Event loop's messages are abstracted away from the VI's messages enough that it doesn't make sense for the Event loop to receive external messages directly.

     

     

    AristosQueue wrote:

     

    I avoid dynamic registration when I don't have to have it because it creates a lot of code that just increases complexity.

     

    I don't think setting up and tearing down a generic user event for an Event loop to receive messages on is appreciably more complicated than setting up and tearing down a queue for message handling loops.  Fundamentally it's the same thing, it just looks a little different.  But maybe that's just because I'm used to it...

     

     

    AristosQueue wrote:

     

    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).

     

    It's only hard to figure out when to dispose the user event refnum if multiple Event structures are registering for the same event.  A generic user event is a (less capable) queue.  Dispose of it when the Event loop exits.  If you have an advanced use case where the Event structure needs to register for externally created user events you can wrap it in a message and have it register in the message handling case structure.  In those cases I expect the user event refnum would be released when the event generator loop exited.

     

    I *do* agree there shouldn't be a blanket ban on Val(Sgnl) events.  Ultimately the "right" solution to any problem is one that meets the business needs.  Val(Sgnl) is a potential solution when time is short.  I'm not ready to grant it the status of a "good" solution; it's just an "adequate" solution when requirements demand it.  (In other words, I consider it code debt.)

     

    -Dave

     

    [As always, these are just my current opinions on the subject.  They may change before I wake up tomorrow morning.]

  • Daklu Calculating status...
    Currently Being Moderated
    13. Mar 27, 2012 12:06 AM (in response to Olivier Jourdan)
    Re: Event issue

    You bring up a good point Olivier.  Our coding practices are heavily influenced by our coding philosophies.  I admit my coding habits are likely more defensive than the majority of the community.  I don't do it for the sake of academic purity; I do it because I've found I can create better products in less time when I follow certain practices.  YMMV.


    "We can think that the layers under the "Value Signaling" are similar as layers used for managing "User event"."
    Val(Sgnl) is a static event.  User events are dynamic.  They use different queues under the hood.  (This is one of the many complexities of events that you don't have to worry about when using a queue.)


    "How we can be certain that this behavior cannot be reproduced with user event?"
    I downloaded your code again and timed myself while replacing the Val(Sgnl) with a simple string-based user event.  It took less that 2 minutes to make the change, and I'm a slow coder.  The problem with App.ActorCore not shutting down went away.  It shut down reliably every time.  It didn't solve *all* the problems, but it did solve that one.


    "Even if ValueSignaling is not "the best" solution, I don't understand why it's not working in my project... Nobody gives me a reason for this behavior, you are just telling me that it's not the solution."
    We don't know exactly why it is happening.  For some reason the static references are getting messed up.  It's not just the StopSignal button; it's the Waveform Chart reference too.  That's why there aren't any data updates on the actor when it won't shut down correctly.  I can't say why the static references are getting mixed up.  I attached a debugger to the refnums and it looks like they are consistent.  It's obvious LV reuses the clones in the dev environment--often when launching the actors the waveform chart still has the data from the previous execution.  Maybe something is getting mixed up there.  Just guessing though.

     

    On the other hand, I can't rule out the possiblity of race conditions in your code either.  My gut feeling is we're seeing the effects of several different things.  Here are some potential reasons the app is not behaving as you expect:

     

    1. You're using the Panel Close event to send a Stop message from App.ActorCore to the AcquisitionActor.  It's usually not a good idea to start shutdown processes with that event.  (Check LV's help for the big red warning.)  I don't remember all the details about Panel Close, but I do remember there were some unusual things that could happen with it.  To be fair, switching it to Panel Close? and discarding the event still caused some odd behaviors.  Different odd behaviors, but odd behaviors nonetheless.

    2. You have circular static dependencies between your libraries.  (Read "-->" as "depends on.")  App actor --> Acquisition actor --> Process actor --> DisplayData msg --> App actor.  Will that prevent something from shutting down and unloading?  I don't know, but circular dependencies are always a point of concern for me.  (Besides, circular dependencies between three different libraries defeats the purpose of having them in different libraries.)

    3. Your actors aren't monitoring the shutdown process of their subordinate actors.  They're just firing off a Stop message and shutting themself down.  Controlled shutdowns can't be an afterthought.  I don't have any of my actors shut down until it has received confirmation from all of it's subordinate actors that they have shut down.  I believe the AF uses the LastAck mesage for that, but I'm not certain how to implement it.

     

    Does it take time to write controlled shutdown processes?  You bet.  Considering I've spent less time writing controlled shutdowns for my last four projects combined than I've spent trying to figure out why this project doesn't shut down, I figure it's time well spent.  Are any of those three things contributing to the problems we're seeing?  I honestly don't know, but I can't rule them out, and that means (assuming it were my project) I have to spend time investigating them.


    "Code I've developed is largely "inspired" from the best and clearest AF I've found."
    To be honest I think there is a huge hole in relevant material for learning how to design actor-oriented systems.  The examples I've seen focus on the implementation, not the principles and design considerations.  I'm developing some material that hopefully will be

1 2 Previous Next

More Like This

  • Retrieving data ...

Bookmarked By (1)