Adding a 36hour timer To SLC5/05

Jon82387 · Mar 29, 2013

Hello everyone, i have searched this forum and looked here for advice before but this time i wasn't able to find an exact answer for what i'm trying to do.... I did find some good information but i just don't understand it enough to implement it.

I am trying to add a 36hour timer instruction to an existing program we have at work. The timer would time for 36 hours when a certain motor/VFD is running, after the motor has ran for 36 hours it will start another timer that will energize a solenoid for an oiler to turn on for 1 minute and 5 seconds.

Now at first i thought this wouldn't be very hard.... but after finding out a standard timer would only go to around 9 hours..... i did more research as far as setting the timer to time for 1 hour then have a counter count up 36 times for the equivalent of 36 hours.

Then energize a Time Off Delay timer for the oiler for 1minute 5 seconds.

After adding in something to reset the 1 hour timer and everything my counter will count to 35 then it starts subtracting counts and i can't really figure it out.

After some research i found this thread http://www.plctalk.net/qanda/showthread.php?t=26446&highlight=36+hour+timer

Where TConnolly explains about using a timer setup that never times out.... now i can do the basics as far as programming goes but this explanation is a bit over my head i think. Can anyone elaborate a little on it?

sthompson · Mar 29, 2013

Welcome to the Forum!

You are on the right track. That is how I usually do it. What you want is a Totalizing Timer (RTO). Use the Timer Done Bit in the Rung above the Timer to Reset it (RES).

Then use an XIC (N/O) Contact to Trigger the Counter. Use the Counter Done Bit to start your second Timer for the Oiler. Use the Timer Timing Bit (TT)from this Timer to fire the Solenoid, and the Timer Done Bit to Reset (RES) the Counter.

I find putting the Reset Rung for Timers and Counters on the Rung right before them the most dependable way to do it.

Stu....

Jon82387 · Mar 29, 2013

sthompson said:
Welcome to the Forum!

You are on the right track. That is how I usually do it. What you want is a Totalizing Timer (RTO). Use the Timer Done Bit in the Rung above the Timer to Reset it (RES).

Then use an XIC (N/O) Contact to Trigger the Counter. Use the Counter Done Bit to start your second Timer for the Oiler. Use the Timer Timing Bit (TT)from this Timer to fire the Solenoid, and the Timer Done Bit to Reset (RES) the Counter.

I find putting the Reset Rung for Timers and Counters on the Rung right before them the most dependable way to do it.

Stu....

Hmmm well after what you posted i tried it and ran it in a simulator and it worked fine.... not sure what i must have screwed up at work lol.

Everything works great but the one problem i have realized is that say the sorter/line is stopped when the oiler timer has come on it will continue oiling the chain while the sorter has physically stopped.

Now i figured a way to stop the oiler from oiling if the motor stops but..... i'm not quite sure of a way to continue the oiling process after it is started again. If there was some sort of retentive off delay timer it would work perfect but i dont think there is?

What alternative ways to do this is there?? I'll try to attach a S/S of the program i came up with any input appreciated!!!

sthompson · Mar 29, 2013

In that case, I would use a Retentive Timer (RTO) for the Oiler Solenoid as well, and condition it with the Motor Running Bit in front of the Timer. Don't forget to Reset the Timer.

Stu....

Jon82387 · Mar 29, 2013

sthompson said:
In that case, I would use a Retentive Timer (RTO) for the Oiler Solenoid as well, and condition it with the Motor Running Bit in front of the Timer. Don't forget to Reset the Timer.

Stu....

Well at first you had me confused with that.... then i thought about it and here is what i came up with

I added another timer in so that when the sorter restarts since its on a VFD and takes a second to ramp up the oiler won't dump all over the chain moving at a slow pace.

Whatcha think?

Bit_Bucket_07 · Mar 29, 2013

Jon82387 said:
Whatcha think?

I'd say that you have figured out one of the 1000 ways to skin this cat -- and you only need one.

My only recommendation is that you implement documentation so as not to confuse yourself, or other programmers who may come behind you.

tomalbright · Mar 29, 2013

I'm curious how the accuracy works out. I've had mixed results using internal timers to... actually time something. External clocks are a better reference, but I know we can't always do that.

Jon82387 · Mar 29, 2013

Bit_Bucket_07 said:
I'd say that you have figured out one of the 1000 ways to skin this cat -- and you only need one.

