Hour meter

[StefanA]

I made a hour meter by letting a special bit second clock increment a variable which increments other variables so that get minutes and hours. When running the function against a referens clock (the pc clock) I have noticed a lagging effect after an hour or so. When running for 10 hour the difference is 30 seconds or more. Have I design the function wrong or is the special bit second clock not that accurate.

[garysdickinson]

StephanA,

I observed the same behavior that you are seeing using a FMD1616.  I found that the Clk:1.0s signal lags behind the RTC in the PLC and gets behind about 4 seconds an hour on my hardware.

The test code that uses only 2 custom functions, SetHourMeter and DisplayTime.

SetHourMeter, forces the hour meter counters to the time 00:00:00 and the RTC time to 00:00:00.
' SetHourMeter Initialze counters and RCT to 00:00:00
'
'  This is done becuase the initial value of a counter is "-1" and
'  by forcing the intial state to "0" I do not need to special case the "-1"
'  value.
'
CtrPV[Seconds] = 0
CtrPV[Minutes] = 0
CtrPV[Hours] = 0

' Set RTC to 00:00:00
'
TIME[1] = 0
TIME[2] = 0
TIME[3] = 0
[/color]

The DisplayTime custom function displays the current Hour Meter time and the RTC time on the LCD display in the format:

    HH:MM:SS Hour Meter
    HH:MM:SS RTC


' Display hour display on LCD.
'
' First Line is the hour meter display using the Clk:1.0s
' Second Line of the display is the elapsed time using the RTC hardware
'
SetLCD 1,1, STR$(CtrPV[Hours],2)+":"+STR$(CtrPV[Minutes],2)+":"+STR$(CtrPV[Seconds],2)+" Hour Meter"
SetLCD 2,1, STR$(TIME[1],2)+":"+STR$(TIME[2],2)+":"+STR$(TIME[3],2)+" RTC"
[/color]

The ladder logic follows:

[garysdickinson]

StephanA

To answer your question, your code is probably OK.  

In my case the CLK:1.0Sec signal  is more like 1.00094 seconds (5 second error in 90 minutes). This is an error of about 0.1%.

If your application cannot tolerate a 0.1% error then you may want to explore using a more accurate time standard for measurement.  You may want look at using the PLC's RTC mechanism to measure elapsed time.

Best regards,

Gary D.

[StefanA]

Thanks for the explanation Gary. My application is not that time critical. I could just not understand why my meter was lagging.

[support]

Thanks Gary for carrying out the test.

The clock pulses (Clk:.01s to Clk:1min) used by the PLC ladder program is derived from a 1ms clock tick interrupt to the operating system. From time to time the operating system need to disable the interrupt in order to handle certain critical task or to protect the critical memory and this can result in some missing clock ticks. As such the clock pulses are not meant to be used as accurate time base for real time clock.

The RTC on the other hand are handled directly in the CPU hardware and therefore are not subject to missing clock ticks.  As such more accurate measurement of elapsed time can be derived from the RTC hardware.

If the PLC is connected to the Internet then even more accurate RTC can be gotten from internet time server.

[garysdickinson]

Hello All,

I modified my test code to use the RTC to generate a 1Hz signal.  This approach results in a signal that 100% is as accurate as the RTC (no missing transitions).

This is the custom function that I call 5 times each second (Clk:0.2s):

' Gen1SecClk - custom function to generate 1Hz clock using the RTC mechanism
'
' The special bit: Clk:1.0s has an observed error of about 0.1%. It is believed that the missing
'   transistions on the Clk:1.0s is due to internal PLC firmware that disables interrupts during some
'   critical code section and as a result the Clk:1.0s losses time.
'
' Please note that "CurrentTime" and "SavedTime" are 16-bit integer values that reside in DM[].  The
' #Define mechanism is used to create this varialbes.  This sort of makes these variables "local" to
' this custom function.  The use of the #Define allows the names of these variables to make logial
' sense.
'
CurrentTime = TIME[3]   ' get current time in seconds: 0..59
if CurrentTime <> SavedTime
   SavedTime = CurrentTime
   SetIO RTC1SecClk
else
   ClrIO RTC1SecClk
endif
[/color]

The reason that I used the Clk:0.2s contact was that I needed to poll the Seconds registers of the RTC at a minimum of 2 times each second (Nyquist rate).  Clk:0.5s looses a transition about once every 15 minutes.  Clk:0.2s suffers from the same issues as Clk:0.5s, but even when a transition is lost, there are still 2 transitions per second on this clock.

Gary D.

[MarkWater]

I also used this hour meter and its working great. How would you store the values so that when you power down the PLC the hour meter will be at the same point where it was before?

[garysdickinson]

The short answer is that you can periodically store the Present Values of the COUNTERS into non-volatile memory.
 
When the PLC is powered up, you would update the COUNTERS with the stored values on the first scan of the ladder logic.  This would make your hour meter non-volatile.

The longer answer gets a bit complicated so I'll ask you a couple questions:

  Which PLC are you working with?

  Have you installed one of the optional FRAM-RTC modules?

If I have a free minute I'll try and give you a bit better answer.  

In the meantime look in your PLC manual for the sections that talk about "Non-Volatile Data Storage", the TBASIC SAVE_EEP and LOAD_EPP statements and the SETSYSTEM 252,0 statement.  

There is also a DIP switch (SW1=1) on most PLCs that automatically make many things non-volatile.  Look at the "DIP SWITCHES" section in the manual.  The documentation is not 100% clear on the affect of this DIP switch in regards to OUTPUT, RELAY, TIMER and COUNTER values.  I would not suggest this approach without a lot of careful testing.

Gary D.

[MarkWater]

Thanks Gary, I was able to figure it out, using the non-volatile memory.

[MarkWater]

I have constructed an hour meter like the one pictured above, is it possible to place the "hour" portion into a float variable so i have no limit on run hours, and also it can be displayed as x.x on my hmi?

[garysdickinson]

The hour meter code is done in ladder logic. A ladder logic COUNTER can have the following range of integer values -1,0,1,2,3 ... 9999.  The "-1" is sort of special and belongs in another discussion.

If you want to count to values greater than 9999 you could cascade another counter and this would allow you to count to 99,999,999 hours.  This is about 11,000 years.  Neither of us will live to see the counter overflow.

You could replace the hour COUNTER with a custom function that can uses a 32 bit integer to accumulate the hours.  You could then count to 2,147,483,647 hours.  This would be about 245,000 years.

If you are using one of the new and improved Fx PLCs that support floating point, you would probably still want to use an integer variable for counting.  The floating point math has some issues with precision.  A 32-bit float will start giving you errors in about 957 years.  If you stick with 32-bit integers you will get almost 244,000 extra years of counting.

Let me know when the counter rolls over.

Gary D.