What is a good way to repeat start and stop under Actor Framework

[Tepig]

Im using AF to develop my standard template. This framework is really awesome.

I could have implemented some basic feature for my application. It's working fine. 

The present application work flow is,

Run --> Initialize --> (By "Start" button value changed event) Start -->

Acquiring and Logging (named "AandL") --> AandL --> AandL --> ...

--> (By "Exit" button value changed event) Exit

To repeat AandL, I resend message named "Send Measure.vi" in itself.

As next step, I want to remake this application as below.

Run --> Initialize --> (By "Start" button value changed event) Start -->

AandL -->  AandL --> ... --> (By "Stop" button value changed event) Stop AandL

--> Start --> AndL --> ... --> Stop --> Start --> .... --> Exit

But I stucked how can I stop the repeated methods.... When I used QMH, it was not difficult. I could easily interrupt and stop those methods. Now I have no idea how to stop. Regardless of calling stop method, Acquiring isn't stopped because "Send Measure.vi" is continuously  called. Of course, I think my way to repeate is not clever.

Does anyone have idea, Good way to repeat start and stop Acquiring and Logging under AF?

Best,

Embor

[StefanLemmens]

Dear Embor,

a "quick and dirty" way to do this would be to add a boolean flag "Stop" to the actors private data. Set this flag to false when you start measuring and to true when the stop button is pressed. Then put the "Send Measure.vi" in a case so that it isn't called anymore after the stop button is pressed.

Another way to do this is by using time delayed messages. You can fire such any message with the "Time-Delayed Send Message.vi" and specify a delay and count (-1 = infinite). This way it keeps on repeating at a fixed interval. You don't even have to send the message again. To stop it you have to use the notifier that the "Time-Delayed Send Message.vi" returns. Be carefull that your delay is larger than the time it takes to measure otherwise your message queue might get filled with messages.

Kind Regards,

Stefan

[Eric.M]

An AF message should not "recurse", as you did with Send Measure.vi. It is prone to infinite messaging. It prevents your actor from being responsive because of the Wait function you have there. And if you want to add conditions (to choose if you want to re-send the message), you will possibly end up adding a lot of logic in that method while it should only be meant to acquire data (lack of cohesion in your code).

Stefan pointed out a much better approach with a TD message.

Another possible way would be to create a parent actor that has an helper loop running at a defined rate which calls into a dynamic dispatch method (e.g. Update.vi). Then your actor can inherit from this actor and implement its own Update.vi

--Eric

[Tepig]

Dear Stefan, Eric,

I really appreciate your kind advice! I added TD message and it worked what I expected.
I stopped the measurement by releasing notifier reference on Stop case.

================================================

But as Stefan said, if delay is smaller than the measurement time, it took long time to stop the measurement. I understand this is caused by overstocking of messge queue.

All looks fine but I have a concern if I don't know a valid value of the delay, what method is good to know it? Of course, I may be able to calculate it but if there is no good way, how can I know?

Perhaps, AF isn't suitable for "continuous data acquiring and logging" application?

Do you have an experience which developed similar application using AF?

Best,

Embor

[drjdpowell]

---

@StefanLemmens wrote:

a "quick and dirty" way to do this would be to add a boolean flag "Stop" to the actors private data. Set this flag to false when you start measuring and to true when the stop button is pressed. Then put the "Send Measure.vi" in a case so that it isn't called anymore after the stop button is pressed.

---

The boolean should be called "Acquiring", true when measuring, and it's not "quick and dirty".   The actor has two states, "Acquiring" and "Idle", and all messages should be handled in a way consistent with that state.  Don't start if your already acquiring; don't measure if your idle; don't stop if your already stopped.  The issues the OP is having is partly because he's not letting the Actor be smart enough to know its own state.  

[drjdpowell]

---

@Tepig wrote:

Perhaps, AF isn't suitable for "continuous data acquiring and logging" application?

Do you have an experience which developed similar application using AF?

---

This is a video I did demonstrating two methods of recurring actions in an "actor".  It's not Actor Framework (it's a different actor-model framework) but you can use the same techniques using the "Time-Delayed Send Message" feature in AF**.

Recurring Event Methods (in Messenger Library)

**Note: the AF feature doesn't have the "metronome"-like time-drift correction that the Messenger-Library equivalents have.

[Ironman_]

if he destroys the notifier, he won't be able to restart it

The timedelayed is very dangerous to use, it basically DEPENDS on how you layout the application architecture, how you manage these

If you go deep, you find that it basically spawns a VI, so you have a running VI that you can "control" only via notifier/end of messages/errors/weird conditions.

I suggest to implement an actor with a state.

[Tepig]

Guys, thanks for your kind advice : D

I decided not to use TD message because I have a fear that cannot handle the message in a correct way : (

Instead, I added "state" into each modules. They read the state before do own task and decide "do" or "don't". I think this is a better way. If you have any feedback for my code, please let me know! 

<< Parent >>

 << Acquire Module >>

Thanks,

Embor

[wrkcrw00]

Using messages adds non trivial overhead so taking measurements at higher rates isn't practical. I use a different tact for acquiring data. I put my acquire and send code right into a helper loop on the actor core.vi diagram. My actor behaves as an asynchronous shell within which I do what might be considered "classic" state machine for acquiring data. For example, I put my DAQmx calls there, then load the data into a queue for transfer to another actor that does some processing. 

I stick with actors because for launching many and configuration AF works great. I only pull out the high speed data recording into the helper loops but leave everything else messages. 

[Tepig]

Thanks wrkcrw00, I will try to create helper loop.

In your code, how the helper loop communicate with Parent Actor.vi?

I want to know better case to do the communication.

Best,

Embor