Perhaps OP is using one of the seven Day-of-Week tools found on the RA site (
here)? Or are they using the sci-math-faq formula (e.g.
here)?
From what I can see, all of them use year, month, and day. So when that day value changes is when the calculation will change.
If I had to guess with no other information, I would guess that the GSV call is probably getting yr/mo/d from WALLCLOCK/DateTime**, when it should be using WALLCLOCK/LocalDateTime**. LocalDateTime appears to be correct, so perhaps the CSTOffset is -7200E6µs (i.e. -2h).
* i.e. the base time, ideally UTC or GMT? but it could also be EST with a CSTOffset of 0.
** i.e. the Georgia, USA-appropriate local time i.e. Eastern US i.e. EST/EDT
We do have other information:
- One of the images, presumably of the AOI currently in use, makes a GSV call to WALLCLOCKTIME/DateTime, which supports the idea above
However:
The day of week program started changing day of week 2 hours early. It changes at 10 P.M. instead of 12A.M. Just started this year.
So it was working correctly before. Which raises the question of what changed i.e. why does the day-of-month change 2h earlier since New Year's?
Also:
I have a GSV with local date time so maybe it is causing a conflict in my logic.
Which seems to suggest WALLCLOCKTIME/LocalDateTime is in use.
The only way to be sure would be to see the online (real-time) values, including .Hour, of the
TestDateTime structure in the same picture with the Windows clock at lower right.
By the way, a much simpler formula would be to
- get the the µs since 1970 local time i.e. (WALLCLOCKTIME/CurrentValue + WALLCLOCKTIME/CSTOffset),
- divide by 86400E6 (µs per d) with truncation to get days since 1-Jan-1970,
- add 4 (1-Jan-1970 was a Thursday), and finally
- reduce that modulo 7 to get the current day of week number (0 => Sun through 6 => Sat).
That would be messy, I think, for CompactLogix as they do not have LINTs. But it could be done with DINT pairs.