Display date and 12-hour time on an HMI text line

Why does my HMI show the date but not the weekday?

Most real-time clocks keep year, month, day, hour, minute and second and have no weekday field, so the screen can show a weekday only if its clock object computes one or your program calculates and writes one; the date register alone carries nothing to read.

That absence is deliberate. Weekday is a property of the calendar date, so clock devices leave it out and expect software to derive it. On the screen side, two sources can produce it: a clock display object whose documentation says it derives the weekday from the date, or a tag your controller program calculates and writes to the screen like any other value. If the panel's object list shows no weekday option, no amount of hunting through format codes will make one appear, and hand-editing undocumented format codes risks corrupting unrelated fields on the line.

This also explains the frustrating version of the symptom: the date is perfect and only the weekday is missing or frozen. The date path works because the fields exist; the weekday path has no field until you supply the calculation.

Which device should keep the clock, the panel or the PLC?

Let the device that holds correct time through a power loss own the clock and write it to the other on a fixed interval; when both have battery-backed clocks, ownership goes to whichever the plant logs treat as the reference.

Pick the owner from two documented properties: retention and drift. Retention decides who survives a power cycle with the time intact. Drift decides who stays close to wall time between corrections, and controller clocks generally drift more than the clock in a PC-based panel, so a controller-owned clock needs periodic correction against a trusted source. Panel clock objects document both directions, panel to PLC and PLC to panel, so the write direction is a configuration choice, not a workaround. One widely used arrangement puts the PLC in the master seat and updates the panel's clock every 10 minutes, which suits a plant where the controller's clock is the reference for logs and shift times; a push on that cycle also feeds the panel whatever the controller believes, so set the owner once before enabling the writes. Getting that write path right is the same job as setting the panel clock from the controller, which covers the transport side in detail.

What does an IEC DATE_AND_TIME value contain?

IEC 61131-3's DATE_AND_TIME type carries a calendar date and a time of day in one value, written as a literal such as DT#2024-06-25-14:30:00, and it contains no weekday; some integrated platforms split the same clock into tags such as Clock.Year and Clock.Month.

The literal groups the clock fields: year, month, day, hour, minute, second and fractions of a second. That is everything a clock keeps. If your runtime exposes the clock only as raw registers, converting them into these fields is its own step, and converting controller timestamp units for a factory display walks through that arithmetic. Two traps follow the fields onto the screen. Date order: 11-09-01 reads as month-day-year in one plant and day-month-year in the next, so fix the order once, print it that way everywhere, and let no sample string in a work order decide it. Sample weekdays: check any weekday that arrives in a work order against a calendar before trusting it, because samples get written from memory; 9 November 2001 was a Friday, so an order sample calling it a Wednesday would send you chasing a fault that lives in the sample.

How do I calculate the weekday from a date in the PLC?

A week has 7 days, so the weekday is the day count modulo 7; one compact form is (y + y/4 - y/100 + y/400 + t[m-1] + d) mod 7 with t = {0,3,2,5,0,3,5,1,4,6,2,4}, subtracting 1 from y for January and February, where a result of 0 is Sunday.

All four divisions truncate to integers. The month table encodes the cumulative offsets for a year that starts in March, which is why January and February borrow the previous year, and leap days drop out of the arithmetic with no extra branch. Map the result 0 through 6 onto a seven-element array of day names and write the name to the screen as a text value. If your runtime ships a documented day-of-week function, use it and skip the formula; the formula earns its keep on runtimes that stop at DATE_AND_TIME and leave the weekday to you.

How do I render 12-hour time with the right AM or PM?

Use the screen object's documented 12-hour option when it has one; when you build the string yourself, compute hour12 = hour24 mod 12, show 12 whenever that result is 0, and take AM for hours 0 through 11 and PM for hours 12 through 23.

Three failures account for nearly every wrong suffix. The first is converting twice: applying the hour conversion to a value that has already been rendered flips AM and PM around noon and midnight, which is why a line checked at 1:30 PM can fail at 1:00 AM. Convert the raw hour once, then pick the suffix from a comparison on the original 24-hour value. The second is the twelve o'clock hours: 00:00 must display as 12:00 AM and 12:00 as 12:00 PM, and both come out of the substitute-12-for-0 rule. The third is style: AM/PM in capitals, lower case am/pm, with or without periods, is the object's documented choice, so print what your object documents and keep it consistent across screens. If the line travels to a serial character display as a rendered string, width matters: 2:30 PM is 7 characters but 11:59 AM is 8, and a fixed-width line shifts everything after the time unless you pad the field. How those strings are framed and parsed on the serial link is covered in serial display command parsing and format selection.

