FpySequencer 0.1

[zimri-leisher]

Related Issue(s)	#3023
Has Unit Tests (y/n)	WIP
Documentation Included (y/n)	WIP

---

Change Description

The 0.1 version of the FpySequencer, which replicates the functionality of the existing CmdSequencer component.
Features:

• Dispatching arbitrary commands
• Absolute and relative delays between commands
• Configurable timeout
• Cancelling sequences
• Validating and running as separate commands
• Blocking/non-blocking running of sequences

It uses FPP state machines extensively.
~1300 lines of CPP
~550 lines of FPP

Rationale

This is the first part of the roadmap for the implementation of the advanced sequencing language.

[LeStarch]

I addressed all your comments as best I could.

[LeStarch]

@bocchino wants a minimal SDD.

[zimri-leisher]

Awesome, just the feedback I was looking for. Will fix.

[LeStarch]

Finalizing changes:

1. Add sequence file ID. Add it to context. -- TODO
   1. If sequence ID matches active but the returned opcode is not expected: WARN then stop sequence (wrong opcode from current sequence).
   2. If sequence ID does not match, WARN but continue (spurious response from a previous sequence).
   3. Capture sequence command id (distinguish between multiple same opcodes)
   4. Capture sequence file ID (dustingush against different runs)
2. Add SDD w/ statement about being in development.
3. Remove priorities.
4. Remove test usage in Ref.
5. No invalid sequence
6. Make sequence failed specific to reason why
7. Statement Index to events where approrpiate

Once done, I will review one more time and then merge as-is.

To make this prime-time we will additionally need to:

1. Author better UTs (close to 100% coverage)
2. Author a full SDD with documented binary format
3. Author users guide for tool support
4. Add to references and templates.
5. Constant for the buffer size
6. Failed on line
7. Consider: fixing object ids
   These steps are a separate PR.

[zimri-leisher]

Finalizing changes:

• Add SDD w/ statement about being in development. DONE
• Remove priorities. WONTDO -- I know I said I would remove priorities, but due to some slight changes in internal architecture it's now hard to remove them. Tim said it was okay, so I'm gonna keep them in.
• Remove test usage in Ref. WILLCO
• No invalid sequence DONE
• Make sequence failed specific to reason why DONE
• Statement Index to events where approrpiate DONE

The remainder are about the "what to do if we get an unexpected response" problem.

Here is the behavior that I think we want:

1. If we get a response back from a different sequence, warn but do not cancel current.
   • Rationale: This can happen nominally if we cancelled the previous sequence while a cmd was executing
2. If we get a response back from the same sequence:
   1. If the opcode or cmdIdentifierNumber (a number incrementing from 0 modulo 2^16) do not match, fail the sequence
      • Rationale: it must be a coding error if the current sequence gave us a different response. Do not proceed!
   2. Otherwise, all's well, proceed as normal.

Working on implementing this now.

[zimri-leisher]

The implementation of the new, more precise command response behavior is quite complex and needs another pair of eyes. @LeStarch please review FpySequencer::cmdResponseIn_handler and the RUNNING state (specifically, the on stmtResponse_unexpected signal listener) in the FpySequencerStateMachine.fppi.

EDIT--this is ready to review now

[LeStarch]

Still need to confirm 2 more things:

1. priorities when we discussed, @timcanham heard "priorities aren't needed in this component", and @zimri-leisher heard "Priorities can be used". Both statements were true, but created different expectations to the path forward. I am working on a resolution
2. I see exactly what I expect from the code block for the new command response handling, except it seems to me that the m_statementsDispatched is incremented in the wrong place as it is incremented just after dispatch, resulting in a wait for the next command. What am I missing?
3. Remove from Ref when the above two are resolved.

Very good work. We are in the final steps.

[LeStarch]

Still need to confirm 2 more things:

1. `priorities` when we discussed, @timcanham heard "priorities aren't needed in this component", and @zimri-leisher heard "Priorities can be used".  Both statements were true, but created different expectations to the path forward.  I am working on a resolution

2. I see exactly what I expect from the code block for the new command response handling, except it seems to me that the m_statementsDispatched is incremented in the wrong place as it is incremented just after dispatch, resulting in a wait for the next command.  What am I missing?

3. Remove from Ref when the above two are resolved.

Very good work. We are in the final steps.

I confirmed Priorities are green-light. Thus to close out this PR

• Address/Resolve my last round of feedback
• Answer my ordering question
• Remove from Ref
• Pass CI
• Merge
• Celebrate 🎉🎉 🎉 🎉 🎉

[zimri-leisher]

Okay, I think I have completed all of those items.

[bocchino]

This PR looks good to me!

• I reviewed and approved the state machine design
• I asked for a minimal SDD, which was provided

[LeStarch]

@zimri-leisher we'll need to fix the CI errors that came in when you bumped F Prime. Let me know if you need help!

[zimri-leisher]

Okay, believe they're all fixed now.

[zimri-leisher]

@LeStarch let's get this merged!!! So excited.

[LeStarch]

• Versioning