My only recommendation is that you implement documentation so as not to confuse yourself, or other programmers who may come behind you.

Hmm like what sort of documentation? Rung comments? Or just plain old writing on paper type stuff? Elaborate a bit if you don't mind!

Jon82387 · Mar 29, 2013

tomalbright said:
I'm curious how the accuracy works out. I've had mixed results using internal timers to... actually time something. External clocks are a better reference, but I know we can't always do that.

Well from what reading i have done like you said this may not be super accurate..... but to be honest the previous contractor that did the install totally forgot to REINSTALL the oiler..... so for the past 6-8 months or so it wasn't working at all......

I figure as long as it comes on within reason then we should be ok....

The original figure was 36 hours..... but after doing some math with the information i recieved it looks like it may be 2.5 hours really. So if it comes on a few times a day i think we will be fine!

Actually here is the info i have.... the oiler is supposed to come on every 65,000 Slats.
Each slat is 5" wide
It takes 1 minute 5 seconds for the sorter to rotate completely
The sorter is running at 180 Feet/Min

180/60= 3Feet per sec

65seconds * 3FPS= 195 Feet per revolution

12/5= 2.4 Slats per Foot

195*2.4=468 Slats per revolution

65,000/468= 138.8 or 139.... revolutions total

139*65 seconds= 9035seconds Runtime for 65,000 Slats

9035seconds/60seconds=150.58 151minutes

151minutes/60Minutes=2.5Hours for 65,000 Shoes to be rotated/used

TConnolly · Mar 29, 2013

When you use a timer DN bit you will loose two plus scans of time evertime your timer times out. Remember that a timer is a computer instruction and not a device. Since its a computer instruction it only updates when it is executed. The time will expire some time mid scan but the timer won't "know" it until it is next executed. The following scan it resets. And on the third scan it restarts. This often does not matter, and if you are timing 36 1 hour intervals with then your time loss is around 1 second depending on scan time. If its not that critical then don't worry about it and go for the easiest to program/understand method. However, if you were say counting minute intervals then after a day the timing loss gets to be fairly large. When that happens, instead of letting the timer time out you do a comparison of the timers ACC and if it is greater than your count interval you increment the count and subtract the interval from the timer's ACC. This avoids the loss of time with the DN bit, reset, and restart of the timer and your only time loss is on the final scan.

When a timer is operating it stores a time reference from the system in the low byte of timer word T4:X.0. The next scan it gets a new time reference from the system and subtracts the stored time reference from it. It then updates the ACC by the difference, and then stores the new time base in the low byte of word 0. Lather, rinse, repeat. By subtracting from the ACC instead of resetting the timer you preserve the last aquired time reference in word 0 and so you don't loose the scan time. At the scan when you reach your count all the regular timer precision rules apply, namely you could be off by one scan time, but you won't have totalized all of the additional error you would get with the other method.

Bit_Bucket_07 · Mar 29, 2013

Jon82387 said:
Hmm like what sort of documentation? Rung comments? Or just plain old writing on paper type stuff? Elaborate a bit if you don't mind!

In my opinion, rung comments aren't usually needed for each rung. I do prefer to at least provide a rung comment as a header for each group of rungs that form a specific logical task. Even in cases where symbol names are assigned for data elements, I like to see a more verbose descriptor added.

That said, I understand the urge to simply whip out the logic with machine addresses when developing for a test, but that's a habit that I've forced myself to abandon over the years, because I've found that the time invested in documentation pays off in avoidance of confusing myself while attempting to troubleshoot my own programming.

My goal in program documentation is to have any programmers who might one day come behind me and modify a program that I have written say; "Thanks, buddy -- whomever you were!"

Jon82387 · Mar 29, 2013

TConnolly said:
When you use a timer DN bit you will loose two plus scans of time evertime your timer times out. Remember that a timer is a computer instruction and not a device. Since its a computer instruction it only updates when it is executed. The time will expire some time mid scan but the timer won't "know" it until it is next executed. The following scan it resets. And on the third scan it restarts. This often does not matter, and if you are timing 36 1 hour intervals with then your time loss is around 1 second depending on scan time. If its not that critical then don't worry about it and go for the easiest to program/understand method. However, if you were say counting minute intervals then after a day the timing loss gets to be fairly large. When that happens, instead of letting the timer time out you do a comparison of the timers ACC and if it is greater than your count interval you increment the count and subtract the interval from the timer's ACC. This avoids the loss of time with the DN bit, reset, and restart of the timer and your only time loss is on the final scan.

