Content
# #south-county — 2025-12-06
**11:06 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765047985613249):**
![[F0A1JQNDKCP_image.png]]
**11:06 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765047999804109):** it may be related to this. this was part of what prompted me to add that task to our to-do list.
**11:06 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765048012514789):** there is some clean up needed there.. im looking into the CCT plc now
**11:07 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765048048852639):**
```
typically indicates that the controller (PLC) is running low on available memory or resources needed to handle the alarm and event subscriptions requested by the FactoryTalk View SE server.
```
**11:07 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765048063496399):**
```
The issue is usually on the controller's side, not the FactoryTalk View SE software itself.
```
**11:11 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765048303978649):**
![[F0A2D6A7D6D_image.png]]
**11:15 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765048508533299):**
![[F0A1TSSNY3D_image.png]]
**11:15 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765048544971969):** rut roh
**11:16 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765048580386399):** checking alarm and events server.. there are only analog alarm objects in the PLC. it should still alarm on the A&E alarms i think
**11:16 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765048586469699):** but this PLC is maxed out
**11:16 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765048605036099):** and starting to cause problems.. a power cycle may clear up some memory but not an ideal solution
**11:20 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765048827025949):** I wonder why this is a problem now?
**11:20 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765048833330509):** we haven't added anything to the plc
**11:21 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765048872931829):**
![[F0A2094CZPU_image.png]]
**11:21 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765048879752799):** the notice came in on 12/2
**11:21 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765048887325989):** but i did make changes yesterday
**11:21 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765048903192649):** mychal called on the fail to stop alarm for these pumps
**11:22 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765048923109079):** i added two rungs, no new tags.
**11:23 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765048997115969):** I don't remember ever checking the memory after we went Pax
**11:23 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765049012820159):** it's probably been on edge for a while
**11:23 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049027207819):** it is in the yellow now, but the peak was well into the red
**11:24 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049046738439):** i think this was an issue and we limited the pax objects in this PLC
**11:24 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049051009299):** i very vaguly remember
**11:24 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049077679409):** and what the heck is all this
![[F0A1JRW1ECF_image.png]]
**11:24 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049099583379):** the system needs to be cleaned up.. likely with the help of support
**11:25 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049120625739):** possibly comm issues.. or rockwell software issues
**11:27 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049235936579):**
![[F0A209J3H7U_image.png]]
**11:27 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049258608369):** well.. this is part of the issue. it failed to start at 11pm last night and the alarm condition cleared 6 seconds later.
**11:27 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049262775469):** thats why it didnt call out
**11:27 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049274660909):** i dont know why it cleared itself
**11:28 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765049284646419):** hmmm
**11:29 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049351366349):**
![[F0A1JS63CLX_image.png]]
**11:29 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049362708429):** if we enable reset required it shouldnt do that? that essentially latches it i think
**11:32 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049522300539):** losing faith in PAX objects even with FT faceplates. I really like to understand how all the logic works and what its all doing.
**11:32 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765049550700569):** what should we do here today?
**11:34 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765049642796639):** 1. explain why they didn't get an alarm when the chlorine pump stopped
2. do something to fix it
3. test it
**11:40 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050014350049):** i dont have a lot of time right now, think they will be ok until tonight/tomorrow/monday?
**11:40 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050047063459):** i can enable the reset required as a "maybe temporary fix"
**11:42 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765050153451829):** yes. enable that for now. I will jump in and see if I can come up with something
**11:43 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050198859559):** there is an AOI for alarms.. that gets called from other AOIs.. i think.. i have a feeling its going to be very difficult to make sense of the alarm logic
**11:43 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050218831229):** p_alarm
**11:44 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765050266847679):** I don't plan on messing with that. gonna find another way to alert them
**11:45 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050302144649):** gotcha. we could do an alarm bit outside of PAX objects.
**11:45 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050305784459):** whos logic we control
**11:46 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765050367397109):** so the alarm didn't call because it auto reset
**11:46 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050368337079):**
![[F0A2UL2KF6C_image.png]]
**11:46 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050377865069):** also just noticed that there is no flow signal
**11:46 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050379456459):** or no flow
**11:46 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050398231569):** the fail to start condition cleared immediately
**11:47 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765050445421189):** the pump should never shut off. I need to figure out how we are getting a fail to start
**11:48 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050489434689):** the run status is based on the feedback signal
**11:51 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765050683045639):** thanks for jumping in and checking on this
**11:51 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050693331559):** we could trend the feedback signal
**11:51 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050695870549):** see if its dropping out
**11:52 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765050727638739):** we could alarm on flow rate (right now its not showing flow which should probably be an alarm?)
**11:52 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765050777089319):** those flow meters suck
**11:57 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051026283569):** hold on
**11:57 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051030016629):** may have found something
**11:57 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051071843069):**
![[F0A20BJGJ3C_image.png]]
**11:58 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051091299469):** so the critical alarm (severity 1000) notifcation thing was triggered.. and tried to call relentlessly as intended
**11:58 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051114908499):** but its saying that it skipped each dial out "based on send notification settings"
**11:59 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765051193088609):** notification settings in win911?
**12:00 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051226496269):** yeah
**12:00 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051230408149):** looking
**12:00 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765051242785369):** thank you
**12:05 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051503869239):**
![[F0A2UMC4WKA_image.png]]
**12:05 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051541582789):** combination of things here.. i think because the alarm cleared itself immediately and the critical alarm policy is not set to call on inactive + unack alarms..
**12:06 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051560407789):** still looking
**12:06 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051601521899):** so if we change the crtical alarms to call on inactive + unacknowledged it would have called.
**12:06 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051615114449):** the real question is why did it go fail to start.. and THEN why did the condition clear itself
**12:10 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765051830413239):** Indeed
**12:12 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051926195609):**
```
1. The Primary Cause: Alarm Auto-Cleared Immediately
The main reason the system failed to dial out is that the "Fail to Start" alarm condition cleared itself only 6 seconds after it triggered (at 11:00 PM).
The Mechanism: Because the alarm condition disappeared (became "Inactive") so quickly, the WIN-911 system saw the alarm as "Inactive" by the time it attempted to process the notification.
The Policy Mismatch: The WIN-911 "Critical Alarms" policy was likely configured not to call out for alarms that are in an "Inactive + Unacknowledged" state. Since the alarm was already inactive, the system skipped the call "based on Send Notification settings."
2. The Underlying Process Issue
The users are unsure why the alarm cleared itself so fast.
Feedback Signal: The pump's "run status" relies on a feedback signal. The users suspect the feedback might have dropped out momentarily, triggering the "Fail to Start," but then returned or stabilized, clearing the alarm condition immediately.
Proposed Fixes:
Short Term: Enable "Reset Required" on the alarm tag. This would "latch" the alarm, preventing it from auto-clearing even if the condition resolves, which would force the WIN-911 system to complete the callout.
WIN-911 Config: Change the notification policy to dial out even if an alarm is "Inactive + Unacknowledged."
3. Secondary Issue: PLC Memory Limits
While investigating, the users discovered a separate critical health issue:
Memory Warning: The CCT Controller (PLC) is "maxed out" on memory.
Subscription Errors: This low memory caused the "Unable to subscribe to alarms... Insufficient memory" error seen in the earlier logs.
Impact: Although the users determined the callout failure was due to the auto-clear issue described above, the memory issue poses a risk for future alarm reliability and needs to be addressed (possibly by cleaning up code or upgrading hardware).
```
**12:12 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765051939482489):** AI summary of findings.
**12:14 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765052088758309):** I enabled reset required for all 4 chemical pumps.
**12:14 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765052093623869):** Perfect thank you. I wonder, Mike said there was an alarm bell on the pump and the pump was off. He had to reset it to get it to start again. seems to me this should have been an "active " alarm
**12:15 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765052103805159):** agreed.
**12:15 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765052108935269):** ok
**12:15 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765052122540319):** that doesnt make a lot of sense either.
**12:16 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765052166437129):** i think we need to spend some time on cleaning up this system.
**12:18 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765052313421269):** want to plan that for Monday? I think if you spend a morning with support you can maybe figure some things out?
**12:20 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765052403761029):** all we can do is try.. the problems arent as clear as i would like.. its going to be hard to describe these "problems"
**12:20 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765052442361789):** Let's plan to sit down together and define the problems
**12:20 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765052443553019):** but i can do that monday and see how it goes.. i dont think its going to be a quick fix.
**12:20 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765052449841399):** yeah. that needs to be done
**12:20 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765052453377439):** good idea.
**12:21 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765052476850299):** i can do that this afternoon or tomorrow
**12:21 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765052492978589):** but i need to get going right now
**12:21 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765052501786459):** go
**12:21 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765052504216159):** thank you!
**13:20 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765056007962539):** Having Mike stop the chlorine pump for 5 seconds
**13:32 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765056753868519):** Mike unplugged the power to the pump. it took about 5 seconds for the alarm to trigger on scada.
**13:32 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765056776791259):** the alarm triggered, and the call out came from Win911.
**13:33 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765056800193039):** The fail to start did not auto reset.
**13:35 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765056944196549):** what I noticed was after he unplugged it, the analog signal went up and down, as with the running signal on/off, like 3 times before it settled down to zero.
**14:03 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765058601468959):** prompt to Gemini:
using the attached document, please present some ideas as to why the "alarm bell" icon would be displayed on the pump object but the alarm was inactive. I may need to also upload to you the P_VSD documentation
**14:03 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765058621538279):** I uploaded the P_Alarm portion of the pax doc
**14:03 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765058626338549):** Reply
**14:08 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765058899029789):** Based on the `P_Alarm` documentation provided, there are several logic states that could cause an alarm indicator (the "bell") to remain visible on the HMI even if the physical alarm condition (the input) appears to be inactive or cleared.
Here are the potential causes based on the Add-On Instruction's logic:
1. The Alarm is Latched and Requires a Reset
The most common reason for a lingering alarm indicator when the equipment seems fine is the "Reset Required" configuration.
•
• *The Logic:* If the parameter `Cfg_ResetReqd` is set to 1, the alarm condition is latched1. Even if the physical input clears (returns to normal), the alarm state remains active (`Alm` status remains 1) until a specific Reset command is received2.
•
• V*isual Result:*
• The HMI would display the alarm bell because the instruction is still technically "In Alarm" waiting for an operator reset, even though the pump itself is no longer sending a fault signal.
2. The "Minimum On" Timer Has Not Expired
The instruction includes a timer to prevent alarms from flickering on and off too quickly.
•
• *The Logic:* The parameter `Cfg_MinOnT` sets a minimum amount of time (in seconds) that an alarm must remain in the alarm state3. The instruction ensures the alarm stays on for this duration even if the input condition clears immediately4444.
•
• Vi*sual Result:*
• If a fault spiked for only a millisecond but the timer is set to 5 seconds, the alarm bell will remain on for the full 5 seconds after the fault has already disappeared.
3. The Alarm is "Shelved" or "Suppressed"
Operators or logic can "shelve" (temporarily hide) or "suppress" alarms.
• T*he Logic:*
• When an alarm is shelved or suppressed, it does not clear until the input condition clears, and if latched, it still requires a reset5555.
• Vi*sual Result:*
• While shelving typically hides the
• _notification_ (banner), many HMI standards (referenced as `PROCES-RM014` 6) use specific icons (like a bell with a slash or a different color) on the pump object to remind the operator that an alarm exists but is currently being ignored or hidden7.
•
4*. Acknowledge Is Required*
•
• *The Logic:* If `Cfg_AckReqd` is set to 1, a new alarm clears the "Acknowledged" status8.
•
•
• *Visual Result:* Even if the condition clears, if the alarm state is latched or held, the bell may flash or change color to indicate it is "Unacknowledged"9. The alarm bell will persist until the operator acknowledges it.
•
•
5. Embedded Alarm Status
The document notes that P_Alarm blocks are often embedded within other instructions, such as a Motor or VSD block10.
•
• *The Logic:* The containing object (the Pump/VSD) aliases the `P_Alarm` outputs (Alm, Ack, Disabled, Shelved)11111111.
•
• V*isual Result:*
• If you are looking at the Pump object, the bell is likely a composite status. If _any_ embedded alarm (Fail to Start, Interlock Trip, etc.) is in one of the states listed above (Latched or Unacknowledged), the Pump object will display the alarm bell.
Summary for Troubleshooting:
To determine exactly why the bell is on, you should look at the specific instance of the P_Alarm (or the P_VSD running the pump) and check the status of these three tags:
1.
2. *Alm* (Is the logic still holding the alarm true?) 12
3.
4.
5. *Ack* (Is it waiting for acknowledgement?) 13
6.
7.
8. *Cfg_ResetReqd* (Is it latched waiting for a reset?) 14
9.
10.
**14:08 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765058923801519):** Terrible formatting translation though....have to figure that out
**14:42 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765060970550689):** I uploaded Gemini the P_VSD instructions and promted:
Here is the P_VSD instructions. The issue we are interested in figuring out is how the fail to start alarm can trigger, the pump logic stopped the pump with a fault (stop sign icon), but the fail to start alarm automatically reset and the pump stayed off.
**14:42 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765060976653279):** Reply:
**14:43 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765061024454329):** Based on the P_VSD manual and your description of the incident, here is an analysis of why the "Fail to Start" alarm could trigger, shut down the pump, and then auto-reset.
1. The Alarm Configuration: "Reset Required" (Cfg_ResetReqd)
The key to the auto-reset behavior lies in the Cfg_ResetReqd parameter.
• *If Cfg_ResetReqd = 0:* The alarm is *not latched*. It will clear automatically as soon as the input condition clears or the command changes.
• *If Cfg_ResetReqd = 1:* The alarm is *latched*. It requires a manual reset command to clear, even if the condition returns to normal.
Scenario Analysis:
It is highly likely that your FailToStart embedded alarm has Cfg_ResetReqd set to 0 (Auto-Reset).
1. *Trigger:* The logic commanded the pump to start. The FailToStart timer expired because Inp_Running (Run Feedback) did not turn true.
2. *Action:* The FailToStart alarm triggered. This is a "Shed Fault" (as noted in the manual 1111), which forces the pump logic to *Stop*.
3.
4. *The Auto-Reset Loop:*
• Once the pump logic forces the command to *Stop*, the mismatch condition (Command Start vs. Feedback Stop) disappears.
• Since the command is now Stop and the feedback is Stop, the "Fail to Start" condition is no longer true.
• Because Cfg_ResetReqd is 0, the alarm automatically clears itself.
5. *Result:* The pump remains stopped (because the shed fault killed the start command), but the alarm banner disappears, leaving the operator confused as to why it stopped.
2. The Stop Sign Icon (Shed Fault)
You mentioned the "Stop Sign" icon appeared.
• *Meaning:* In this library, a Stop Sign usually indicates a *Shed* or *Shutdown* condition22. This confirms that the FailToStart alarm successfully executed its shutdown logic.
•
• *Why it stayed off:* Even though the alarm reset, the P_VSD logic drops the Out_Run command when a shed fault occurs. The logic does _not_ automatically restart the pump just because the alarm cleared; it requires a new start command3333.
•
3. Recommendation
To prevent this "vanishing alarm" scenario, you should change the configuration for the embedded FailToStart alarm.
• *Action:* Locate the FailToStart parameter group within the P_VSD instruction.
• *Change:* Set Cfg_ResetReqd to *1*.
• *Result:* When a Fail to Start occurs, the alarm will latch. The pump will stop, but the alarm banner (and the red bell icon) will remain active until an operator physically clicks "Reset." This forces acknowledgement of the failure.
**14:44 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765061080433169):** then I prompted:
**14:44 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765061081989609):** we would rather the logic doesn't drop the out_run on fail to start or fail to stop. is there a way to disable this action?
**14:44 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765061084612839):** reply
**14:45 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765061110471739):** Yes, there is a way to disable the drive shutdown (shed) action for the *Fail to Start* alarm.
According to the *P_VSD* documentation:
•
• *Fail to Start:* The manual states that the "Fail to Start" condition "can be configured to *alarm only*, or to de-energize the motor (shed)"1.
•
• If enabled as a "shed fault," the drive is stopped and requires a reset2.
• To disable this, you need to find the configuration tag associated with the
◦ `FailToStart` alarm (typically named something like `Cfg_FailToStartShed` or `Cfg_HasFailToStartShed` in this library's tag structure) and set it to *0*. This will allow the alarm to trigger without forcing `Out_Run` to drop.
•
• *Fail to Stop:* The manual notes that "Fail to Stop" is raised when the drive is commanded to stop but the feedback does not indicate it has stopped3.
•
• The documentation does *not* list a "shed" configuration option for "Fail to Stop" like it does for "Fail to Start"4.
•
◦
◦ _Technical Note:_ Since a "Fail to Stop" alarm implies the logic is _already_ commanding the drive to stop (i.e., `Out_Run` is likely already 0), there is no "run command" to drop. The logic is already trying to de-energize the output; the alarm is simply notifying you that the physical device isn't responding.
Summary of Change:
To prevent the "Fail to Start" alarm from stopping the pump logic, locate the configuration bit for Fail to Start Shed (likely Cfg_FailToStartShed) and change it to 0.
**14:50 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765061402950759):** trying a different format
**14:50 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765061450356279):**
```
Here is the text formatted specifically for Slack. You can copy and paste the block below directly into your chat.
***
Yes, there is a way to disable the drive shutdown (shed) action for the *Fail to Start* alarm.
According to the `P_VSD` documentation:
*Fail to Start:*
[cite_start]The manual states that the "Fail to Start" condition "can be configured to *alarm only*, or to de-energize the motor (shed)"[cite: 577].
* [cite_start]If enabled as a "shed fault," the drive is stopped and requires a reset[cite: 578].
* To disable this, you need to find the configuration tag associated with the FailToStart alarm (typically named something like `Cfg_FailToStartShed` or `Cfg_HasFailToStartShed` in this library's tag structure) and set it to `0`. This will allow the alarm to trigger without forcing `Out_Run` to drop.
*Fail to Stop:*
[cite_start]The manual notes that "Fail to Stop" is raised when the drive is commanded to stop but the feedback does not indicate it has stopped[cite: 570].
* [cite_start]The documentation does *not* list a "shed" configuration option for "Fail to Stop" like it does for "Fail to Start"[cite: 570].
* *Technical Note:* Since a "Fail to Stop" alarm implies the logic is already commanding the drive to stop (i.e., `Out_Run` is likely already `0`), there is no "run command" to drop. The logic is already trying to de-energize the output; the alarm is simply notifying you that the physical device isn't responding.
*Summary of Change:*
To prevent the "Fail to Start" alarm from stopping the pump logic, locate the configuration bit for Fail to Start Shed (likely `Cfg_FailToStartShed`) and change it to `0`.
```
**14:53 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765061627635659):** Damn. That’s a good idea. Having it parse the AOI
**14:58 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765061901267739):** Test sounded like it went well. I can also add a delay on or delay off to the run status
**14:59 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765061960744649):** yeah the test worked exactly like we think it should. not sure if it was because of the change you made.
**20:06 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765080392475259):** Mike text says he got multiple chemical pump alarms around 1930
Alarm history shows all 4 pumps tripped Drive Fault at the same time
Investigating what causes those faults
**20:10 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765080607086239):** Man, what is going on? Does it feel like comm issues?
**20:11 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765080661695859):** It could be, but I thought we set those RIO cards to not go to 0 when comm loss happened
**20:11 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765080710420379):**
```
Based on the **P_VSD** instruction manual, the `Val_Fault` output (which indicates the specific fault code) is triggered by one of the following five alarm conditions.
[cite_start]These conditions are monitored and implemented by embedded `P_Alarm` instructions within the P_VSD logic[cite: 152]:
* **Drive Fault**
* [cite_start]**Trigger:** Raised when the physical drive detects an internal fault and sets its `Faulted` status bit[cite: 153].
* [cite_start]**Input:** This is typically linked to the `Inp_Faulted` parameter or read via the drive's datalink[cite: 511, 549].
* **Fail to Start**
* [cite_start]**Trigger:** Raised when the instruction sends a start command, but the Run Feedback (`Inp_Running`) does not confirm the drive is running within the configured time limit[cite: 153].
* [cite_start]**Note:** This can be configured as a "shed fault" which will de-energize the drive output[cite: 160].
* **Fail to Stop**
* [cite_start]**Trigger:** Raised when the instruction sends a stop command, but the Run Feedback (`Inp_Running`) does not indicate that the drive has stopped within the configured time limit[cite: 153].
* **Interlock Trip**
* [cite_start]**Trigger:** Raised when the drive is actively running and an Interlock "Not OK" condition occurs, causing the drive to stop[cite: 153].
* **Behavior:** If interlocks are **not bypassed**, *any* interlock (bypassable or non-bypassable) will trigger this trip. [cite_start]If interlocks **are bypassed**, only a *non-bypassable* interlock will trigger it[cite: 153].
* **I/O Fault**
* [cite_start]**Trigger:** Raised when the `Inp_IOFault` input is true[cite: 153].
* [cite_start]**Cause:** This input is used to indicate a communication failure with the drive's I/O or network card[cite: 153].
```
**20:12 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765080733473119):** we don't have inputs for Drive Fault
**20:13 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765080827461579):** I wonder if we bump up these timers
![[F0A1UUUQC03_image.png]]
**20:13 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765080837095559):** for start and stop feedback
**20:14 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765080891374249):** Is that related to the drive faults?
**20:16 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765080992399339):** start and stop fail
**20:16 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765081014252529):** I bumped the start fail delays to 60 seconds for grins
**20:17 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765081035877929):** I don't know why we would have gotten all 4 alarms
**20:17 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765081049937879):** they can't all be fail to start
**20:20 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765081205154899):** Did they get failed to start alarms or drive fault alarms
**20:25 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765081510515949):** drive fault
**20:25 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765081532649179):** it's too weird. I think the PLC is glitching
**20:26 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765081575568559):** I talked to Mike. He will disable the alarms if they come in again tonight. He will be fine with the ORP alarm to alert to a problem.
**20:26 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765081607852959):** I’m not sure why we have a drive fault alarm if there’s no fault input. Unless we tied some logic to the fault.
**20:29 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765081754897739):** I looked and didn't see anything tied to the fault input
**20:30 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765081858844849):** Yeah, not sure how it triggered. Or why it’s even enabled. We need to give the system some love.
**20:32 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765081973195219):** I was wrong
![[F0A1ZALTFPG_image.png]]
**20:33 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765081983796329):** there are DIs
**20:33 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765081993151999):** Ah
**20:33 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765082007792169):** All 4 going seems like network
**20:33 [Mason Radke](https://slack.com/archives/C08G4KZG7D5/p1765082019707509):** I feel there are network issues
**20:33 [Kevin](https://slack.com/archives/C08G4KZG7D5/p1765082026867299):** I think you are right