Ton /tof

[Don Diego]

If the done bit precede a timer either on the same rung or on the previous before the timer will it work. I am more accustomed to putting the done bit after the timer but I've seen a lot ladder logic programs with this reversed and it doesn't work when try it out on my simulator.
In real world applications would it work?

Curious
Wise Samlafo

 

[drbitboy]

what brand of plc/emulator are you working with?


Can you show an example of code that works and code that does not? I am not quite sure I understand what you mean.


The done bit is an output of a timer, and does not usually feed the timer as an input unless the timer is set up to be a repeating timer.

 

[Steve Bailey]

It's a quick way of generating a one-shot pulse at a timed rate if you're not overly concerned with accuracy.

 

[Don Diego]

what brand of plc/emulator are you working with?


Can you show an example of code that works and code that does not? I am not quite sure I understand what you mean.


The done bit is an output of a timer, an does not usually feed the timer as an input unless the timer is set up to be a repeating timer.

Drbitboy, I am finding difficult attaching the ladder program because of poor internet , I am at work it is 12midnight. but here's the link :
https://www.sanfoundry.com/plc-program-drive-motors-simultaneously-interlocking/
I use Do Designer /Simulator V. 2.6

 

[Don Diego]

It's a quick way of generating a one-shot pulse at a timed rate if you're not overly concerned with accuracy.

Hi Steve, So it should work ? Take a look this program,it doesn't work on my do More Simulator. When the done bit is placed after the timer, it works perfectly.

https://www.sanfoundry.com/plc-program-drive-motors-simultaneously-interlocking/

 

[AlfredoQuintero]

Don Diego, Hi. I tried to have a look to the information you post on that link above, but this site is asking me to install add-ins to my browser, and since I do not want to do that, I am unable to have a look at your data. I do not speak for all the other members of this forum, but I think it is a safe bet that most of them care about security and will not be too happy to install add blockers or reveal any such kind of information to whatever this "sanfoundry" is asking. Thus, I advice you to try to post the additional information in the forum, so you may increase the likelihood that someone will look at it and give you useful advice.

 

[mikeexplorer]

I was able to look at the website without a problem Here is a snapshot of the code he is discussing.


Mike

 

[Don Diego]

I was able to look at the website without a problem Here is a snapshot of the code he is discussing.


Mike

Hi Mikeeplorer, thanks for retrieving the code.
Anybody ever used TON timer in this manner in real life application ?

 

[drbitboy]

Hi Steve, So it should work ? Take a look this program,it doesn't work on my do More Simulator. When the done bit is placed after the timer, it works perfectly.

https://www.sanfoundry.com/plc-program-drive-motors-simultaneously-interlocking/

Which rung are you moving? Is it rung 003 that does not work as in the image, but works if you switch rungs 003 and 004?


If yes, what happens if you switch rungs 003 and 002?

 

[drbitboy]

I don't know exactly why it works one way and not the other, but I can offer a few observations:

• Safety: Motor1 can run when the system is off ([Coil 0:2/2] is 0)
  • When [M1 Start I:1/1] is 1, rung 003 will pass a true rung state to [Motor1 O:2/1] whenever [T4:1.DN] is 0.
• In one sense, there is no "before" or "after" in a scan: because the scan is repeated ad infinitum, the first rung can be said to execute immediately after the last run.
• It will matter very much how the PLC handles timer states: buffered in between scans; or asynchronous.
  • For example, I see three tests (two XICs, one XIO) of T4:0/DN, on rungs 001, 002, and 003. If the value of T4:0/DN toggled between those rungs, it may change the program behavior from what would be expected by a simple reading of the code.
  • The motor-run logic (currently rungs 001 and 003) is interleaved with the "flasher" timer logic (rungs 002 and 004). Because of the synergy of the motor bits, [Motor0 O:2/0] and [Motor1 O:2/1], with the timer DoNe bits, I would think that separating those two sections of logic would make for more stable behavior, especially if the timer states could change in the middle.
  • So if the DoMore simulator works differently than the same program in an Allen-Bradly SLC or MicroLogix, this could be the reason for different behavior.
• If I was programming the desired model, I would probably make the output to [Motor1 O:2/1] dependent only on [Coil O:2/2] and [Motor0 O:2/0], and put the rest of the logic with the timers, and the MotorN buttons, into choosing whether [Motor0 O:2/0] is on, so there would be potentially less interaction between rungs.

 

[drbitboy]

Also, what behavior do you see when "it doesn't work?"

 

[drbitboy]

Here is another approach. It works fine on a MicroLogix 1100; I think it will work regardless of the order of rungs; I would be interested to hear if that is indeed the case in the DoMore emulator.

Code golf: one less timer than Post #7; two fewer instructions*.






* Assuming [Post #7] needs at least one more XIC to ensure [M1 Start I:1/1] cannot start Motor1 when the system is off; there is also a need for more instructions to handle the case where both motor start buttons are pressed at the same time.

 

[drbitboy]

Cleaned up a bit, added comments.

 

[Don Diego]

Here is another approach. It works fine on a MicroLogix 1100; I think it will work regardless of the order of rungs; I would be interested to hear if that is indeed the case in the DoMore emulator.

Code golf: one less timer than Post #7; two fewer instructions*.



View attachment 56489


* Assuming [Post #7] needs at least one more XIC to ensure [M1 Start I:1/1] cannot start Motor1 when the system is off; there is also a need for more instructions to handle the case where both motor start buttons are pressed at the same time.

Drbitboy,ave you tried the Circuit posted by mikeexplorer in Mixrologix 1100? If you haven't please and share the feedback on the platform.
How much is Mixrologix 1100 ?

 

[Don Diego]

I don't know exactly why it works one way and not the other, but I can offer a few observations:

• Safety: Motor1 can run when the system is off ([Coil 0:2/2] is 0)
  • When [M1 Start I:1/1] is 1, rung 003 will pass a true rung state to [Motor1 O:2/1] whenever [T4:1.DN] is 0.
• In one sense, there is no "before" or "after" in a scan: because the scan is repeated ad infinitum, the first rung can be said to execute immediately after the last run.
• It will matter very much how the PLC handles timer states: buffered in between scans; or asynchronous.
  • For example, I see three tests (two XICs, one XIO) of T4:0/DN, on rungs 001, 002, and 003. If the value of T4:0/DN toggled between those rungs, it may change the program behavior from what would be expected by a simple reading of the code.
  • The motor-run logic (currently rungs 001 and 003) is interleaved with the "flasher" timer logic (rungs 002 and 004). Because of the synergy of the motor bits, [Motor0 O:2/0] and [Motor1 O:2/1], with the timer DoNe bits, I would think that separating those two sections of logic would make for more stable behavior, especially if the timer states could change in the middle.
  • So if the DoMore simulator works differently than the same program in an Allen-Bradly SLC or MicroLogix, this could be the reason for different behavior.
• If I was programming the desired model, I would probably make the output to [Motor1 O:2/1] dependent only on [Coil O:2/2] and [Motor0 O:2/0], and put the rest of the logic with the timers, and the MotorN buttons, into choosing whether [Motor0 O:2/0] is on, so there would be potentially less interaction between rungs.

Drbitboy, the problem is that the first rung #000works perfectly but, Motor 0 on rung #001 and Motor 1 on rung 003 is not energized.