When a timer is operating it stores a time reference from the system in the low byte of timer word T4:X.0. The next scan it gets a new time reference from the system and subtracts the stored time reference from it. It then updates the ACC by the difference, and then stores the new time base in the low byte of word 0. Lather, rinse, repeat. By subtracting from the ACC instead of resetting the timer you preserve the last aquired time reference in word 0 and so you don't loose the scan time. At the scan when you reach your count all the regular timer precision rules apply, namely you could be off by one scan time, but you won't have totalized all of the additional error you would get with the other method.

I was kind of hoping you would chime in.... I read some of your other threads about the way your talking about setting up the timer and downloaded the PDF you have made about setting it up also.

Now.... i have never really gotten into programming that deep but i somewhat understand the things you are doing in the PDF file you made.

I see you are taking a single timer and using the accumulated value and storing it in a Floating point? Now i really don't know what a "Floating Point" is.... i'm assuming its just a place to store a number?

I see you use 3 different floating points F8:1,2 and 3.

Your storing the timers accumulated value in 1 point then subtracting it from the timer and adding the accumulated value to an overall???? Now i think i understand what your saying about the whole .01 of an hour.

The thing i don't really get is.... which value is the total accumulated? F8:3?

And how would you set it for how many hours you want it to count? like.... value F8:3=8 for an 8 hour timer? then how do you implement that into starting a bit or stopping a bit? And resetting everything?

I know this is probably a terrible explanation but i'm just kind of lost on how it all works. You may need to "dumb it down" some more for me to understand it.... if you don't want to waste your time thats fine too lol.

Thanks
Jon

Bit_Bucket_07 · Mar 29, 2013

One method for creating more accurate timing functions in a PLC is to simply add the previous sweep time to a register with each program sweep after the virtual timer is enabled and then use a GE compare to a virtual "Preset" register to trigger a virtual "Done Bit".

For most applications though, the accuracy of a plain-jane TMR is adequate.

TConnolly · Mar 29, 2013

I had to go back and look at that one. That was a long time ago. The customer wanted to time in hours and hundredths of an hour, for example 1 hour and 30 minutes would be 1.5 hours. So the example I gave showed how to do a timer using a floating point number (F file) instead of an integer. A floating point number is a number with a decimal point in it. 3.1316 is a floating point number. In the example, every 36 seconds .01 is added to the totalized value. The example also computed the fraction of the hundredth of an hour that was between 0 and 36 seconds - I don't remember why I showed that unless at the time I was thinking the OP wanted a continuously updating time. F8:2 is the accumulated 100'th of an hour. F8 3 is the fraction of a hundredth of an hour. F8:1 is the accumulated 100ths of an hour plus the fraction of a hundredth. Its definitely not necessary in your application.

If you are counting even hour increments then don't bother with that, it just adds complexity.

To know when your time period is up you are going to have to do a comparison. Look at the very last branch of rung 0 to see the comparison in the example. If you use a counter to count whole units instead of a floating point number you can use the counter DN bit.

Seriously, if you don't have to nail 36 hours exactly, and it doesn't matter if you are off by half a second to one second, then just use a self resetting timer and a counter. This kind of code gymnastics is there for the rare cases when you need high precision, but most of the time you don't need it and at 3:00 AM when Bubba is trying to figure it out the simplest approach can save you a groggy phone call, a coffee fueled drive to the site, and the morning headache that will surely follow.

Lancie1 · Mar 29, 2013

For most applications though, the accuracy of a plain-jane TMR is adequate.

Seriously, if you don't have to nail 36 hours exactly, and it doesn't matter if you are off by half a second to one second, then just use a self resetting timer and a counter.

I second those. Why confuse the new guys with intricate details that they are not ready to learn?

Adding a 36hour timer To SLC5/05

Jon82387

Member

sthompson

Lifetime Supporting Member + Moderator

Jon82387

Member

sthompson

Lifetime Supporting Member + Moderator

Jon82387

Member

Bit_Bucket_07

Member

tomalbright

Member

Jon82387

Member

Jon82387

Member

TConnolly

Lifetime Supporting Member

Bit_Bucket_07

Member

Jon82387

Member

Bit_Bucket_07

Member

TConnolly

Lifetime Supporting Member

Lancie1

Lifetime Supporting Member

Similar Topics