Sign in to follow this  
Followers 0
SSfritz

Logix Counter

18 posts in this topic

We are trying to simulate an hour meter based on the amount of time a pump is running. When the pump contact is enrgized we want to tabulate the amount of hours it ran in a 24 hour period. We tried to use a retentative timer but does not keep the right time because this method uses the running clock. And it also took us about five rungs to make that work. Is there a simpler way? And can we accomplish this using the S:41 bit from the clock? It seems logical that this could be done, but being new to RSLogix I am not sure what module fits this application best. Any help would be greatly appreciated........ Please email me if you like..... Sorry about that....We are using Logix 500 and the PLC is a 5/05.... Edited by SSfritz

Share this post


Link to post
Share on other sites
Which RSLogix are you using? Edited by Bob O

Share this post


Link to post
Share on other sites
Sorry about that.... We are using RSlogix 500 for this application....

Share this post


Link to post
Share on other sites
Hi Duane. Are you wanting to check midnight to midnight or a variable 24 hour period... Like from now to 24 hours ago or from 8:00 am til 8:00 am? Does the SLC run all of the time? Do you also want to accumulate pump non-running time even when the SLC is not running? That's a lot harder. By the way what kind of pump is it?

Share this post


Link to post
Share on other sites
I actually want two counters. 1)How many hours the pump has run since midnight. 2) A total hours ran that would keep track of all hours for the month or year for that matter. The pumps are circulating water pumps.

Share this post


Link to post
Share on other sites
I assume the SLC is controlling the water pump. Is this right? And if the slc runs continuously it can keep track of when the time period is over. There is of course a problem when the SLC is not running... If it were not running when midnight rolls by then is started 3 days later it needs to verify if it is still accumulating run hours for the same day or month or year. You can see that this is not getting simpler than 5 rungs. That loss of SLC power can mess with even a retentive time solution if you don't include the month/day/year data also.

Share this post


Link to post
Share on other sites
One of the problems with using counters and shorter timers to accurately time longer time periods is that over very long times the scan time of the PLC, (the time between when the time period actually expires and when the PLC gets around to scanning the timer instruction again) adds into the total time and begins to produce significant timing errors. Using the PLC system clock in unnecessarily complicated and has some of the problems already addressed in this thread. I suggest you use a floating point time totalizer and a method that does not rely on the timer DN bit. This demonstrates how to mitigate the problem of totalizing scan time into very long timers and how to use a floating point address to totalize hours in 1/100ths of an hour. One of the things you will notice is that the timer is not reset and that its preset is set to the max positive value for an integer. This is because we will never let this timer get anywhere near its preset and we will also never reset this timer. One of the critical pieces of information stored in one part of the timer element that you cannot easily get at is a time base reference value. As long as you preserve this time base reference value you can accurately time without totalizing scan times into the final result. So every 1/100th of an hour, or every 36 seconds we will subtract 36 seconds from the time accumulator and add 1/100th of an hour to the F8:0. F8:0 is where the actual run time of your motor is stored. This will keep the motor total time for much much longer than your PLC and motor will live. If you go to the downloads section you can see a similar application where a precision timer is created. http://forums.mrplc.com/index.php?autocom=downloads&showfile=576 But for motor timers I've used the above logic and found it times very well for many years. There are a number of ways to derive the hours run for just today (since midnight) from the same totalizer value without setting up an additonal timer/totalizer. Here is one such way. If the system might ever be turned off at midnight then instead of looking for 0:00:00, look for a change in the current day instead. Store the current day (S:39) at some integer address, then take action as soon as S:39 doesn't equal the stored number. NEQ S:39 N7:0 BST MOV S:39 N7:0 NXB MOV F8:0 F8:1 BND Edited by Alaric

Share this post


Link to post
Share on other sites
One other thing... Are you wanting to keep that 24hour period data for longer than just the last 24 hour period? If you want to keep 24 hour period data for a year it would take at least two files to store it in. Are these water pumps for cooling water for your centrifugal air compressors? If it is maybe we could integrate it into one of your air compressor controls for you. :)

Share this post


Link to post
Share on other sites
Here is what we have built. Please see attachment. Again it works O.K except it loses time over a 24 hour period. Does the RTO block differ between a 5/05 and a 5/04? I do think this one is a 5/04? The RTo does not give me the choice to go to 1.0 in the time space?

