https://pfspipe.ipmu.jp/jira This file is an XML representation of an issue en-us 8.3.4 803005 13-09-2019 https://pfspipe.ipmu.jp/jira/browse/INSTRM-287 Instrument control development <p>While listing the meta-keywords for sps, we realized with <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=fmadec" class="user-hover" rel="fmadec">fmadec</a> that it would be much simpler if all the sps actors (enu, ccd, xcu ..) and their devices would have the same state machine mechanism.</p> <p>As as they all inherit from <b>tron_actorcore.ICC</b>, 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 .</p> <p>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 .</p> <p>If everybody agree, we think it would be a good idea. <br/> I will join the basic design that we have in mind.</p> INSTRM-287

Adopt the same state machine logic for sps actors

Task Normal Won't Fix Won't Fix arnaud.lefur arnaud.lefur SM1 SPS Tue, 6 Feb 2018 18:36:20 +0000 Thu, 24 Feb 2022 20:32:51 +0000 Thu, 24 Feb 2022 20:32:51 +0000 ics_ccdActor ics_enuActor ics_xcuActor 0 3 <p>Agreed in principle. Can you flesh out what the state keywords are and how they are acted on?</p> <p>I've just attached a diagram of the design, we were thinking of.<br/> You have basically two keywords : </p> <ul> <li>One state keyword ( OFF, LOADED, ONLINE), which represent the functional state of the device</li> <li>One substate keyword ( IDLE, LOADING, INITIALISING, BUSY, FAILED...) which represent what the device is currently doing.</li> </ul> <p>As we discussed on the telecon, it could be nice to incorporate the <tt>exposureState</tt> logic into this. I'd envision replacing your <tt>BUSY</tt> with <tt>FLUSHING</tt>,<tt>INTEGRATING</tt>,<tt>READING</tt> for the CCDs and <tt>FLUSHING</tt>,<tt>READING</tt> for the H4s.<br/> Does that fit in to your scheme? Or would you have some other mechanism?</p> <p>For most hardware, I'd want to lie about <tt>BUSY</tt> &#8211; not toggle between <tt>IDLE</tt> and <tt>BUSY</tt> with each low-level command. Does that violate your framework?</p> <p>Is there any mechanism for annotating the state change? Adding a comment/reason for failure could be efficient.</p> <p>An actor with this mechanism has been developped : <a href="http://example.com/" class="external-link" rel="nofollow">https://github.com/alefur/ics_fsmActor</a></p> <p>Adding it to the actorcore is the second step</p> <p>merged into tron_actorcore 1.8.2</p> <p>Craig to split this ticket into phase one and phase two tickets</p> <p>Blocked by <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-425" title="Implement state engine in ccdActor" class="issue-link" data-issue-key="INSTRM-425">INSTRM-425</a> and <a href="https://pfspipe.ipmu.jp/jira/browse/INSTRM-426" title="Implement state engines in xcuActor" class="issue-link" data-issue-key="INSTRM-426">INSTRM-426</a> .</p> <p>To be discussed with <a href="https://pfspipe.ipmu.jp/jira/secure/ViewProfile.jspa?name=cloomis" class="user-hover" rel="cloomis">cloomis</a> during visit to LAM early May.</p> <p>okay, we never went down that road.<br/> enu and dcb are using this mechanism, but I guess that will be it for sps.</p> Relates INSTRM-425 INSTRM-426 INSTRM-265 Development Rank 0|02qpuc:i6001gy Sprint SM1-2019 L SM1-2019 M SM1-2019 N Story Points 3.0