FreddieAkeroyd
commented
1 year ago The C500 is sent from here https://github.com/ISISComputingGroup/EPICS-InstronArby/blob/7c0b342fef9ebee83dfd15c3054dd8e04612c649/instronArbyApp/Db/devinstron.proto#L63
with %d being passed from the db file at https://github.com/ISISComputingGroup/EPICS-InstronArby/blob/7c0b342fef9ebee83dfd15c3054dd8e04612c649/instronArbyApp/Db/controls.db#L294 so you would set PV MOVE:SP to an integer and that is the integer that appears after C500,
The STOP:_STOP_RAMP PV calls this passing 0
The MOVE:GO:SP calls it passing whatever is in CHANNEL:RAW PV which look to be the value returned from getCurrentControlChannel https://github.com/ISISComputingGroup/EPICS-InstronArby/blob/7c0b342fef9ebee83dfd15c3054dd8e04612c649/instronArbyApp/Db/devinstron.proto#L18
MOVE:_END calls it passing 0
However I think the issuer may be https://github.com/ISISComputingGroup/EPICS-InstronArby/blob/7c0b342fef9ebee83dfd15c3054dd8e04612c649/instronArbyApp/Db/controls.db#L384 I think the intention was to cause $(P)CHANNEL:RAW to process but it is actually writing 0 to its value, this will cause it to process and return to correct value, but there may be a brief period when it is zero and if a MOVE:GO:SP was issued at the wrong time it would see it as zero and send a C500,0 rather than the correct current mode. The line should be $(P)CHANNEL:RAW.PROC rather than just $(P)CHANNEL:RAW I also think the nearby STAT:FRAME and MOVE are also missing a .PROC – I will check all use of seq records in the file similar errors.
After an analysis of trace logs by scientists it seems the instron IOC occasionally send a C500,0 which causes issues
Locate why this happens