No announcement yet.

Time Stamps

  • Filter
  • Time
  • Show
Clear All
new posts

  • Time Stamps

    PLC: Click
    ISSUE: Need to time stamp 4 to 5 past power losses - Then notify user via HMI so the user can make an operational decision.
    ISSUE 2: This same "function" will allow the user to decide (beforehand) what he/she wants the clock to do at power loss. A) Have the RTC continue to run B) use the last "stamped" date and time update the RTC to so the PLC can pick up where it left off.

    I have been trying to figure out a way to "Time Stamp" a loss of power so that when the system comes back up, it will notify the user on the HMI when the PLC lost power. I have tried using a series of COPY instructions with timers and tried think of a way to do COPY instructions with a shift register. Both functions would have taken the previous value and copied it to the next address upon power up. I also tried to make a FOR/NEXT loop in a subroutine , but seem to of struck out there as well.

    With Stamp 1 being the most recent power failure and Stamp 5 being the oldest power failure and Stamp 0 would be a rung with no condition so the current RTC addresses would copy to Stamp 0. Upon power up, Stamp 4 would copy to Stamp 5, Stamp 3 would copy to Stamp 4, Stamp 2 would copy to Stamp 3, Stamp 1 to 2, and Stamp 0 would copy to Stamp 1, then go back to constantly being overwritten in an unconditional Rung.

    Does anyone have any ideas on how to accomplish this or point me in the direction of an existing thread that I cannot find?


  • #2
    Continuously copy the time to a retentive register. On first scan (before the copy), copy that register to Stamp0, move the others, etc.

    This is actually stamping exit-from-run, so you'll also catch R-P transitions but that may be OK, or you can probably screen for that if need be. Also normal shutdowns vs. "power loss", if need be.


    • #3
      Also, if your RTC can get reset by an operator choosing the continue option, are the times stamps still meaningful?


      • #4
        The time stamps are meaningful for troubleshooting. A lot of our equipment is installed in remote areas with dirty power, so I am hoping it will be an indication of how dirty it is.

        As far as the user setting the clock, half our customers want the clock to continue if there is a power loss and half want the automation system to pick up where it left off. Our system is almost synonymous to an irrigation system. For example, say you want to water your lawn at 6:00 AM on Tuesday. If you lose power before 6: 00 Am and comes back up after 6 AM, your lawn wont get watered because the RTC is still running, but the ladder logic misses the trigger to start the process we are automating. This is obviously where the time stamp comes in. On initial set up, the user would select which option best suits their application.

        Pardon my ignorance, but what do you mean by R-P transitions?


        • #5
          Click image for larger version

Name:	Screen shot 1.JPG
Views:	95
Size:	89.6 KB
ID:	120573


          • #6
            This was actually a lot easier than I made it out to be! It will just take several lines of code to do the clock and calendar, but I think this should work.


            • #7
              Run Mode to Program Mode transitions. If you flip the switch from Run to Prog and back again, you'll get a First Scan.

              I still wouldn't be resetting the clock. If you do that, the task scheduled for Thursday at 1000 will end up running on Saturday at 1637 or whatever. Plus, what I was asking about relevance of time stamps if you let the operators reset the clock is just that, troubleshooting. If you mangled the clock by letting him reset it after previous outages, then the power outage the PLC is telling him was Tuesday night at 2200 actually occurred Friday at 0430.

              What I'd do would be this: When the PLC wakes up after a power outage, it knows from the time stamp when the outage occurred. From that and the task schedule, it knows which if any tasks have been missed. So compile a list of missed tasks, by scheduled time and task description, display those on an HMI screen, and pop that screen to the top. For each missed task, the operator should have three options: Reschedule task (with immediately being one scheduling option), delete task from list, and ignore task (don't execute but don't delete). He should be able to decide that on a task by task basis, and probably for convenience, global execute/delete/ignore for all shown tasks too. Make sure the list is retentive, so that if all the missed tasks have not been made up by the next power outage, then the record of them won't be lost.

              Using your irrigation analogy, the operator might want to make up all missed tasks but not immediately as the ground can only absorb so much water at once, so he has to reschedule the makeups out over time. Ignore allows him to defer the decision, or if an operator has to be present for the task, he can come back later and do an immediate, for example.

              Then you can accommodate the varying preferences between customers by allowing them to specify the handling of missed tasks. Always delete, ask me every time, etc. Only if they choose ask do they get the dialog I described above. You could even continue to track the missed tasks, so that if a user who normally wants them ignored can make an exception and go back and look at what was missed and decide to make them up as would the operator who normally does that.


              • #8
                Here's what I've done to log power up times. I copy the current time into DD1000 with some math creating a composite date/time MMDDHHMMSS. I copy this around at _1st_SCAN. With a few more lines you could continually write DD1000 to DD999 every scan, and on _1st_SCAN copy DD999 to another block of registers so you can also determine how long the power went out.
                Attached Files