-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Powermeter fast-fault edits #78
Conversation
lcls-twincat-common-components/Library/Devices/PPM/FB_PPM_PowerMeter.TcPOU
Outdated
Show resolved
Hide resolved
lcls-twincat-common-components/Library/Devices/PPM/FB_PPM_PowerMeter.TcPOU
Outdated
Show resolved
Hide resolved
lcls-twincat-common-components/Library/Devices/PPM/FB_PPM_PowerMeter.TcPOU
Outdated
Show resolved
Hide resolved
I tried adding a simple way of only triggering the fault if the energy is persistently over what's allowable, but I am completely open to doing it another way. |
IF eEnumGet <> E_PPM_States.OUT AND bOverAllowableEnergy = TRUE THEN | ||
uOverCounter := MIN(uOverCounter + 2, 50); | ||
ELSE | ||
uOverCounter := MAX(uOverCounter - 1, 1); | ||
END_IF |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the counter approach here because it's easy to understand and doesn't do anything overly complex. This is what we want for a robust PLC program.
25 cycles at 10ms per cycle = 250ms = quarter of a second
I'm not exactly sure what the "most optimal" count would be but this seems reasonable and will definitely cull the false positives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If bOverAllowableEnergy switches between True and False frequently, it could take up to 50 cycles or half a second to trigger the fault. (+2 * 50) + (-1 * 50) = 50, (+2 * 49) + (-1 * 51) = 47. As long as half of the cycles or more are over, it will trigger, but the higher the proportion the less time it takes, maxing at a quarter second. Like you said, these are all magic numbers that I just think seemed reasonable
lcls-twincat-common-components/Library/Devices/PPM/FB_PPM_PowerMeter.TcPOU
Outdated
Show resolved
Hide resolved
…rMeter.TcPOU Co-authored-by: Zachary Lentz <[email protected]>
ELSE | ||
uOverCounter := MAX(uOverCounter - 1, 1); | ||
END_IF | ||
FF(i_xOK := eEnumGet = E_PPM_States.OUT OR uOverCounter < 50, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm trying to get into the habit of verbosely double-checking fast faults now:
Fault is OK if:
- PPM is out
- OR counter is under 50
Therefore, the beam turns off when both:
- PPM is at one of the known target or an unknown state or in motion
- AND the counter is at least 50 (counter caps out at 50)
This is totally reasonable logic and I endorse it
Some might argue that e.g. the YAG states should also be exempt from these faults, but there is some judgement call to be made because what if the beam is actually hitting the power meter somehow in these states? And what if the state positions other than "OUT" are wrong? I think there's a philosophical discussion to be had here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I forgot to come back and re-approve, I like this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Maggie helped me test this. We checked that the fault would not occur unless the PPM position was at the power meter and the energy was above the threshold, so I think this is good to merge |
Description
Only fast-fault if ppm is not out or moving
Motivation and Context
Power meters in rix are fast faulting even when beam energy should not be high enough to trigger them.
How Has This Been Tested?
Where Has This Been Documented?
Pre-merge checklist
Always Newest
version (Library, *
)pre-commit
or ranpre-commit run --all-files