Worked example: how does 2024-06-25 become Tuesday and 2:30 PM?

For 2024-06-25 at 14:30 the arithmetic returns weekday 2, which is Tuesday, and an hour of 2 with a PM suffix, so the finished lines read Tuesday 06-25-2024 on top and 2:30 PM below.

Scenario: a packaging machine has a controller with a battery-backed clock feeding a two-line text panel, and the work order asks for weekday and date on top, 12-hour time below.

1. Weekday. y = 2024, m = 6, d = 25. Integer parts: 2024 / 4 = 506, 2024 / 100 = 20, 2024 / 400 = 5. June is the sixth month, so t[5] = 3. Sum: 2024 + 506 - 20 + 5 + 3 + 25 = 2543. 2543 mod 7 = 2, because 7 x 363 = 2541, and 2 is Tuesday.
2. Hour. The clock reads 14:30. 14 mod 12 = 2, and 14 lies in 12 through 23, so the suffix is PM and the field prints 2:30 PM.
3. Date line. Print the plant's chosen order, month-day-year: Tuesday 06-25-2024 is 18 characters, which leaves 2 characters spare on a 20-character line.

Result: both lines derive from one clock value, and each one checks against a wall calendar in ten seconds. That last property is the acceptance test for the whole job.

Which readings prove the format before the machine goes back to work?

Test six readings around the two boundaries: 11:59 AM, 12:00 PM, 12:59 PM, 11:59 PM, 12:00 AM and 12:59 AM, plus the date rollover at midnight on a month end such as 30 June, before you sign the job off.

A machine that happens to be running at 1:30 PM when you finish will show a correct line, and that single reading leaves both boundaries untested. Force every row of the table by setting the controller's clock forward or back, confirm each rendering, then restore true time. Finish with the midnight rollover: 30 June 2024 is a Sunday and 1 July 2024 is a Monday, so the minute after 23:59 on 30 June has to advance the day, the month and the weekday together. Month ends are where hand-rolled date code breaks, because the days-per-month table is the piece most often mistyped.

Why is the date wrong again after a power cycle?

If the date comes back blank, zeroed or frozen after a power cycle, the device you are displaying from lost its clock; check which device carries a battery-backed real-time clock, make that one the owner, and add a clock write at startup as well as the periodic one.

Three checks separate the causes.

1. Power down and up the displaying device alone. A default date such as 01-01-2000 means that device has no battery-backed clock or a spent battery, so it is the wrong device to own the clock.
2. Power cycle the intended owner. If the owner also comes back wrong, the battery is the fault, and every screen it feeds goes wrong with it within one write interval.
3. Add a startup write so the panel receives the owner's clock as soon as the link is up, ahead of the 10-minute cycle. Between writes the panel runs on its own clock, so the periodic correction bounds its error at the interval you chose.

Swap a clock battery or open the cabinet only under the machine's lockout procedure. A controller with no battery-backed clock starts from a default date at every power loss, and no format work on the screen will repair that; make setting its clock part of startup, or let the panel, once it holds the correct time, feed the controller in the panel-to-PLC direction.

Which symptom points to which cause?

Match the symptom to the cause before you change anything: the list below covers the failures this job produces, and each entry names the test that separates it from the next one.

• Weekday shows a bare number or stays blank. The source has no weekday field and the object cannot derive one. Add the modulo-7 calculation and check the result against one known calendar date.
• Weekday disagrees with the calendar. The weekday comes from a hand-set or stale register, or the work order sample itself was wrong. Recompute from the date and trust the calendar.
• Time shows 14:30 on a 12-hour line, or 1:30 with no suffix. The object's format is still 24-hour or its AM/PM option is off. Set the documented 12-hour format on the object.
• AM and PM flip at the wrong hour. The hour was converted twice, or the conversion ran on a rendered string. Convert the raw hour once and pick the suffix from the unconverted value.
• Correct all shift, wrong after a power cycle. The clock owner lacks retention or the startup write is missing. Run the three power-cycle checks above.
• Date is right but the order looks foreign. Day-month and month-day conventions collide between plants. Fix the order once and keep every screen and report on it.

Recommendation: Make the battery-backed device the clock owner and write its clock to the display at startup and every 10 minutes; where both devices keep time through a power loss, let the plant's log reference own it, correct that owner against a trusted source at commissioning, and derive the weekday and the 12-hour rendering on the display side with the calculations above.

Questions