[INSTRM-287] Adopt the same state machine logic for sps actors Created: 07/Feb/18  Updated: 25/Feb/22  Resolved: 25/Feb/22

Status: Won't Fix
Project: Instrument control development
Component/s: ics_ccdActor, ics_enuActor, ics_xcuActor
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: arnaud.lefur Assignee: arnaud.lefur
Resolution: Won't Fix Votes: 0
Labels: SM1, SPS
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: JPEG File stateMachine.jpg    
Issue Links:
Relates
relates to INSTRM-425 Implement state engine in ccdActor Open
relates to INSTRM-426 Implement state engines in xcuActor Open
relates to INSTRM-265 List and describe meta keywords for sps Won't Fix
Story Points: 3
Sprint: SM1-2019 L, SM1-2019 M, SM1-2019 N

 Description   

While listing the meta-keywords for sps, we realized with fmadec that it would be much simpler if all the sps actors (enu, ccd, xcu ..) and their devices would have the same state machine mechanism.

As as they all inherit from tron_actorcore.ICC, if would be worth putting the code which handle the state machine directly the in the actorcore, with prototyped (functions, callback ...) which are called when passing from one state to the other .

It would be still up to the developer to fill those functions, but the machinery behind would do most of the work and generate the useful keywords .

If everybody agree, we think it would be a good idea.
I will join the basic design that we have in mind.

 Comments   
Comment by cloomis [ 07/Feb/18 ]

Agreed in principle. Can you flesh out what the state keywords are and how they are acted on?

Comment by arnaud.lefur [ 07/Feb/18 ]

I've just attached a diagram of the design, we were thinking of.
You have basically two keywords :

  • One state keyword ( OFF, LOADED, ONLINE), which represent the functional state of the device
  • One substate keyword ( IDLE, LOADING, INITIALISING, BUSY, FAILED...) which represent what the device is currently doing.
Comment by cloomis [ 08/Feb/18 ]

As we discussed on the telecon, it could be nice to incorporate the exposureState logic into this. I'd envision replacing your BUSY with FLUSHING,INTEGRATING,READING for the CCDs and FLUSHING,READING for the H4s.
Does that fit in to your scheme? Or would you have some other mechanism?

For most hardware, I'd want to lie about BUSY – not toggle between IDLE and BUSY with each low-level command. Does that violate your framework?

Is there any mechanism for annotating the state change? Adding a comment/reason for failure could be efficient.

Comment by arnaud.lefur [ 27/Mar/18 ]

An actor with this mechanism has been developped : https://github.com/alefur/ics_fsmActor

Adding it to the actorcore is the second step

Comment by arnaud.lefur [ 04/Jun/18 ]

merged into tron_actorcore 1.8.2

Comment by hassan [ 23/Jul/18 ]

Craig to split this ticket into phase one and phase two tickets

Comment by hassan [ 11/Apr/19 ]

Blocked by INSTRM-425 and INSTRM-426 .

Comment by hassan [ 02/May/19 ]

To be discussed with cloomis during visit to LAM early May.

Comment by arnaud.lefur [ 25/Feb/22 ]

okay, we never went down that road.
enu and dcb are using this mechanism, but I guess that will be it for sps.

Generated at Sat Feb 10 16:23:26 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.