#236 Taurus4: label background ignores state changes

[Carlos Pascual]

To reproduce:

• launch taurusdemo->label
• set bgrole to state
• execute command switchstates in sys/tg_test/1 device

In Taurus 3.6, you see the background of the label changing. In Taurus4-preview it remains green

[Carlos Pascual]

It can also be reproduced (more easily) running taurusdevicepanel sys/tg_test/1 and using the switchstates and init command buttons from the commands panel. The status label on top of the widget does not change.

[Carlos Falcon]

Taurus4 was modified to use agnostic state (TaurusDevState) instead of tango equivalent state (DevState). The new possible state are Ready, NotReady and Undefined.

The TaurusBaseController was modified to show in the background the device state, instead the Tango attribute, state.

So, according to these facts, I consider that the reported behaviour is the expected one and I will reject the bug.

[Carlos Pascual]

You are right. The label is indeed responding to taurus state changes (can be checked by stopping-and-restarting the device server an seeing that the states cycle from ready->not->ready->undefined->ready

BUT: I think that we should map the FAULT Tango state (and also DISABLE) to the NotReady Taurus state. because:

• FAULT or DISABLE tango devices are "not ready"
• the colors associated to Tango's DevState.FAULT and DISABLE are red and purple respectively, which are closer to the red color of TaurusDevState.NotReady than to the green color of TaurusDevState.Ready

I made the necessary changes in https://github.com/cpascual/taurus/pull/12

[Zbigniew Reszela]

A good source of information about the Tango states is Tango Device Servers: Design & Implementation Guidelines.

Before looking for the map between Tango states and Taurus states we should describe Taurus states guidelines. What do you think about this?

State	Associated Color	Meaning
Ready *	Green	The device is operational by the user and could even be involved in some operation.
NotReady	Red	The device is not operational by the user. This could be due to numerous reasons e.g. device initialization, device failure.
Undefined	Grey	The device cannot retrieve its state e.g. due to communication problem to the hardware (network cut, broken cable etc...) It could also represent an incoherent situation.

* Here we could think of adding one more agnostic state - Busy to distinguish on operation in progress

So I see this map as following:

Tango State	Taurus State
Unknown	Undefined
Init	NotReady
Fault	NotReady
Disable	NotReady
Off	Ready
Standby	Ready
Moving	Ready
On	Ready
Alarm	Ready
Running	Ready
Open	Ready
Close	Ready
Extract	Ready
Insert	Ready

If there are no negative comments, I will proceed with merging the pull request, previously mapping the Tango Init state to the Taurus NotReady states.

[Carlos Pascual]

I agree with mapping init to NotReady too.

Also, I added the state documentation to the docs that are being rewritten for [#221]

[Zbigniew Reszela]

Added mapping of UNKNOWN to Undefined and INIT to NotReady and pushed to develop.