Timer only executes once
- Thread starter Tomz
- Start date
joseph_e2
Member
I'm a little rusty in the Siemens world, but....
Is the -(p)- instruction a rising edge?
Is S_ODT an on delay timer or an off delay timer? And is TV its setpoint?
If (p) is a pulse that's on for 1 scan and S_ODT is an on-delay timer, then it will never finish unless your scan time is greater than 10s. Because #varpom will be on for one PLC scan, which will start T71. Before T71 times out, the PLC scan will return to Network 2, see that #varpom is "on" and then change its RLO to 0, which will stop the timer's timing. If S_ODT is an off-delay timer, then I would think your code would work.
Is the -(p)- instruction a rising edge?
Is S_ODT an on delay timer or an off delay timer? And is TV its setpoint?
If (p) is a pulse that's on for 1 scan and S_ODT is an on-delay timer, then it will never finish unless your scan time is greater than 10s. Because #varpom will be on for one PLC scan, which will start T71. Before T71 times out, the PLC scan will return to Network 2, see that #varpom is "on" and then change its RLO to 0, which will stop the timer's timing. If S_ODT is an off-delay timer, then I would think your code would work.
drbitboy
Lifetime Supporting Member
Short answer: it executes only once because that is what the program logic tells it to do.
Long answer:
I suspect the -(p)- instruction is a one-shot, and S_ODT is an On-Delay Timer.
If that is the case, it's output rung can be True for only the one scan cycle when #pombit transistions from a value of 0 to a value of 1.
On the scan cycle when the #pombit value transitions from 0 to 1, that -(p)- output rung becomes True, which feeds the S rung of the timer, and starts the timer.
However, on all following scan cycles, the value of #pombit is still 1, but the output of the -(p)- instruction will be False because the one-shot already happened and it cannot be True again until the #pombit values transit back to 0 and then to 1 again. Since the output of the -(p)- instruction is False, the input pin S will see that false and reset the timer. Since the timer is reset, it's output Q pin can never become True, so the #pombit value can never become 0 again, so the timer stays reset.
As @joseph_e2 says, changing to an Off-Delay Timer should work. Another option would be to remove the -(p)- one-shot instruction, so a value of 1 in #pombit would keep the S_ODT timer timing until timer expiry, which would then reset the value of #pombit to 0, which would in turn reset the timer and allow the process to start again.
A better solution might be to do this without Set and Reset instructions, and use the canonical Start/Stop Circuit pattern (see here) to implement this logic. In my experience, although there is nothing wrong with Set and Reset instructions, logic that is implemented with Set and Reset is usually harder to read and debug.
Long answer:
I suspect the -(p)- instruction is a one-shot, and S_ODT is an On-Delay Timer.
If that is the case, it's output rung can be True for only the one scan cycle when #pombit transistions from a value of 0 to a value of 1.
On the scan cycle when the #pombit value transitions from 0 to 1, that -(p)- output rung becomes True, which feeds the S rung of the timer, and starts the timer.
However, on all following scan cycles, the value of #pombit is still 1, but the output of the -(p)- instruction will be False because the one-shot already happened and it cannot be True again until the #pombit values transit back to 0 and then to 1 again. Since the output of the -(p)- instruction is False, the input pin S will see that false and reset the timer. Since the timer is reset, it's output Q pin can never become True, so the #pombit value can never become 0 again, so the timer stays reset.
As @joseph_e2 says, changing to an Off-Delay Timer should work. Another option would be to remove the -(p)- one-shot instruction, so a value of 1 in #pombit would keep the S_ODT timer timing until timer expiry, which would then reset the value of #pombit to 0, which would in turn reset the timer and allow the process to start again.
A better solution might be to do this without Set and Reset instructions, and use the canonical Start/Stop Circuit pattern (see here) to implement this logic. In my experience, although there is nothing wrong with Set and Reset instructions, logic that is implemented with Set and Reset is usually harder to read and debug.
drbitboy
Lifetime Supporting Member
Is this a homework assignment or real work?
For @joseph_e2's solution, simply remove the -(p)- #varpom instruction and then report back here that it now works.
An image of the Start/Stop Circuit pattern is in the link provided in my previous post. It will take a little thinking to know what elements of your system to use for each of the Start, Stop, and Seal-In/Run elements of the Start/Stop Circuit; I suggest watching the video series mentioned next to help with that.
Do you know what the PLC scan cycle is? If not, watch this video series, which takes less than two hours total but will explain 80% of what you need to know to program PLCs.
It's education for work. only started working with no experience. I managed to make it work tho. Thank you for replies!
Similar Topics
I have some logic that I have written within a 5380 series controller that tracks the time an event is started, while the event is running an RTO...
Hi all,
I have a simple question that I have overcomplicated and gotten stuck on. I have a variable, we can call it "light" that I need to stay...
Question to anyone with ideas about my thoughts on upgrading a very vintage timer, which is being used to switch between 2 5hp domestic water...
Good morning guys, I'm searching for a Timer relay which accomplishes the "flasher" condition in the photo attached, however, I need the ability...
Hello all,
I am trying to improve my skills, so I decided instead of moving a value into every single .PRE of an array of timers, I thought I...