pcdshub / lcls-twincat-pmps Goto Github PK

There should be some mechanism to alert everyone daily that there are pmps overrides active, as per the morning tailgate today

Pulse energy is not a knob we can really turn, so we'll be removing it (from pytmc)

File here:

References commented out property:

An uninitialized variable found here may be causing some issues. While the code can normally be built in normal conditions, builds preempting a "login w/ change" fail. Pihl speculates that this could be a potential cause of the issue.

DUMMY_AUX_ATT_ARRAY : ARRAY [1..PMPS_GVL.AUX_ATTENUATORS] OF ST_PMPS_Attenuator;

Current Behavior

No such PV

Expected Behavior

I should be able to caget a value that lets me know if an arbiter is vetoed or not.

Context / environment

Latest

Suggested Solution

• Add a pragma'd BOOL to FB_Arbiter (and all I_LowerAuthority things)
• Write to this pragma's BOOL from FB_VetoArbiter

BP_IO can be mismatched between versions leading to uncaught invalid structure mapping between BP_IO and BP.

BP_IO needs to carry a version number that can be used to catch mismatches.

We need a counter or something to indicate faults are "flapping."

The FB is is part of the pmps lib but will be used by the other PLCs / devices to fault on Pressure.
The FB should have as inputs Pressure threshold, hysteresys, gauge ok bit, and as inout output the FB_HardwareFFOutput.
Maybe also a veto input?

I tried to activate a bypass that was not already faulted as a preventative measure, but it rejected me.

This would have been good for testing the HOMS_XRT today to set the bypasses prior to there being any faults to prevent interruptions after the initial miscommunication.

This will be more generally useful in cases where a bad fault is intermittent and clears itself quickly.

Open to discussion

• ads-deploy works based on solution files
• #61 will fail without a solution file, and documentation will not be built

• :HAPPI pv linked to .HappiName could be used to open a relevant typhos ui straight from the diagnostic. This could be included both for FFOs and for the PVs we see in the pre-emptive request screen.
• :DESC pv linked somewhere for the pre-emptive request screen.

I intended to add these myself today but it's a bit late so I'm at least writing them down

For some reason no request in the arbiter pool evaluates to 10Hz.

Turns out this is because the ST_BeamParams_IO struct has 10Hz as the default value.... that should be corrected going forward.

Also the arbiter should probably initialize with an elevation cycle request.

If we include a PV that shows whether a fast fault is vetoed, then we can include that information in the pmps ui. This will make it more clear why some of these faults are "not ok" but "beam allowed".

Inspired by https://slac.slack.com/archives/CUC9NLU8H/p1633314475350600

Confirm that it should be represented as a 1 or a %.

Change F_AttenuatorOK to use bit labels once they're being used in the struct.

Create a FB_JsonToDoc That will:

1. Read a local json file (check the file is correct)
2. Parse the file into a global PMPS.JsonDoc, that will be available to all devices to load their states BP.

Create a FB_JsonDocToBP That will:

1. Parse the global JsonDoc object, find the device/state data and load them to the PB structrue.

Dynamic and static selection of a beam parameter request set as a function of photon energy and based on Current Beam Class.

Note these currently active overrides, where the start time is on the 26th and the end times are earlier in the month

When the device is requested to move, part of it's safe beam parameters include this new beam class bit mask that first evaluates if it is ok for this device to be inserted or fault accordingly.

Need to modify preemptive request system to provide a device name associated with a request ID inline in the PMPS UI. This probably doesn't have to happen in the core beam parameter structure.

Update to 32bit eV ranges

Transmission (rather than attenuation) is a more natural parameter and is technically more failsafe.

This might be more for LCLS General... an FB that can verify the value of a "global constant" against what another PLC has. Useful in instances with the PMPS where the arbiter and subsystem PLCs keep independent versions of these constants. Think, photon energy bitmask ranges, or full beam rate.

The FB is is part of the pmps lib but will be used by the other PLCs / devices to fault on temperature.
The FB should have as inputs temp threshold and hysteresys, and as inout output the FB_HardwareFFOutput.
Maybe also a veto input. if the device is retracted, then the fault should be vetoed.

Instead, use an integer type to indicate state.

Between fast fault arrays and arbiter pools...

Given an array of photon energy ranges (high-low pairs), generate a bitmask using the constants.

Function block in the library, to copy the attenuator requests and status to and from the IO interface.
Currently, a P_SATT is running on lfe-arbiter and kfe-arbiter that includes a lot of repetitive statements for each PLC.

Need configurable eV range variants capability

Add nBeamClass
Add nBeamClassRange

Expected Behavior

• project files should not change their headers when the editor version changes
• unused configuration elements should not clutter the solution explorer

Context / environment

Recommended by Jakob in pcdshub/lcls-twincat-general#74
Jakob also makes recommendations based on the static-analysis-rules.csa file but only general lib uses this right now

Staring at the MPS diagnostic with zero logs is not the best. It would be better if FFOs checked in once every 24 hours or so

PMPS UI is ready, but the fast fault system needs to be changed to work with the date time representation, ideally in parallel with the ms representation.

The Transmission was an INT changed to Real.
The variable name needs to be changes. Its in the IO interface.

Can wait until enough changes are requested for the IO interface

Downstream libraries which include both lcls-twincat-general and lcls-twincat-pmps result in duplicate symbols for GVL_Logger which breaks IOC generation.

Unclear as to the exact fix; this needs some research.

Duplicate symbols:

$ pytmc summary --symbols plc/plc-kfe-vac/plc-kfe-vac.tsproj  |grep GVL_Log
    GVL_Logger.TCPADS_MAXUDP_BUFFSIZE : UDINT (3072800 32)
    GVL_Logger.TCPADS_MAXUDP_BUFFSIZE : UDINT (19932800 32)
    GVL_Logger.cLogHost : STRING(15) (3072896 128)
    GVL_Logger.cLogHost : STRING(15) (19932608 128)
    GVL_Logger.fbRootLogger : LCLS_General.FB_LogMessage (3073728 26944)
    GVL_Logger.fbRootLogger : PMPS.LCLS_General.FB_LogMessage (21634560 80896)
    GVL_Logger.iLogPort : UINT (3072144 16)
    GVL_Logger.iLogPort : UINT (19932512 16)
    GVL_Logger.sIpTidbit : STRING(6) (3073024 56)
    GVL_Logger.sIpTidbit : STRING(6) (19932736 56)
    GVL_Logger.sPlcHostname : STRING(80) (3073080 648)
    GVL_Logger.sPlcHostname : STRING(80) (19952480 648)

Note that the above symbols are allocated twice on the PLC at different locations.

Short-term hack to allow this bad behavior in pytmc:

pytmc db --allow-errors ...

GVL full beam has value 0 for all the nTran should be 1 for full beam.

@ZLLentz suggested 0hz to be full tran.