sbixby (Customer) asked a question.
I'm wanting to create a date range from my (PC) application in a Click PLC and have the PLC enable an output if the RTC is within that date range. It's important that if the PLC (and the rest of the controlled system) loses power and restarts, it can still know if it's within the date range. It's easy enough to detect a specific point in time by comparing an application-supplied Y/M/D/H/M/S to latch a bit and another one to clear a bit -- but this won't restart a process if the PLC powers up during the window.
I was hoping to be able to get some kind of epoch value from the RTC and calculate start & end times on the application, then I just compare this epoch value to similarly calculated start and end times and output a corresponding bit.
Any suggestions? I don't think I can or should implement a complex Julian timestamp calculation in "Math" based on y/m/d/h/m/s parts.
Unfortunately there is no native way to accomplish this in the Click. I have forwarded this as a feature request to the Click Product Manager.
You could easily create a date/time composite with a Math instruction, I've had to do that in a Click. MMDDHHMMSS works fine, but you're not accounting for the year, which will make rollovers from one year to the next tricky to incorporate. And depending on if you need seconds resolution, until the end of this year, you could drop the SS on favor of YY, YYMMDDHHMM, but that will no longer fit in a 32 bit signed integer once the new year rolls around.
If put MONTHS first, it will fit. But you lose sorting! :'(
Here's what I ended up doing. (I'm a life-long app programmer, so shifting to ladder logic took a bit of learning, and I'm sure there's other approaches):
What I did - for now at least - is created a timer that increments once per second and tops out at 999,999,999, which shouldn't ever occur. I preset the CTD1 value to a year's worth of seconds as a baseline.
In my PC application, when setting this interval, I first read the CTD1 value and get the current datestamp value from the PC. Then I accept the start and stop timestamps and calculate a delta in seconds, and apply this delta to the value I got from CTD1 to get two dwords.
Then in the PLC, I just compare the current CTD1 to the start and stop times and OUT a flag to use in the rest of the ladder logic.
The catch here is that I need to maintain this value carefully, so when I connect to the PLC (modbus), I will check/update these values each time. Additionally, these values preset to zero so if the PLC comes up without the PC, it won't hit the interval. Then when the PC connects, it can update it immediately and *hopefully* we're all good.
I'd really love an epoch from the RTC, though. "Click Product Manager", please? :)
It's lots of logic, but even if an epoch was currently available, it would still take a convertor program to make the values conveniently and error free.
Hmm... that seems like a usable approach, although it does complicate the ladder logic a bit more than I like. (As a traditional non-PLC programmer, at least)
I might give it a whirl, it would avoid the startup conundrum.
Eh, I ran through this, same issue as I had originally on a slightly different approach.
The problem is that parts roll over independently, so for example, while minute might be in the range, seconds might not be, then vice/versa.
Final answer, if and at least until RTC epoch becomes available.
I went with calculating YYMMDDHHMM value from RTC, and corresponding start/end times from the application.
The YY is offset from 2020, which gives me an effective max of 2041/12/31/ 23:59 using a calculated value of 2112312359 which fits in the signed DWORD range.
Hopefully within 20 years I'll be long gone or the PLC will give me an epoch.