Differences

This shows you the differences between two versions of the page.

--- life:operator_explain [2025/06/25 17:41] – ryans
+++ life:operator_explain [2025/08/27 16:39] (current) – ryans
@@ Line 1: / Line 1: @@
-====What is an Operator? (unchecked)====
+=====What is an Operator? (unchecked)=====
 {{tag>needs_review}}
 If you're reading this then you probably just recently joined Ops, so welcome!
@@ Line 17: / Line 17: @@
   * The most basic thing we're responsible for is making sure that beam is being sent when it should be, and not being sent when it isn't. But it's also crucial to keep track of the beam's details. When you have the chance, mosey over to the large TV's hanging above the Control Room doors. This provides a great map of the accelerator and other parts of the beamline, but also some very important numbers. The one I find myself checking the most is __Beam Power__, which can be thought of as a measurement of how much beam is being sent. If the beam is being stopped by the __Chopper__ then __Beam Power__ will be zero. You can imagine that there are some pretty tight restraints on our __Beam Power__, and another one of our key responsibilities is keeping this at an acceptable figure.
   * What is acceptable? Great question, our __Operational Safety Envelope__ or __OSE__ is a document that provides guidelines for what we're allowed to do. Violating the __OSE__ is a serious matter, but exists so that we can self govern to some extent and avoid violating the __Accelerator Safety Envelope__, which is external and could get us in some pretty serious trouble. They are intimidating documents, but feel free to ask other Operators for assistance when referencing or reading through them.
+**Notes**
+- In the second point, perhaps take out some of the details about the chopper. Reserve these for a good and thorough explanation in another section dedicated for specific equipment in the beam line. Replace with some description of how pages on Phoebus are displayed, and how to navigate them?
 ==== Why do I keep hearing Alarms? Phoebus====
   *Don't worry! The annunciator might be constantly reminding you that there's "30 Active Alarms", but having some be active is normal and more steeped in office politics than I'd like to go into. You should not however ignore the annunciator.
   *Firstly, you may have noticed that there are two voices for the annunciator. One is a male voice that speaks much more frequently and one is a female voice that speaks infrequently, but will most likely repeat herself a few times. Theses are separate alarm systems, we'll look at the male voice first.
-  *This is the Phoebus Alarm System, named after the software it lives in. Phoebus Alarms come in three varieties, all being announced before the rest of the alarm. Those are "Minor", "Major", and "Invalid"(pronounced "In-va-lid"). To explain these, let's imagine some measurement that gives us 20 of some unit. Many devices are being monitored and measured so this could stand in for many devices,I'm just using 20 as a simple number. There are generally 4 limits associated with any measurement, the HI, the LO, the HIHI, and the LOLO. The HI and LO and numbers that are above and below the expected measurement, so for our example the HI could be 23 and the LO could be 17. These are often set as warnings that the measurement is shifting and that you should look into them before they potentially get worse. After that the HIHI and LOLO values are more extreme in both direction, so HIHI could be 25 and LOLO could be 15. These will tell us that the situation has gotten worse and things could potentially be in a bad state. HI and LO alarms will trigger a Minor alarm and HIHI and LOLO will trigger a Major alarm. Try to keep an ear out for these kinds of alarms.
+  *This is the Phoebus Alarm System, named after the software it lives in. Phoebus Alarms mainly come in three varieties, all being announced before the rest of the alarm. Those are "Minor", "Major", and "Invalid"(pronounced "In-va-lid"). You'll also see "Undefined" on rare occasion, but these often are apart of some larger bit of work going on. To explain these, let's imagine some measurement that gives us 20 of some unit. Many devices are being monitored and measured so this could stand in for many devices,I'm just using 20 as a simple number. There are generally 4 limits associated with any measurement, the HI, the LO, the HIHI, and the LOLO. The HI and LO and numbers that are above and below the expected measurement, so for our example the HI could be 23 and the LO could be 17. These are often set as warnings that the measurement is shifting and that you should look into them before they potentially get worse. After that the HIHI and LOLO values are more extreme in both direction, so HIHI could be 25 and LOLO could be 15. These will tell us that the situation has gotten worse and things could potentially be in a bad state. HI and LO alarms will trigger a Minor alarm and HIHI and LOLO will trigger a Major alarm. Try to keep an ear out for these kinds of alarms.
   *Invalid alarms notify when a measurement is "disconnected", there was some error in communication that are normally very short, but these should always be checked to make sure connection was reestablished.
   *For response advice, check [[task:phoebus_alarms|here]].
@@ Line 27: / Line 30: @@
 ====MPS====
-  * The __Machine Protection System__ is a system. It's purpose is to protect the machine. Sardonicism aside, it takes those measurements we discussed before and watches them. Some of those measurements can go into alarm without threatening the health of the machine, but many of these measurements can tell us that it is unsafe for the machine to try sending beam. NOTE: MPS only protects the beam, I'll talk about our __Personnel Protection System__ soon enough.
+  * The __Machine Protection System__ is a system. It's purpose is to protect the machine. Sardonicism aside, it takes those measurements we discussed before and watches them. Some of those measurements can go into alarm without threatening the health of the machine, but many of these measurements can tell us that it is unsafe for the machine to try sending beam. NOTE: MPS only protects the machine, I'll talk about our __Personnel Protection System__ soon enough.
   * A few things happen when MPS finds a measurement that stops us from sending beam, firstly remember that it does not watch every measurement. Some measurements correspond to devices that don't directly impact beam  and therefore aren't watched. Some measurements correspond to situations that do impact the beamline, but are localized to an area where we are not sending the beam. Some measurements do not live on the same system as the "ftc" network that controls the [[dev:chopper|Chopper]], so even if they do tell us that something is wrong and we should stop the beam ASAP, they cannot be read by MPS to stop the beam automatically.
