ISISComputingGroup / ISISComputingGroup/IBEX
GALIL: Changing .VELO often fails [time 1d for issue]
- Lingua principale
- Nessun dato sulla lingua
- Stelle
- 6
- Fork
- 2
- Merge medio
- 16h 40m
- PR unite (30g)
- 2
Descrizione
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.
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Direzione di ricerca
Start with the test_set_velo utility in the issue and reproduce the .VELO/backdoor discrepancy across CRISP axes, comparing S4ROT and SMROT. Inspect the IOC-reported velocity against the controller's MG _SP response and determine why some axes fail or produce false negatives. Done means identifying the cause and creating a focused ticket to fix it.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Valutazione
- Stack tecnologico
- python
- Ambito
- embedded-iot
- Tipo di issue
- Bug
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Stato di attività
- Ferma
- Chiarezza
- Da chiarire
- Idoneità per principianti
- 25/100