Share this post


Link to post
Share on other sites
There is an error in vour compute at the top. It should be s:40 + (s:41/60)... Not "/ 100". That could be your error, right there.

Share this post


Link to post
Share on other sites
Again all we are trying to do is create an hour meter. One for hours ran today and one that keeps an overall total. This is triggered by the pumps run contact. Now these pumps can be turned on or off during the day as required by the system.

Share this post


Link to post
Share on other sites
You could just use the current time @ stop minus the current time at last start to get run hours. Then accumulate these time periods in a "24 hour period word". You need to watch the day though for a reset. If you want to keep the data you need to move it to a different address. We commonly would move the data into the last address of a data file and keep shifting the data back as new data is accumulated. (You have to shift the data first then add new data.) We use the copy command and copy N40:1 to N40:0 with a length of 100 then put the new data (or accumulate data) in N40:100. That way you could have the 100 most recent days of the 24 hour data.

Share this post


Link to post
Share on other sites
Our operators will take the midnight reading for their book work. The today meter can be monitored daily. then I subtract the two meters and display the actual hours ran today on a RSView screen for general knowledge. But the midnight reading is the most important reading for record purposes.....

Share this post


Link to post
Share on other sites
Don't try to use that copy command the other direction 'cause it won't work. The copy command is more like a looped move and if you go the other way it will fill your file with the most recent data.

Share this post


Link to post
Share on other sites
The first thing to understand about the TON instruction is that it is not a timer. It is an instruction to the processor that emulates a timer. When you start a timer instruction the processor records the curren value of the system reference time in the least signficant byte of the timer element word 0. Now the processor moves on and does other things. Eventually it comes back to take a look at the timer instruction. It compares the current value of the system time reference time to the value it recored earlier. If this value is greater than the time base it adds the difference to the timer accumulator and records a new time reference value. It does this until the accumulator is greater than the preset, then it stops doing it and sets the timer DN bit. The actual time that has elapsed since this happened is NOT the value recorded as your timer preset. It is the value of the preset + the amount of time that elapsed before the processor got around to checking it again. If you have a 50mSec scan time and a one second timer, then that means that up to 1.050 seconds could have actually elapsed. If you are using a one second timer to trigger a counter then after a full minute you would totalize a value in the counter somewhere between 57 counts and less than or equal to 59 counts, but not 60 counts - you are already off by at least 1 and maybe by as much as 3 counts! Over the course of a day thats adds up to something noticeable. By using a longer timer then you have fewer chances to accumulate error into your total, but you are still going to get this error, and over long periods of time it becomes more and more obvious. The key to understanding the solution is to realize that you need to keep that time base reference in the LSB of word 0 current and up to date, and the instruction will do that for you as long as you never let the time time out. Everytime the DN bit gets set and the timer gets reset that reference word is wiped out and you start over - so you just lost track of however much time has occured since the preset time actually elapsed and when the processor next scanned the instruction. But if the DN bit is never allowed to set, and the ACC is never allowed to reach its preset, then the timer will happily keep that time base reference value current. And its not hard, you actually don't need to do anything except keep the ACC value < the PRE and then keep track of how much you adjusted the ACC by. In my example above, every 1/100th of an hour we subtract 36 seconds (.01 hours) from the ACC and add .01 hours to a floating point number. The timer is never allowed to time out, so the time reference word is always current. This way our maximum possible error is the time of a single scan, not the totalized time error from millions of scans. Edited by Alaric

Share this post


Link to post
Share on other sites
Excellent explanation of the workings of TON Alaric wish more people understood this.

Share this post


Link to post
Share on other sites
Thank You Alaric for the explanation. And thank you for your help. You to FinFin.........

Share this post


Link to post
Share on other sites
Are you trying to make the time base change by editing online? Both platforms support the .01 and 1 second time base, but if you are trying to change the time base with onine editing while the timer is in use I suspect you are going to have problems. If you cannot take the equipment offline then keep the current time base and add .05 hours instead of .1 hour (but fix it so you aren't resetting the timer as I explained above). (Floating point time totalilzers counting 1/100ths of hours are not without their own set of problems that are related to the way floats are stored in a computer, but that won't happen until long after your great-grandchildren have retired.)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0