ISISComputingGroup / ISISComputingGroup/IBEX
GALIL: Changing .VELO often fails [time 1d for issue]
- 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