ISISComputingGroup / ISISComputingGroup/IBEX

GALIL: Changing .VELO often fails [time 1d for issue]

Offen
#4,396 5 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
bug
Vorherrschende Sprache
Keine Sprachdaten
Sterne
6
Forks
2
Ø Merge
16 Std. 40 Min.
Gemergte PRs (30 T.)
2

Beschreibung

Observed on CRISP:
After changing the `.VELO` field of motors on CRISP, the IOC will report back the right value, however when querying the controller via the backdoor it appears to not actually have changed. Some axes seem to work better than others e.g. changing S4ROT (`MTR0606`) almost always fails, wheras SMROT (`MTR0106`) almost always succeeds.

I have knocked together this script as a utility for testing whether changing velocity on a given axis (by controller- and axis-number) succeeds. The intention is to run it over all axes and see whether any patterns emerge. Currently, **this script needs some work as it currently fails more often than it should** i.e. returns false on axes although the speed sets correctly. However, this may serve as a starting point to be modified by whoever picks up the ticket if they deem it useful.

```
def test_set_velo(ctrl_no, axis_no, velocity):
# backdoor pv uses A-H rather than 1-8 to identify axis
axis_lookup = {1: "A", 2: "B", 3: "C", 4: "D", 5: "E", 6: "F", 7: "G", 8: "H"}
axis_pv = "{}MOT:MTR0{}0{}".format(g.my_pv_prefix, ctrl_no, axis_no)
velocity_pv = "{}.VELO".format(axis_pv)
backdoor_pv = "{}MOT:DMC0{}".format(g.my_pv_prefix, ctrl_no)
initial_velocity = g.get_pv(velocity_pv)
motor_resolution = g.get_pv("{}.MRES".format(axis_pv))
# for comparison with the value reported by the backdoor
initial_speed = initial_velocity / motor_resolution
print(float(initial_speed))

g.set_pv(velocity_pv, velocity, wait=True)
g.waitfor(seconds=1)
g.set_pv("{}:SEND_STR_CMD".format(backdoor_pv), "MG _SP{}".format(axis_lookup.get(axis_no)), wait=True)
g.waitfor(seconds=1)
actual_speed = g.get_pv("{}:SEND_STR_MON".format(backdoor_pv))
print(int(float(actual_speed)))
set_successful = not int(float(actual_speed)) != int(float(initial_speed))

# Restore initial .VELO
g.set_pv(velocity_pv, initial_velocity, wait=True)

return set_successful
```

Acceptance criteria:
1. Understand what causes setting the velocity on certain motor axes to fail (e.g. `S4ROT` on CRISP)
1. Create an appropriate ticket to fix this bug.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Rechercherichtung

Beginne mit dem im Issue genannten test_set_velo-Utility und reproduziere die .VELO/backdoor-Diskrepanz über die CRISP-Achsen hinweg, wobei du S4ROT und SMROT vergleichst. Untersuche die vom IOC gemeldete Geschwindigkeit im Vergleich zur MG _SP-Antwort des Controllers und ermittle, warum einige Achsen fehlschlagen oder False Negatives erzeugen. Die Aufgabe ist erledigt, wenn die Ursache identifiziert und ein fokussiertes Ticket zu ihrer Behebung erstellt wurde.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Bewertung

Tech-Stack
python
Bereich
embedded-iot
Issue-Typ
Bug
Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Aktivitätsstatus
Veraltet
Klarheit
Muss geklärt werden
Anfängerfreundlichkeit
25/100

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.