News:

  • November 06, 2026, 12:35:59 PM

Login with username, password and session length

Author Topic: Timer -vs- Scan Time Accuracy  (Read 146 times)

SOWEGATS

  • Full Member
  • ***
  • Posts: 24
Timer -vs- Scan Time Accuracy
« on: November 04, 2026, 05:58:29 PM »
I'm working on a program where I want to start an accumulating time - we'll call it T1 - and I want to record its value(s) when certain things happen, E.G. various switches/inputs are activated.

I want to be able to compare the amount of time and/or deltaT for these "events", so stopping the timer is not really desirable and using multiple timers would be more difficult and/or confusing.  Seems like a simple solution would be to simply "Copy" T1.acc into a D register: D1, D2... etc. whenever these "events" happen.

A) I believe that the T1.acc values would be in milliseconds, yes?
B) Given the CPU Speed of the BRX PLC and the potential Scan Time of the program, how much discrepancy am I likely to see between the actual T1.acc value and the associated D register into which it was copied.

Yes, I know it depends of the size and executables of the program, but total program size is unknown at this point, and I would be using multiple programs with Stage Programming.  I'm just trying to get a ball park feel for what to expect and find ways to reduce the discrepancy.  Am I looking at microseconds, milliseconds, etc.?

Thanks in advance!!

Good Programming and God Bless!!

SOWEGATS

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3855
    • Host Engineering
Re: Timer -vs- Scan Time Accuracy
« Reply #1 on: November 05, 2026, 08:57:22 AM »
Instead of using TMR for measuring duration, look at the MATH TICKms() function that returns a hardware timer register in millisecond counts.  The value itself does not mean anything, but using it to do calculate time deltas is perfect for this.

So store that value, then on the event you want to measure, call TICKms() again and take the difference.  The delta will be the duration, but as a signed DWORD.  The modulo math will just work even if those TICKms() values appear negative or any combination of positive and negative.  However, the delta must be LESS THAN 0x7FFFFFFF or 2,147,483,647 (largest positive signed DWORD) milliseconds, or slightly less than 25 days???

Will that work better for you?

FYI, you can use MATH TICKus() (microsecond hardware register) to PROFILE PLC INSTRUCTIONs.  Stick MATH w/TICKus() before a (set of) instructions, then another MATH directly below it to take the difference - you get the actual hardware execution time of those instruction(s) in MICRO seconds.  You are just doing it for grainer real-world event time measurement via TICKms().

SOWEGATS

  • Full Member
  • ***
  • Posts: 24
Re: Timer -vs- Scan Time Accuracy
« Reply #2 on: November 05, 2026, 10:17:12 AM »
Never used that function before.  In fact, I didn't even know it existed.  Thank you!!  I will take a look at it.

Also, could a High Speed Asynchronous Input be of service in such a situation?

Many Thanks and God Bless!!

SOWEGATS

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3855
    • Host Engineering
Re: Timer -vs- Scan Time Accuracy
« Reply #3 on: November 05, 2026, 10:30:46 AM »
Also, could a High Speed Asynchronous Input be of service in such a situation?

If you need to measure duration resolution to the MICROSECOND, definitely.  There are High Speed Inputs and corresponding features, along with interrupt capabilities onboard in many BRX MPU models, and in BX-HSIO expansion modules.

SOWEGATS

  • Full Member
  • ***
  • Posts: 24
Re: Timer -vs- Scan Time Accuracy
« Reply #4 on: November 05, 2026, 10:36:53 AM »
The TICKms Function should be more than sufficient. Plus or minus 1 or 2 ms will be plenty accurate for my application.  Maximum duration will only about 60seconds, and, usually, only about 15seconds.

I looked up the TICKms in the instructions.  The last line in the instructions says this:

"Because the resolution of this value is in milliseconds, the primary use is measuring scan-to-scan events. One example is measuring the time between external I/O events."

Gave me a chuckle!!  You guys think of everything!!

Thanks again and God Bless!!

 
« Last Edit: November 05, 2026, 11:10:47 AM by SOWEGATS »