Map an operator toggle switch to one discrete internal tag, fire an alarm event on each transition, and read the two timestamps from the alarm history. One job leaves two records; subtract the start time from the finish time for the duration. A job logged 08:14:30 to 08:47:10 ran 32 min 40 s.
You can record how long a job takes from the operator panel alone, with no timer running in the controller and no math in the panel. Make one discrete internal tag the job signal, log an alarm event every time it changes state, and read the two timestamps back from an alarm history. Each job leaves two records: the switch turns on when the job starts and off when the job finishes. Finish time minus start time is the duration, read after the fact.
What the log gives you
The alarm history is an event log. The event you care about is the job boundary, and the log keeps the date and time of each one in order, on a screen an operator can open. What it will not give you is a number counting up while the job runs. If the crew needs the running time on screen, time the job in the controller and format the PLC timer value as a duration display; that is a separate build from this one.
Two records per job is the number to remember: every duration you report costs two lines in the log.
What you need
Four objects in the panel project, and a clock you trust:
| Object | Job here |
|---|---|
| One discrete internal tag | Holds job state: off before, on during, off after |
| One toggle switch mapped to that tag | The operator marks both boundaries |
| One alarm event on that tag | Writes a log record at each state change |
| One alarm history object or history button | Shows the records with date and time |
The clock inside the panel stamps every record, so set it before you trust anything the log prints. If the panel takes its time from the controller, setting the PLC clock from the operator panel is quicker than typing the time in two places.
Set it up in five steps
- Create the discrete internal tag. Name it whatever your own scheme for job data uses; the panel only stores its state.
- Put a toggle switch on the job screen and map it to the tag. Label it so both positions read clearly, running and done. Operate it once and confirm the tag follows the switch before you build anything on top of it.
- Add an alarm event triggered by that tag. A discrete alarm watches one bit, and its configuration picks which state raises it, so set message text that names the transition: job started on one edge, job complete on the other. If your event logs only one direction, add a second event on the opposite state so both boundaries print their own text.
- Add the alarm history object to a supervisor screen, or the button object, where the software has one, that opens the panel's built-in history screen and lets an operator acknowledge or clear entries. Confirm the history lists date and time with every record.
- Clear the history and run the check cycle below before the first real job.
Worked example: one job, two timestamps
First shift runs a weld cycle. The operator turns the switch on at 08:14:30 and off at 08:47:10. The history holds two records:
| Record | Time | Text |
|---|---|---|
| 1 | 08:14:30 | Job started |
| 2 | 08:47:10 | Job complete |
Subtract start from finish. The seconds need a borrow: 10 s from 30 s gives 40 s after borrowing a minute, 46 min minus 14 min gives 32 min, and the hours match. The job ran 32 min 40 s.
A job across midnight works the same way, because each record carries its date. On at 23:52:10, off at 00:14:30 the next day: 7 min 50 s to midnight plus 14 min 30 s after it, 22 min 20 s total. Read the dates as well as the clock times, or the subtraction looks wrong.
How to check it worked
- Clear the history, or write down the time of the last entry, so the new records stand out.
- Turn the switch on at a time you note, say 09:00:00.
- Work or wait a known interval; use 10 min for the test and turn the switch off at 09:10:00.
- Open the history. You want two new records, in order, 10 min 00 s apart, each with its own text.
If a record is missing, check three things in this order: the tag changes state when the switch moves, the event's trigger is that tag, and the history is set to show that event's class. The history object only displays what the event system recorded; it brings back nothing that never fired.
Where the method breaks
The log depends on the switch changing state at both boundaries. A switch left on after a job logs no start for the next job, because the tag never moved, and that gap stays in the record. Panel power is the other weak point: if the panel reboots mid-job, check which state the internal tag comes back in before you trust the running job, and see HMI toggle switch resets at PLC power up for the fixes.
When the history fills
Two records per job sets the horizon. A history capped at 64 records keeps the last 32 jobs, since 64 records divided by 2 records per job is 32 jobs. When the line needs more than the panel holds, save the alarm history beyond 64 entries to USB and keep the panel log for the current shift.
The decision
When the finished numbers belong in front of the whole crew, a shop-floor status display can play the exported list offline; it is a playback screen with no live tag connection to the panel.
Recommendation: use the event log when the deliverable is a timestamped record of when each job started and finished, and reading the duration after the fact is acceptable. Time the job in the controller when the number must display while the job runs. Either way, drive both boundaries with one operator action each, and check the pair of records on the first cycle of every new job.
Questions
What happens if the operator forgets to turn the switch off at the end of a job?
That job gets no finish record, and the next job gets no start record either, because the tag never changed state between them. Have the operator cycle the switch once and note the gap on the report; the log then resumes from that event. The missed duration cannot be recovered from the history.
Do the recorded times stay usable if the panel clock is wrong?
The printed wall-clock times are wrong by the offset, but the duration between two records stays correct as long as the clock runs at the right rate, because the same offset sits in both timestamps and cancels in the subtraction. Set the clock before you use the log for records, and check it against a known reference at commissioning.
Can I show the elapsed time while the job is running?
Not from this log; the alarm history holds finished events with timestamps, nothing that counts up live. For a running display, time the job in the controller and put the timer value on the panel as a formatted duration. The two builds share no objects: one lives in the event system, the other in tag display.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.