An attempt at integrating a synchronous sequencer within an AF code

[WavePacket]

---

@OneOfTheDans wrote:

Regarding the dual purpose hardware-passthrough messages: your original design had the Hardware Broker doing double duty (dual purpose). It could either act out a Sequence, or it could forward (passthrough) messages from the GUI intended for direct control.

...

---

Ah, got it.

---

@OneOfTheDans wrote:

If you implement your sequence in the Sequence Actor's helper loop, then you'll need all those user events to stop/pause/shutdown.

 Got it, I think I have a grasp of this structure.

---

@OneOfTheDans wrote:

...

On the other hand, if you implement the sequence cases as messages of the Sequence Actor, and send-to-self at the end of each function, then your Actor "is" the sequence, rather than "doing" the sequence in the helper loop. You get 1 clean VI per step, which can be nice for version control & debugging, and any messages coming from Root will be naturally interleaved without coding extra events. If you have too many steps for this to be feasible, it could still work with 1 message "run step(int32)" that is just a giant case structure.

...

---

I think I understand most of this suggestion. This is a state machine with the next stage being stored in a uninitialized shift register or perhaps private data of the actor itself? Therefore rerunning the same message progresses through the state machine?

---

@OneOfTheDans wrote:

...

But I'm just some guy on the internet; these ideas might not fit your real project.

---

Well me too I suppose! Nice to meet you. Hopefully someday I'll be learned enough on these topics to help a newcomer along like you are right now.
  

[WavePacket]

---

@drjdpowell wrote:

---

@WavePacket wrote:

(2) In the timeout case, Hardware Broker synchronously edit with timeout asks root permission to continue to next state (so root can ask for a stop between any states). 
(3) If root gives permission, then Hardware Broker proceeds to next state.

---

This is problematic.  It would be better for Root to create a "Sequence Abort Notifier" and provide it along with the Sequence**.  The subVIs inside the Hardware Broker can check the Abort Notifier at multiple points to see if Root has signaled and Abort (can also implement Pause/Resume).  This avoids all your Timeout problems.

**note: a different notifier for each sequence; having only one Abort Notifier would be more problematic and have race conditions.  

---

Yeah, Ok - thanks. I see how this eliminates this portion of the synchronous behavior in my design. This synchronous portion is separate from the sequence of hardware calls, and the hardware calls themselves. Those synchronous behaviors seem to be needed, as far as I can see at the moment.

[OneOfTheDans · Accepted solution]

Regarding the deadlock:

Handle Error will determine whether the Actor should shut down. Unless you override, it always does.

Then, after the Actor Core shuts down, it runs Stop Core. That sends Stop to all Nested Actors. If there's an incoming error, it's an Emergency Stop. Otherwise (Error 43) it's a Normal Stop.

Notice, that's "after the Actor Core shuts down". It's already dead by then!

Normally, I suggest people don't look inside the AF at first. But you have a good handle on AF already, so I'd encourage looking in the parent methods for Stop Core.vi, Actor Core.vi, and Handle Error.vi. Those ones aren't bad, and really helped me understand the framework better. Avoid the launchers and Actor.vi lol.

Regarding the Sequence Actor:

Two ways (probably more?) to do what I was saying.

1. Many class methods & AF messages: one for every sequence step.
2. One class method & AF message: "Execute Step(int32 or enum)". The method has a case structure with case per sequence step.

The last thing each method does is enqueue-to-self the next step. You'd use #2 if there are many steps and you don't want tons of boilerplate AF messages. With #2 you could more easily save the previous step in private data, if you need that.

[WavePacket]

---

@OneOfTheDans wrote:

Regarding the deadlock:

Handle Error will determine whether the Actor should shut down. Unless you override, it always does.

Then, after the Actor Core shuts down, it runs Stop Core. That sends Stop to all Nested Actors. If there's an incoming error, it's an Emergency Stop. Otherwise (Error 43) it's a Normal Stop.

Notice, that's "after the Actor Core shuts down". It's already dead by then!

Normally, I suggest people don't look inside the AF at first. But you have a good handle on AF already, so I'd encourage looking in the parent methods for Stop Core.vi, Actor Core.vi, and Handle Error.vi. Those ones aren't bad, and really helped me understand the framework better. Avoid the launchers and Actor.vi lol.

...

---

I just did exactly that...and I now appreciate the concern you shared about deadlocks in the first design in the opening post. I'll avoid that portion of the design.

---

@OneOfTheDans wrote:

...

Regarding the Sequence Actor:

Two ways (probably more?) to do what I was saying.

1. Many class methods & AF messages: one for every sequence step.
2. One class method & AF message: "Execute Step(int32 or enum)". The method has a case structure with case per sequence step.

The last thing each method does is enqueue-to-self the next step. You'd use #2 if there are many steps and you don't want tons of boilerplate AF messages. With #2 you could more easily save the previous step in private data, if you need that.

---

Got it, thanks -- I think I'm at the point of making the judgement call of which is better.

---

@OneOfTheDans wrote:

...

Normally, I suggest people don't look inside the AF at first. But you have a good handle on AF already, so I'd encourage looking in the parent methods for Stop Core.vi, Actor Core.vi, and Handle Error.vi. Those ones aren't bad, and really helped me understand the framework better. Avoid the launchers and Actor.vi lol.

..

---

Appreciate the compliment, but I'm self-labeling myself at the "good enough to be dangerous stage". I'm hoping to proceed onto the "actually productive with it stage" haha. I've had many posts recently opening my ideas of for criticism, and people (like you) have been kind enough to share helpful critiques.