Thank you. These are the images for how the sensor is read in, another engineer recommended I use this method to bit shift. (RealSensorValue is our live current value)
https://ibb.co/X4t3kZf
https://ibb.co/S3dNN8V
This is the current logic I was using. Even when the LT condition was not true, my RealSensorValue was overriding the MinSensorValue. (RunEffortProgram is my 3 s delay on motor earlier in logic)
https://ibb.co/5K0KRN0
Yes, because the input rung to the MOVE instruction on rung 0014 is true, so whether the LT instruction evaluates to True is completely irrelevant.
Solution: look at @joseph_e2's comment about my code, and look at my code, to see how I ensure that the MinSensorValue is not
unconditionally overwritten once the while the 5s MinTimer is timing i.e. while RunEffortProgrm is 1 and MinTimer.Q is 0.
Quickest solution, starting from what you have:
- Rung 0014, top branch: insert a one-shot (pulse) just after the branch point and before the MOVE.
Better solution:
- Rung 0014: remove the bottom branch of Rung 0014
- Rung 0014: change the [NOcontact MinTimer.IN] to [NCcontact MinTimer.IN]
- Rung 0015: change the [NOcontact MinSensorValueSearch] to [NCcontact MinTimer.Q]
- Rung 0013: move this entire rung to after current rung 0015
- PLC programming is primarily about time, and the scan cycle is the primary clock; the secondary clock comprises rules for the order of execution of rungs and instructions.
- Thinking about and being aware of when something happens is more important than what is happening.
I strongly suggest you try both solutions, and try to understand why they work.
Also consider that the reason your code did not work, and you did not know why, was that you had two MOVE instructions that could be writing the value of RealSensorValue into MinSensorValue, and you had no idea which one was doing the writing; note that my code has only one such MOVe instruction, so I am able to control, with an iron fist
, when it does and does not overwrite MinSensorValue.