-  * So let's say that we're sending beam and everything is working alright, suddenly "MAJOR ALARM: MPS FAULT". Now, we're not sending beam, that's stopped by the __Chopper__. If you try to tell the __Chopper__ to send beam, it won't listen. This is because the device for whichever measurement went bad is now [[info:plc_interlocks|Interlocked]]. Measurements can vary quite a bit, most have a certain "fuzz" of variation from noise or device fluctuations and to ensure that this doesn't cause the device to go in and out of alarm unceasingly, it may enter an [[info:plc_interlocks|Interlocked]] state. The device should be checked (quickly looking at it's other measurements is ok in many cases) before the [[info:plc_interlocks|Interlocked]] is reset. The __Chopper__ may not be restarted until all devices have good measurements and are not [[info:plc_interlocks|Interlocked]].
+  * So let's say that we're sending beam and everything is working alright, suddenly "MAJOR ALARM: MPS FAULT". Now, we're not sending beam, that's stopped by the __Chopper__. If you try to tell the __Chopper__ to send beam, it won't listen. This is because the device for whichever measurement went bad is now latched. Measurements can vary quite a bit, most have a certain "fuzz" of variation from noise or device fluctuations and to ensure that this doesn't cause the device to go in and out of alarm unceasingly, it may enter a latched state. The device should be checked (quickly looking at it's other measurements is ok in many cases) before the latch is reset. The __Chopper__ may not be restarted until all devices have good measurements and are not latched.
   * One final note is that MPS does not watch any measurements when the __Chopper__ is off. They are very closely linked and sometimes it's convenient to allow devices to be adjusted without causing 100 alarms, so this can be done at any time by stopping beam with the __Chopper__. Sometimes we would like to watch those measurements but not send beam, this can be done by blocking the beam with devices other than the __Chopper__, for now it's good that you know this but the details aren't urgent to know. Feel free to ask another Operator to satiate your curiosity (Hint: mention "1102" and they should know exactly what you're talking about.)
   * Read more  [[task:mps_trips|here]].
@@ Line 35: / Line 38: @@
 ====Voice Alarms & PPS====
   * Voice Alarms are the other variety of alarms you'll hear on occasion, they have a female voice and will repeat until an Operator acknowledges them, They live on totally different software than the Phoebus Alarms and are generally more scary. The main differences are that these alarms can encompass personnel safety, such as low O2 levels in an area or excessive flammable gas in another. There is also a big folder of responses to these alarms behind the main desk labelled "VOICE ALARM RESPONSES". If there is ever a voice alarm, I would recommend trying to find it in that folder if nobody else is looking at it.
-  * Similarly, there is a big yellow box to the side of the main desk, this is the __PPS Rack__. It's main purpose is to make sure that there are no people in areas that will contain beam. It works in a more complicated way, but that's its main function. Before sending beam, we need to make sure that the __PPS Rack__ says it's ok first. If the __PPS Rack__ doesn't think it's ok, then it yells real loud and it's the scariest sound in the Control Room. It looks at some measurements for devices that you can control on the "ftc" network, but it also looks at which areas are "secure"
+  * Similarly, there is a big yellow box to the side of the main desk, this is the __[[info:pps_background|PPS]] Rack__. It's main purpose is to make sure that there are no people in areas that will contain beam. It works in a more complicated way, but that's its main function. Before sending beam, we need to make sure that the __PPS Rack__ says it's ok first. If the __PPS Rack__ doesn't think it's ok, then it yells real loud and it's the scariest sound in the Control Room. It looks at some measurements for devices that you can control on the "ftc" network, but it also looks at which areas are "secure"
-  * Securing an area means doing a __Search and Evict__ which is a sweep of the area to ensure no one is in there. Operators do many __Search and Evicts__, but other trained individuals can also perform them. During the __Search and Evict__ buttons are pressed throughout the area as it is searched for people, at the end a all entrances into the area are closed and the __PPS Rack__ will acknowledge it as secure. If there is any error in the __Search and Evict__ or if the doors into the area are opened then the area will no longer be secured. This can range from an inconvenience of having to re-secure the area to the __PPS Rack__ freaking out as it is possible that a person could have entered an area containing beam. This will //violently// shut off many devices and is very bad for them. Accidents happen, but ensure to read the __Stack Lights and Signs__ outside of every door before opening it.
+  * Securing an area means doing a __Search and Evict__ which is a sweep of the area to ensure no one is in there. Operators do many __Search and Evicts__, but other trained individuals can also perform them. During the __Search and Evict__ buttons are pressed throughout the area as it is searched for people, at the end all entrances into the area are closed and the __PPS Rack__ will acknowledge it as secure. If there is any error in the __Search and Evict__ or if the doors into the area are opened then the area will no longer be secured. This can range from an inconvenience of having to re-secure the area to the __PPS Rack__ freaking out as it is possible that a person could have entered an area containing beam. This will //violently// shut off many devices and is very bad for them. Accidents happen, but ensure to read the __Stack Lights and Signs__ outside of every door before opening it.
-  * Read more about [[task:voice_alarms|Voice Alarms]] or [[task:pps_alarms|PPS Alarms]].
+  * Read more about [[task:voice_alarms|Voice Alarms]] or [[info:pps_background|PPS]].