Skip to Content

Register Login

Industry Online Support

Technical Forum

Navigation

Unreasonable Timer Outputs

Created by: Chemical CJS at: 10/9/2012 5:30 PM (6 Replies)

Rating (0)

Thanks 0

7 Entries

10/9/2012 5:30 PM	Rate (0)
Chemical CJS Posts: 28 Rating: (1)	Hi all, I have attached a test program I was working with since our timers seem to be screwing up. OB1 basically calls an FC that calls three timer-based FCs, which I have simplified the logic by enabling and disabling with marker bits. The idea is to have pulse bits representing one second (IEC timer in PLC Misc. sent to all other FCs). After a few pulses, an "alarm" goes high unless it is reset. Obviously I could use an IEC timer every time instead, but limitations in the design prohibit me from adding more IEC timers. Now, with just one FC timer, the program runs fine; the counter will increment each second until the bit is reset. However, when I add the other two FC timers, I get two problems: 1. None of the counters will even run until the last FC's memory bit is activated, but then all three run simultaneously. (That is, only M0.7 works and causes all FC timers to run in unison.) 2. The watch table gave me strange numbers. I turn on the simulator one time and I get a value of 257. The next time I try I get 15797. The values do not change as I run the timers. I want to say that maybe a variable is being rewritten, but I have three distinct timer variables from the UDT entering each FC, and the rest of the values are temps or unique marker bits. (I am assuming temps don't carry over between nested FCs) Then again, I don't see how the FCs all run or stop depending on the marker bit for only the last FC. Any help would be appreciated. I am probably missing something huge but I can't see it thus far. Thanks in advance. Attachment C:\Users\csaharkh\Desktop\PLC programs\P13 Test Lab CJS 1_with_multi_timers.zip (226 Downloads)
Chemical CJS Posts: 28 Rating: (1)
Suggestion To thank Quote Answer

10/9/2012 6:01 PM	Rate (0)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 9/19/2024 Posts: 15207 Rating: (2417)	Without actually installing an older Portal Version to look at the uploaded project, I can ask a couple of questions that may help us both understand the problem better. 1. Are all your FBs/FCs running every scan you need those timers timing? If not, that is a problem as the timers STOP timing when the FB/FC it is in is not active. These are not PLC hardware timers that we start independently of the logic and monitor in software. 2. Are you able to see the timer block is 'green' or enabled all the time it should be timing?
	science guy
Suggestion To thank Quote Answer

10/9/2012 7:06 PM	Rate (0)
Chemical CJS Posts: 28 Rating: (1)	I have attached a few photos to demonstrate the strtucture of my program. The IEC timer is always running in that every x amount of time, the timer stops and starts again, generating the bit. This is all in a separate, process independent FC. The FC "timer" blocks simply read for the pulse bit from that FC, which is coupled with process information (simplified to a marker bit for testing purposes) and acts as a TON without the need for more timers. In other words, the time for the three FCs is just adding up x many one-second pulses toestablish a y secondmakshift timer, and is reset by a "move 0" instruction. Also, the logic for the counters are exactly the same between the three different FCs except that the starting marker bits are different. Hope that helps, Attachment C:\Users\csaharkh\Desktop\Actual_Timers.zip (279 Downloads)
Chemical CJS Posts: 28 Rating: (1)
Suggestion To thank Quote Answer

10/9/2012 7:53 PM	Rate (0)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 9/19/2024 Posts: 15207 Rating: (2417)	Ok, maybe I understand, maybe I do not. The Q output is on as soon as the timer preset time is reached, and it stays ON until you turn off the timer IN bit. *Maybe you want to add a P_TRIG between the timer Q output and the coils for the 1s & 6s pulse.* Also, I have had mixed results with the timer Q output acting with consistent behavior in the past. To make my timer.Q act consistently, I would add a rung to the network with the timer that parallels the timer (a vertical branch from the Timer.IN input to a horizontal rung). I would then add a NO contact with the timer.Q before acting on the Q bit. This seemed to force consistent behavior to timers, though it could have been using the IEC timer and the non-IEC timer and expecting similar behavior? For the S7-1200 PLCs, there are clock memory bits for 1s pulse. I would hope similar clock pulses are available for your PLC and this would eliminate the problem if you had existing clock pulse bits and all you needed was counters to count to 6 or whatever values you need, then trigger your FCs.
	science guy
Suggestion To thank Quote Answer

10/9/2012 8:30 PM	Rate (0)
Chemical CJS Posts: 28 Rating: (1)	What concerns me is why the counters would not add until only one of the memory bits were active. I understand that the clock memory would be a great way to setup my timers rather than relying on an IEC timer, but I don't quite understand why the FCs simply don't count once I use more than one. To clarify, let's assume I have only one 1stimer, either IEC timer or clock memory bit. Let's say I want to count the risingbits totalling to three different times (i.e. 5s, 7s, 9s) using this 1s bit (5 counts, 7 counts, and 9 counts consequently). And let's say that the counters are only added if a starting bit is set (m0.1, m0.2, m0.3 respectively) When I just use the 5 count FC in my program, the value adds by one per second correctly. When I use the other two counter FCs, the program no longer works. In fact, only activating M0.3 will allow the counters to start, but now all three go together, despite the fact that M0.1 and M0.2 control the other FC counters. I often get numbers like 257 that just stay at that number when monitoring, or it simply adds correctly but gives the value to all three timers (despite the fact that each variable is different). Could I just have a crappy simulator, or is my LAD for the counters flawed? The timer works fine, it's the counter program I am having trouble with.
Chemical CJS Posts: 28 Rating: (1)
Suggestion To thank Quote Answer

10/9/2012 9:08 PM	Rate (0)
0_Einstein Diamond Expert Joined: 7/7/2010 Last visit: 9/19/2024 Posts: 15207 Rating: (2417)	Your counters, you mean the add block? What I do not see is how the total from the output affects the input to the add block. I saw several unrelated items in the rung. I guess it is confusing since I only see a limited amount of the logic. Also, I generally see counters using add blocks use the same output tag on one of the inputs. In this case, it looks to me like tagB <= tagA + 1 rather than tagA <= tagA + 1.
	science guy
Suggestion To thank Quote Answer

10/10/2012 12:54 AM	Rate (0)
Chemical CJS Posts: 28 Rating: (1)	The approach is complicated because a nested FC can't process UDTs as In/Out. So the tag is updated outside of this block, as the output is given to the same variable as the input. You can see it in one of the photos, where I place in UDT values and the variables "cCurrent" and "cCurrentVal" have the same tag on either side of the called FC (where it shows FCs FailtoStart and FailtoStop). Basically, Tag A -> Temp B (add to make Temp C) -> Tag A for each cycle. Yes, the counters are the add block, sorry for my misnomer. To clarify, OB1 sends an In/Out UDT to the first FC, then the FC calls another FC and sends individual variables from the UDT as In only and receives individual UDT variables as Out only. By doing this, the nested FC can "process" an In/Out.
Chemical CJS Posts: 28 Rating: (1)	Last edited by: Chemical CJS at: 10/10/2012 12:57 AM
Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on