Should State be exposed?

[MikeHart85]

This is a design question/discussion rather than an issue to fix.

Should the state machine state be exposed outside of the simulation module and/or as a PV?

On the one hand, keeping the state machine and its states internal to the simulation would be good from an encapsulation perspective.

However, it could be useful to expose them for both diagnostic and user feedback purposes.

[MikeHart85]

Thinking ahead, we may want some sort of indicator in the user interface to show the user what is currently happening. Particularly, since things like levitating, spinning up, spinning down and phase locking can take a long time, not having some sort of feedback about what is going on would likely be frustrating for the user.

Another long term consideration would be whether we want to expose the states exactly as they are in the state machine, or in a simplified, user-friendly form (or both). Estimated time delays or some kind of progress indication may also be useful feedback for the user.

[MichaelWedel]

I think part of this is answered through the CHIC Communications Requirements Specification. The table contains some status fields that relate to the state of the underlying state machines, for example there are fields that specify whether the "rotor is levitated", and also a field that is some sort of enumeration of states (item 36 in the long table).

[MichaelWedel]

So yes, I agree. The chopper should report some of the state of its components, but probably at a higher level that doesn't necessarily expose the entire underlying state machine. The user should also get some indication whether the current state of the chopper means "waiting for something to complete" or "ready to accept new instructions".

[MikeHart85]

Regarding the CHIC Communications Requirements Specification, I'm seeing the following discrepancies between the states listed there and the ones in the current state machine.

• State Machine has separate states for "Levitating" and "Levitated", Requirements have only "Levitating"
• Reqs have a "Tripped" state, not present in SM
• SM has a "Speed setting" state, not present in Reqs
• SM has a "Phase locking" state, not present in Reqs

Is this mostly a matter of the State value in the requirements being simplified?

What about the "Tripped" state? This sounds like an important condition that's not covered in the Sim currently.

[MichaelWedel]

Yes, there are some discrepancies, probably the field in the document simplifies too much. If I interpret the document correctly, their Levitating state is our Levitated state. But since it's not an instantaneous thing and something may go wrong in the process of lifting up the disc it makes sense to have that as a separate state.

The same goes for Speed setting (should probably be named Accelerating) and Phase locking, which are just Rotating in the document. Maybe the chopper group is even willing to refine that a bit, because I think it is genuinely useful to the user to know that the chopper has reached the set speed but is still busy trying to obtain a phase lock.

Regarding the Tripped state I wasn't sure what exactly that means, so I left it out for now. After talking to Jon I suppose this is an error state. We have to clarify from where this state can be reached but since our first approximation probably will not produce any error states we're fine for now.

[MichaelWedel]

Andres got back on me regarding these two issues.

Tripped state The tripped state is indeed an error state. If something goes wrong in the drive and/or motor (he mentioned high temperatures, vibrations, ...), the motor is powered off and the disc is moving only by inertia (which he mentioned is call "coasting").

This state can be reached from any state.

State indicator This is based on the states of the SKF drive, they are happy about feedback and if we identify more things that may be beneficial for the user to know they'd like to be informed.

[MikeHart85]

About all the different temperature, status, etc values that are listed in the CHIC requirements:

Is our goal to simulate all of them in detail, modeling them as closely as possible to the real device for each particular state of operation?

Will we be making all of them available to the client code?

Will the client be making all of them available via, for example, PVs?

Do we know how often they are updated by the real device?

[MichaelWedel]

Yes, ultimately we should aim to model everything as closely as required in order to make our end of the chopper controls ready for dealing with these situations. That doesn't mean we need a thermodynamically sound description of the temperature development inside the chopper housing, but we should be able to change such relevant operation parameters in different ways and make the system behave similar to "the real world".

The client should be able to influence those values if necessary, so in some cases I suppose these things may need to be exposed to the client.

Whether they will be exposed via PVs is a very different question, one that is ultimately decided by how ICS and the chopper group define the EPICS interface to the CHIC. It's too early to make decisions on that.

Regarding update rates, as in issue #5, this is probably something that needs to be discussed in the upcoming meeting.

[OwenArnold]

What you've said here is very interesting. I hadn't considered that this would be an advantage of writing the simulators! i.e. simulator driving the real CHIC direction.

[MichaelWedel]

I agree, it's very good that this goes in two directions as we may notice "end customer stuff" that they have overlooked (and vice versa).

[OwenArnold]

@MichaelWedel I'd urge caution regarding accuracy of simulation here I think this could be a grey-area. The main objective at present should be able to create a vertical slice through the system. device-simulator->ioc->nicos. I think it would be a mistake to spend too much time on making the simulator very realistic initially given that we can grow it in future and will need to anyway as the CHIC specs evolve.

I think this is what the consensus is amongst us.

[MichaelWedel]

Yes, it is, that's what I tried to express with "as required". At the moment we don't need "very realistic", but we may need it at some point. So all I'm saying is we should be careful not to cut ourselves off from that possibility by making the design too narrow.

[OwenArnold]

Sounds good to me. And I do agree that the aim should be to evolve the simulation to make it increasingly more realistic. That way we can work with the best next thing to a real-world chopper through our entire development lifecycle on NICOS.

[MichaelWedel]

Closing this issue as well, the state is exposed as STATE PV at the moment and it's likely going to stay like this.