Data log time is reset in HMI

[OkiePC]

Just got back from a customer that had a 4" CR1000 with no logging functions connected to a Click Plus running a little pump station. It does have a clock and alarm banner on the Master Slide, which all the applications I've ever created in Crimson have. His was locked up with "Invalid Database" and I had to update it with my laptop. There's a good possibility I will be going back up there after Red Lion comes out with a fix.

On the way back, I stopped at another customer location who uses his G12 trend to find peaks in filter turbidity for his reports. I didn't know he was using the Crimson trend for that, but it works well as long as the trend is working ... which it doesn't when it can't plot from 3-22-2024 to 1-1-1997. I connected his office PC to the Red Lion and downloaded the log files in csv format and noticed that he had two log files for today. One of them worked up until 1:42 am and then a new file was created with ~12,000 entries for filter flow and turbidity with a timestamp of midnight 1-1-1997 followed by the normal once per minute entries after that, but the hour appears to be wrong by about 1 hour. Not a big deal there since he's just looking for peak NTU during each batch.

Many of my installs can be accessed remotely, but a lot of the simpler ones are standalone wells and pump stations scattered all over the state.

 

[JordanCClark]

I don't have a horse in this race, as i don't use any Crimson products. It won't stop me from having on opinion on it, however.

I suspect they got around the Y2K problem by using an arbitrary epoch, mention earlier in this thread, with the though of '27 years is a long time from now, we can fix it later. Or, someone else can, because I'll be retired then.'

Hopefully for you fellows using these, they can come up with a 64-bit clock to use. Otherwise, it will be a new epoch date and they'll kick the can even further down the road.

 

[padees]

Here's another email I just got from RL.

 

[atc222]

Well, Monday approaches.

I’m going to attempt to update one customer remotely.

No big deal if that fails, only 30 minutes away.

I will update this thread with my success or failure.

I’d encourage others to do the same.

(Report their results, that is.)

I’ll post again by 8:00 am EST.

 

[atc222]

Installed 3.2 and updated one unit remotely. Success.

Note that if you are using remote access, and have a shortcut setup to go directly to remote view, the shortcut will need to change...

 

[OkiePC]

I updated two of them yesterday via remote access. One that I updated from 3.1 to 3.2 and another that was already on 3.2. I haven't used 3.2 a bunch, but one thing that is different is where you set the IP address for the Ethernet port(s) and that you need to enter that IP address in the Link Options TCP/IP field. The Find... option didn't appear to be able to find the HMI (even the one running 3.2) via VPN router. Also, after getting the firmware installed, the update asked for a login to continue and in both cases rejected my entry on the first attempt but succeeded on the 2nd attempt and then I was able to perform the update again which finished installing the application. In both cases, retentive tag data was retained (which I use for storing email alarm notification information).

2 down, ~150 to go ...

 

[kolyur]

>Crimson tracks time internally using a two methods: The first is to count the number of seconds since 01/01/1997, and the second is the count the number of 200ms ticks since that same epoch. The latter clock is used for data logging and other similar purposes where better than one second resolution is required. Both values are stored in 32-bit numbers, which works fine for the 1 second clock, but for the 200ms clock creates a wrap-around after slightly more than 27 years. To be precise, the 200ms clock will wrap-around at 01:17:39 on 03/22/24.

This is interesting. We experienced the initial crash of all our HMIs on 3/22 along with everyone else. However, after a power cycle they booted up normally and are maintaining the correct time & date. I am using some of the clock functions such as GetDate() and these seem to be working. I'm wondering, exactly which features make use of the 200ms clock and would be affected? Just the data logging or are there others? I'm just trying to determine which of our screens we need to worry about updating.

 

[OkiePC]

Alarm and Event timestamps and data log timestamps are affected. Everything else seems to be fine. If you are not using trending, alarms or events, you won't see the bug.

 

[arpus4KM]

We regret this event over which we have no control,