Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

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

0 Kudos
Message 11 of 25
(1,456 Views)
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.]

0 Kudos
Message 12 of 25
(1,456 Views)

Hey, thank you for all replies.

I didn't think about that debate on Value signaling when I posted this messages. I'm going to try to add my stand point on the topic. As it's almost philosophical, feel free to ask me some complement if I'm not clear.

  1. Code I've developed is largely "inspired" from the best and clearest AF I've found.
  2. If I agree that we must avoid the usage of Value Signaling to implement the logic of the nominal application actions, I like (when it works ) this simple and easy way to exit the event loop. As a side note, I'm currently evaluating AF to promote or not promote it internally. There are already lots of topic like OOP by value that could be a difficulty in the adoption of the AF. Having to implement User Event just to Exit the AF should be another one which I don't want to fight with. I have to demonstrate that AF is an easy to use framework that allow developers to deals with customer problem not with architecture problem.
  3. Even if ValueSignaling is not "the best" solution, I don't understand why it's not working in my project (I'm not used to use "feedback nodes/globals/put everything in the list" but as far as I know they have to work as expected if they are available in LV). Nobody gives me a reason for this behavior, you are just telling me that it's not the solution. How we can be certain that this behavior cannot be reproduced with user event? We can think that the layers under the "Value Signaling" are similar as layers used for managing "User event".
  4. It seems that the bug is not related to the AF, but I have to confess that I've "often" encountered issue when stopping AF examples like Angry Eagles or MVC demo from Elijah in the large app community group (does anyone remenber of things like that or am I the only one?). I've never try to reproduce and found the origin because of time lack. Now, I start to think that it could be something related since I came across the issue on my first attempt to use AF. I have to be confident in the AF to use it in real world app that's why I have to understand why my snippet doesn't work as expected.
  5. About the related refresh issue, I'll try to send it quickly to an AE.

Regards,

Olivier


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
0 Kudos
Message 13 of 25
(1,456 Views)

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

0 Kudos
Message 14 of 25
(1,456 Views)

Thank you Daklu for your very interesting reply and time you've spent for it.

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

I think that the problem has to be investigate by LabVIEW R&D guys. Even if, as you say later in your post, there is some architecture clumsiness, there is not a big coding error that explain this and I'm affraid that sort of unexplicable behavior could happened in larger application with real business challenge. I can't wait to know the feeling of LV R&D about this.

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.

I'm not aware of that point.

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

I know that, but remember the origin of my code (see my first post). I've just tried to use AF to rewrite a code originaly QSM based that already have this circular dependencies. I voluntarily keep this architecture for demonstration purpose. I agree with you and think that my code is not a good one to demonstrate AF features.

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.

Consider that my code is not a demo for a "good" implementation of AF. I definetely change things if I should use AF architecture in real world project and shutdown process would be one of main topic to review.

"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

Can't wait to glance at your material.


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
0 Kudos
Message 15 of 25
(1,456 Views)

"I'm developing some material that hopefully will be"

Sloppy editing.  Sorry.  It should read...

I'm developing some material that hopefully will be helpful for those exploring actor-oriented programming.  I have two things I'm currently working on... the first is a white paper describing an archeological investigation into one of the existing AF examples.  The idea is to take the project as it is and make sense of it, using only the code as guidance.  The second is a presentation with the working title, "Fundamentals of Actor-Oriented Programming."  This will explain the principles of actors without the added abstraction of the AF or LVOOP.  Unfortunately my real job, family, LapDog, and various other things are all competing for my time, so I cannot promise when any of it will be done.

"I think that the problem has to be investigate by LabVIEW R&D guys."

I think you are correct.  Or at the very least by someone smarter than me. 

"I know that, but remember the origin of my code (see my first post). I've just tried to use AF to rewrite a code originaly QSM based that already have this circular dependencies."

I didn't look at the original QSM so I didn't know it had circular dependencies.  Writing demo code is always a tricky proposition.  People tend to look at them as examples of the correct way to write an application when usually the author leaves out lots of important stuff (error handling, shutdown processes, etc.) so the technique being illustrated isn't lost in the noise. 

Code comparing programming paradigms is especially difficult.  (I ran into this same problem with LVOOP vs traditional LV.)  Different programming paradigms often require thinking about the problem in a different way.  Trying to port a design based on a QSM thought process to an actor-oriented implementation for direct comparison may result in a poorly structured application.  If you create a "correct" design using actor-oriented thinking you run the risk of having an implementation that is difficult for people to compare to the original QSM implementation. 

Personally I think it's a mistake to demonstrate how to program in a new paradigm by implementing a poor design.  I've never been able to convince someone to move away from the QSM when their primary goal is write code quickly.  The QSM excels at that.  The value of actor-oriented programming isn't that it is faster and easier to write, it's in the scalability and sustainability.  Since I won't be able to influence the "write quickly" crowd anyway, I'd rather spend my time showing those who are looking for scalability and sustainability how to create an application that meets those goals.

Message 16 of 25
(1,456 Views)

Daklu wrote:

Personally I think it's a mistake to demonstrate how to program in a new paradigm by implementing a poor design.  I've never been able to convince someone to move away from the QSM when their primary goal is write code quickly.  The QSM excels at that.  The value of actor-oriented programming isn't that it is faster and easier to write, it's in the scalability and sustainability.  Since I won't be able to influence the "write quickly" crowd anyway, I'd rather spend my time showing those who are looking for scalability and sustainability how to create an application that meets those goals.

That said, I really can't wait your "Fundamentals of Actor-Oriented Programming." Hope you will find time to do it and again thanks for sharing your knowledge.


Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc!
0 Kudos
Message 17 of 25
(1,456 Views)

Thanks to the discussions on the forum, we are now able to identify the problem, and will put the fix in the release.

Here is a short explanation:

After making changes to a reentrant VI, if the changes do not require a recompile (for example cosmetic changes on the front panel), labview will only throw away the front panel of the clones and recreate them to keep them consistent with the original VI. One step is missed in this process, which eventually causes the code handling property nodes not get called. If the changes do trigger a recompile, the entire clone will be thrown away and recreated from scratch, everything will work just fine.

I hope this explains all the strange things you saw.

So the work around is:

After making changes to a reentrant VI, if the changes do not trigger a recompile, please force one.

You can force it by Ctrl+clicking the run button. If the run button is not present, you can drop a node on the block diagram and then remove it.

0 Kudos
Message 18 of 25
(1,456 Views)

> fix in the release

Are we targetting LV2012 or LV2012sp1?

0 Kudos
Message 19 of 25
(1,456 Views)

This fix is too late for beta2, but will definitely be in LV2012 release.

0 Kudos
Message 20 of 25
(1,456 Views)