You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As someone who uses a Beckhoff I would like my bump strips signal to be correctly propagated to IBEX.
Firstly, these aren't loaded in from twincat, but are from galil, so we should load them in from both (and assume only one will be used)
Secondly, when testing on LARMOR, the signals are the wrong way round, as in tripped is 0 and not tripped is 1, rather than changing this motion logic I want to be able to invert the value and send it to MOT:BUMP_STOPS
Acceptance Criteria
What is the acceptance criteria?
INSTETC is changed to load in bumpstop.cmd from twincat\ as well as galil\
a way of inverting the value send to MOT:BUMP_STOPS is given, through a calcout or similar
Extra Information
This could be done with a macro in the same way that the PV name is passed to INSTETC via bumpstops.cmd.
A workaround will be added in custom_records.db on LARMOR for now so that should be removed when this is deployed - this will be done in #6966
The text was updated successfully, but these errors were encountered:
rerpha
changed the title
Bumpstrips: allow inverting the value passed to INSTETC
Bumpstrips: allow inverting the value passed to INSTETC, load in cmd file in beckhoff ioc
Jan 18, 2022
in case we need to patch this on instruments I have made ISISComputingGroup/EPICS-ioc#668 for the first point of the acceptance criteria
rerpha
changed the title
Bumpstrips: allow inverting the value passed to INSTETC, load in cmd file in beckhoff ioc
INSTETC: allow inverting the value passed to BUMP_STOPS, load in cmd file in twincat ioc
Jan 18, 2022
As someone who uses a Beckhoff I would like my bump strips signal to be correctly propagated to IBEX.
Firstly, these aren't loaded in from twincat, but are from galil, so we should load them in from both (and assume only one will be used)
Secondly, when testing on LARMOR, the signals are the wrong way round, as in tripped is 0 and not tripped is 1, rather than changing this motion logic I want to be able to invert the value and send it to
MOT:BUMP_STOPS
Acceptance Criteria
What is the acceptance criteria?
Extra Information
This could be done with a macro in the same way that the PV name is passed to INSTETC via bumpstops.cmd.
A workaround will be added in custom_records.db on LARMOR for now so that should be removed when this is deployed - this will be done in #6966
The text was updated successfully, but these errors were encountered: