[Challenge] Pump Rotation Logic

[Giantsbane]

Objective:

Your task is to design pump rotation logic using any available logic blocks in Niagara 4 (N4) that efficiently manages duty/standby pump operation based on runtime. You will implement logic to control two pumps (Pump A and Pump B), ensuring that the pump with the least runtime is activated first and that pumps rotate appropriately when stopped.

Instructions:

Setup:

• You have two pump enable outputs: PumpAEna and PumpBEna.
• You have two pump status inputs: PumpASts and PumpBSts.
• You also have a PumpCall input that triggers the start of a pump.

Logic Requirements:

1. Runtime Comparison:

• When PumpCall is active, the pump with the least runtime should be enabled.
• Ensure that the pump selection is latched so that it does not switch during operation, even if the runtime exceeds that of the other pump.

2. Rotation Logic:

• When both pumps indicate stopped (PumpASts and PumpBSts are false) and PumpCall is disabled, rotate the pumps so that the pump with the least runtime becomes the next one to start.
• Use a boolean point to indicate the next pump to run, with facets trueText=PumpB and falseText=PumpA.

3. Manual Rotation:

• Implement a trigger for manually rotating the pumps. When triggered, the pump selection ignores runtime, and the pump that is not the current duty pump becomes the new duty pump.

Tools:

• Use appropriate logic blocks (e.g., Comparators, Latch, And, Or, etc.) to achieve the desired behavior.

Testing:

• Test the logic by simulating the activation of PumpCall and checking that the correct pump is enabled.
• Verify that the pump selection is latched during operation and does not switch mid-operation.
• Test the rotation logic by disabling PumpCall and ensuring that the pumps rotate as required.
• Manually trigger the pump rotation and confirm that the non-duty pump becomes active.

Submission:

• Save your work and submit the completed Niagara 4 file (.bog) as a reply to this post.
• Include a brief explanation of the logic you implemented, why you chose the specific components, and how you ensured the logic meets the requirements.

[Rosenthaler]

PumpRotationLogic.bog (1.8 KB)

Not sure if I overcomplicated my solution I’m really tired and wasn’t sure about the pump status, as I would usually just read and log on the outputs.

This was a nice challenge I like it a lot!

[Giantsbane]

@Rosenthaler Unfortunately I have to give you a fail on this one. It is almost correct, however:

• There is no Boolean point indicating the active duty pump
• The pump cannot be manually rotated unless the pump call is active
• If the pump call is active and the pump is manually rotated the pump changes to the standby pump. However if the pump call is deactivated while manually rotated. When the pump call is inactive BOTH pumps are enabled.
• If the pump was manually rotated and the pump call is disabled. You cannot relinquish control back to the normal rotation.

[Giantsbane]

My submission, using only primitive logical blocks.

PumpRotation.bog (1.7 KB)

[Zygan]

not laid out as pretty but works

config.bog (7.9 KB)

note wouldnt use this logic as i would want clear points for which pump is in lead and standby etc + i would usually have a fault rotation. i just used the challenge to see how little blocks i could use.

[ControlFreak]

Gentlemen, this is my take on this project. I found a good part of the logic on youtube. This prompted me to use a “Discrete Totalizer” coupled with a “LeadLagRuntime” block, with feedback from the totalizer runtimes fed back into the LeadLagRuntime blocks. I have the two overides fed into or blocks to run the outputs. In reality, doesn’t do exactly what Objective asks for (I’m missing the latching mechanism, the “Next Pump” and PumpSts, but…maybe I’ve step up to the spirti of the challenge a bit (pretty much above my paygrade, but I wanted to at least try.

PumpRotationLogic.bog (1.8 KB)

[Giantsbane]

Challenge accepted! Looking forward to trying to break it!

[Giantsbane]

@Zygan, I’ve interrogated the logic and found a couple of issue.

Interrogation Process

1. I reset the Elapsed Active Time for PumpA and PumpB
2. Enabled the PumpCall
   • PumpB was Enabled → Elapsed active time incremented as it should
3. Disabled the PumpCall
   • PumpA and PumpB went to Idle as expected
4. Re-enabled the PumpCall
   • PumpB was enabled. This is not the expected behaviour. PumpB Runtime > PumpA Runtime. Pump A should have been enabled.

5. I repeated step 4 multiple times and each time PumpB was enabled.
6. Triggered Manual_Rotate. This rotated the pumps as expected.
7. When PumpA Runtime → PumpB Runtime and the pump call is cycled the Pump rotates from PumpA to PumpB as expected.

Issue

Pump rotation only works in one direction. When PumpA Runtime is greater than PumpB. However when PumpB is greater than PumpA the rotation does not work unless manually rotated.

The issue lies in the ExprLogic block: inA and !inC and inD as 'out' see if you can figure it out

Note, these reviews are not intended to discourage anyone! I understand these are challenges we are slapping together in our own time, and thus we probably don’t give them the same level of attention as would in our normal working life!

The hope is that we can share and learn together from our wins and losses. I encourage you to break my logic too, I am certainly no stranger to mistakes!

[Giantsbane]

@ControlFreak, you’ve submitted @Rosenthaler’s PumpRotationLogic.bog. Must have selected the wrong file .

[ControlFreak]

ChallengePumpLogic_Lee1.bog (1.4 KB)

Sorry about that. Still learning to navigate the tree. Every step brings me closer, but sometimes it feels like a process of elimination! Thank you for your patience and I do appreciate your review of these challenges to tell me how I can improve.

[Giantsbane]

@ControlFreak

ChallengePumpLogic_Lee1.bog (1.4 KB)

@ControlFreak I have reviewed your code

Interrogation Process

1. I reset the Elapsed Active Time for PumpA and PumpB.
2. Enabled the PumpCall
   • PumpA was Enabled → Elapsed Active Time incremented as expected
3. Disabled the PumpCall
   • PumpA & PumpB were Disabled as expected
4. Re-Enabled the PumpCall and PumpB was Enabled as expected
5. While PumpB was Enabled the LeadLagRuntime block did not receive pump status causing it to fault roll over back to PumpA.

6. PumpA & PumpB Overrides work however they override the PumpCall. This is not desirable for two reasons.
   • The pumps can run outside of the normal schedule and are no longer governed by automatic control.
   • Both pumps can run simultaneously which may be detrimental to the system. Generally in a duty/standby situation the system pipe sizing and so on is sized for only 1 pump. The second pump is to provide redundancy should one of the pumps fail.
7. In the real world I’d like to see points that displays which is the duty pump and which is the standby pump. This is something a consultant would want to see on the graphics.

Otherwise nice work @ControlFreak defiantly a great attempt! Only those small issues I could find.

[ControlFreak]

Thank you. Yes, I was looking to put the pump status in, but to be honest, at that point, the complication was…really above my pay grade. Thank you for the input on what I did get down. In the end I just had to “throw it at the wall and see if anything stuck.” But I hate not even trying. This is high praise coming from you guys. I’ll just keep trying!!!