ENH: add MR1K3 as veto device for TMO #42
Conversation
|
Hi Nick, can you please add a link to the jira related to this PR in the context section? (and fill out any other sections you have info for). We can review without this because it's clear now why this is happening but in a year this info will be helpful when tracking changes. |
| @@ -33,6 +34,9 @@ bMR1K1_IN := PMPS.PMPS_GVL.stCurrentBeamParameters.aVetoDevices[PMPS.K_Stopper.M | |||
|
|
|||
| bST3K4_IN := PMPS.PMPS_GVL.stCurrentBeamParameters.aVetoDevices[PMPS.K_Stopper.ST3K4]; | |||
|
|
|||
| bMR1K3_IN := PMPS.PMPS_GVL.stCurrentBeamParameters.aVetodevices[PMPS.K_Stopper.MR1K3_IN] | |||
| AND NOT PMPS.PMPS_GVL.stCurrentBeamParameters.aVetoDevices[PMPS.K_Stopper.MR1K3_OUT]; | |||
|
|
|||
| fbArbiterIO(i_bVeto:= bMR1K1_IN, Arbiter := GVL_PMPS.g_fbArbiter1, fbFFHWO := GVL_PMPS.g_FastFaultOutput1); | |||
|
|
|||
| GVL_PMPS.g_FastFaultOutput2.i_xVeto := bMR1K1_IN OR bST3K4_IN; | |||
There was a problem hiding this comment.
Right here: I expected FFO2 to be vetoed by MR1K3
There was a problem hiding this comment.
Thats true, we could write that here, but I though that would be redundant with the higher and lower authority logic of FB_VetoArbiter. Let me see if I can point to that in the that function block.
There was a problem hiding this comment.
I think this means in this case, when fbarbiter2 requests veto, fbarbiter1 removes fbarbiter2's request and requests full beam for it. If that's all it does, then you're right, we need to add MR1K3 IN as a veto condition for fbArbiter2.
There was a problem hiding this comment.
I think the higher/lower authority veto logic is independent from the fast fault veto logic
There was a problem hiding this comment.
Does FF2 need to veto MR1K1 even? Its fault is linked to FF1 which already vetos on MR1K1? Would be the same for MR1K3.
There was a problem hiding this comment.
I agree, if the fault 2 and arbiter 2 are linked to fault 1 and arbiter 1 respectively, and the two have the same veto sets, then the 2s can lean on the veto definitions of the 1s
this is all very confusing
| @@ -33,6 +34,9 @@ bMR1K1_IN := PMPS.PMPS_GVL.stCurrentBeamParameters.aVetoDevices[PMPS.K_Stopper.M | |||
|
|
|||
| bST3K4_IN := PMPS.PMPS_GVL.stCurrentBeamParameters.aVetoDevices[PMPS.K_Stopper.ST3K4]; | |||
|
|
|||
| bMR1K3_IN := PMPS.PMPS_GVL.stCurrentBeamParameters.aVetodevices[PMPS.K_Stopper.MR1K3_IN] | |||
| AND NOT PMPS.PMPS_GVL.stCurrentBeamParameters.aVetoDevices[PMPS.K_Stopper.MR1K3_OUT]; | |||
|
|
|||
| fbArbiterIO(i_bVeto:= bMR1K1_IN, Arbiter := GVL_PMPS.g_fbArbiter1, fbFFHWO := GVL_PMPS.g_FastFaultOutput1); | |||
There was a problem hiding this comment.
Right here: I expected Arbiter1 to be vetoed by MR1K3
|
Maybe I need to review the diagram again |
Description
Motivation and Context
When MR1K3 is in, TMO devices should not fault the beam.
TXI preparing for beamtime.
https://jira.slac.stanford.edu/browse/ECS-5580
How Has This Been Tested?
This branch is running on the PLC with synced IOC. We set MR1K3 in by forcing the encoder values sent to the arbiter from TXI-Optics. I then looked at the faults on tmo optics to make sure they were being vetoed.
Where Has This Been Documented?
Screenshots (if appropriate):
Pre-merge checklist
Always Newestpre-commit(alternativelypre-commit run --all-files)