S7 DATE_AND_TIME, wrong day of week causes WinCC Flex to #####

Hi folks. This is my first forum post, I've been practicing S7/STL/WinCC Flex stuff for about 3 months now so hopefully we speak same language, even thou I constantly mix most and least significant bit and such, due history with computers

I have time/date values stored in DATE_AND_TIME in S7-300 and I'm working with kind of temporary, debugging- or low-level user interface with WinCC Flex for it.
I just noticed that if I modify the date-part of D_AND_T with Var-monitor but do not change day-of-week nibble accordingly, WinCC Flex Runtime will render that date and/or time in IO Field to line of # chars, obviously indicating that the DATE_AND_TIME value is broken. Even thou it doesn't show the value even if it was correct.

Now, this isn't a big issue yet if I can screw things by forcing values to DB, but I'm sure that I will run into difficulties with dates and times later, perhaps in another project where I'm trying to let's say read date values without week-day, finding that something like Call SB_DT_DT would return rubbish as the input was "rubbish" aswell.

So, is there a "common practice" way to validate or re-generate day-of-week of DATE_AND_TIME in PLC side? Where will broken day-of-week cause problems? Do you people avoid calendar-dates whenever possible? What if your customer wants daylight-saving or their ERP-system uses it and you need to communicate with it?


As the presentation of future, current and past time is formed depend on rulings of kings, emperors or EU bureaucrats, it would be very frustrating to write one's own date-manipulation functions, those would inevitably be broken if not yet but in future before, just as daylight saving breaks public transport and sleeping rhythms besides your computer(you wouldn't need to download an update every year if it wasn't broken right). If I met an extraterrestial, I'd be very ashamed of how we earth-people represent time

Calling in sequence "DT to DATE", "DT to TOD", "DATE and TOD to DT" seems to rebuild weekday. With needed shuffling of variables etc., loop of 1000 in one program cycle makes cycle time to rise to 22ms from <1ms on S7-319 thou.

Why do you need to loop through these conversions 1000 times per cycle ???????

I can only imagine that you need to fetch the CPU time once per cycle, and then dissect the DATE_AND_TIME into separate parts at the same time. You can then use the separated parts easily elsewhere in the program.
And in most cases, I would not even do that in every cycle.

edit: Maybe you mean the data is stored as TIME (4 bytes) or TIME_OF_DAY (4 bytes), and not as DATE_AND_TIME (8 bytes). DATE_AND_TIME is a special format that is normally only used with the S7 CPU clock.

I am guessing what you are logging in the PLC is event-based information, for example alarms. And you want the alarms to be time-stamped accurately down to the millisecond.
If it were not for this, it would have been more 'typical' to log the data on a PC. The accuracy of the timestamp would then only be as accurate as the time for polling the data. 100 ms accuracy at best.
Is that correct ?

If you use the system functions for setting the PLC clock and then fetching the plc clock the day of week is corrected...

So you could make this sequence..

1. Fetch actual DT and save in a variable
2. Set the plc clock with the DT variable you want to fix
3. Read back the PLC clock to the variable
4. Set the PLC clock back to its original time..

JesperMP said:

Why do you need to loop through these conversions 1000 times per cycle ???????

Click to expand...

Luckily I don't, only max. 1 per cycle But I wanted to see if this conversion is a heavy process and so it seems.

JesperMP said:

DATE_AND_TIME is a special format that is normally only used with the S7 CPU clock.

Click to expand...

Perhaps selecting DATE_AND_TIME comes from my unexperienceness, it was just so easy to draw with WinCC editor. Conversions needed to make the time/date human editable nicely built-in.
I may come to other solution, even TIME has more than enough data for my current purpose. Changing away from DATE_AND_TIME causes more work with panel but at first it seemed to be nice on PLC side.