News:

  • April 30, 2026, 09:30:12 AM

Login with username, password and session length

Author Topic: Timed Events  (Read 13006 times)

Evilbeard

  • Hero Member
  • *****
  • Posts: 160
Timed Events
« on: January 20, 2017, 09:38:55 AM »
I just want to see if I'm thinking about this right. I'm sure there's probably an easier way.

Let's say that I wanted to monitor production per shift. The shifts change a 7am, 3pm, and 11pm. I have a totalizer in my program already as a structure ($totalizer).

I setup 3 Time Structures (FirstShiftCompare, SecondShiftCompare,and ThirdShiftCompare) as UDT0, UDT1, and UDT2.

I move the values 7 -> ThirdShiftCompare.Hours, 15 (3pm) -> FirstShiftCompare.Hours, and 23 (11pm) -> SecondShiftCompare.Hours.

I then use DTCMP to compare $Now to FirstShiftCompare, SecondShiftCompare, and ThirdShiftCompare, looking only at the hours. I use the "set if equals" bit to trigger a move. The move function will move $totalizer.ireg1 to a memory location. I can then do math on that location to calculate the production on that shift Daily, Weekly, Monthly, and Annually.

Is there an easier way to do this, or am I on the right track?

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3806
    • Host Engineering
Re: Timed Events
« Reply #1 on: January 20, 2017, 10:10:09 AM »
That sounds great, especially if you need to set the shift changes to utilize minutes (e.g. 7:30).  You may just want to compare hours and minutes in your DTCMP that way if you ever did set the shift change to half-hour, it would "just work".  For now, set the .Minutes UDT members to 0 and tweak the DTCMP box.

Also, the DTCMP "if equals" result will be ON for the whole hour (minute), so you will want to do a differential contact on the "if equals" result to make it an "event" instead of "level" for a whole hour (minute).

Evilbeard

  • Hero Member
  • *****
  • Posts: 160
Re: Timed Events
« Reply #2 on: January 20, 2017, 11:20:46 AM »
That sounds great, especially if you need to set the shift changes to utilize minutes (e.g. 7:30).  You may just want to compare hours and minutes in your DTCMP that way if you ever did set the shift change to half-hour, it would "just work".  For now, set the .Minutes UDT members to 0 and tweak the DTCMP box.

Also, the DTCMP "if equals" result will be ON for the whole hour (minute), so you will want to do a differential contact on the "if equals" result to make it an "event" instead of "level" for a whole hour (minute).

Yeah, the DTCMP compares date and time, date only, or time only. I've set it to time only, and I've just set those times for them to compare. If I have it to compare time, it should just look for 07:00:00, correct? So it'd only be on for a second?

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3607
  • Darth Ladder
Re: Timed Events
« Reply #3 on: January 20, 2017, 11:54:41 AM »
I typically prefer to do a range check, rather than depend on looking at the exact moment when the time strike occurs.

For example, I do something that emulates an old motorized time switch where you place the little pegs around the dial that flip the switch as they pass.  You can set a couple on and off times per day.  Originally, I just watched for the transition times, which worked, except that if someone changed the "pegs", my logic didn't get right with the world till it passed the next peg.  If they changed one to a time already past, the output didn't come on.

That's not explicitly applicable to you, unless the shift times change sometimes, but another case is when I want to totalize stuff daily.  If the system is shut down at night, it doesn't do anything at midnight.  Now I keep track of the last date upon which I totalized, and if the current date is different, do it.  This might apply more directly in your case if the PLC is ever shut down or faulted at the exact shift change time, it's going to mess up your shift totals for the day.
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3806
    • Host Engineering
Re: Timed Events
« Reply #4 on: January 20, 2017, 12:57:14 PM »
If I have it to compare time, it should just look for 07:00:00, correct? So it'd only be on for a second?

Yes, that is correct.  Apologies for my incorrect info  :(.

Evilbeard

  • Hero Member
  • *****
  • Posts: 160
Re: Timed Events
« Reply #5 on: January 20, 2017, 01:04:34 PM »
If I have it to compare time, it should just look for 07:00:00, correct? So it'd only be on for a second?

Yes, that is correct.  Apologies for my incorrect info  :(.

We're only human, except BobO.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6154
  • Yes Pinky, Do-more will control the world!
Re: Timed Events
« Reply #6 on: January 20, 2017, 01:47:15 PM »
We're only human, except BobO.

Careful. My true nature isn't common knowledge...
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

Evilbeard

  • Hero Member
  • *****
  • Posts: 160
Re: Timed Events
« Reply #7 on: January 20, 2017, 02:04:54 PM »
I typically prefer to do a range check, rather than depend on looking at the exact moment when the time strike occurs.

For example, I do something that emulates an old motorized time switch where you place the little pegs around the dial that flip the switch as they pass.  You can set a couple on and off times per day.  Originally, I just watched for the transition times, which worked, except that if someone changed the "pegs", my logic didn't get right with the world till it passed the next peg.  If they changed one to a time already past, the output didn't come on.

That's not explicitly applicable to you, unless the shift times change sometimes, but another case is when I want to totalize stuff daily.  If the system is shut down at night, it doesn't do anything at midnight.  Now I keep track of the last date upon which I totalized, and if the current date is different, do it.  This might apply more directly in your case if the PLC is ever shut down or faulted at the exact shift change time, it's going to mess up your shift totals for the day.

I think what I'm going to do is every time it hits 7am/3pm/11pm, it will write the number from the totalizer into a memory location, and then write the date/time into a memory location. Then on first scan, I can compare the last update's date to the current date. If it's not the same date, I'll have it update the memory locations. Then when it hits my shift changes, they'll continue on as normal.