Hello Paul -
We are aware of this issue and our development team is urgently working on this for resolution. We will update you on this matter as information becomes available.
We apologize for any inconvenience on this matter and thank you for your patience.
Thank you.
Lindsay Wenke, Technical Support Generalist I
Red Lion Controls | www.redlion.net
(877) 432-9908
The information contained herein, including attached files, is provided for informational purposes only. It is general information and may not reflect upon or address your situation. Red Lion makes no representation about specific knowledge of the customer's system or the specific performance of the system. Red Lion is not responsible for any damage to equipment or connected systems and disclaims any liability for actions you take or fail to take based on the information provided.
From me:
Mar 22, 2024, 9:45 AM EDT
I have a customer with 5 Graphite 15" HMIs that all suffered a "Software Exception 0F-2000-57AC-3707". They all recovered fine after touching the screen to continue. This happened on all five units within an hour or so of midnight last night. It was noted that one of them had an incorrect time on its alarm history this morning. The others appear to have the correct time. We think the night shift operators may have corrected the time using the controls we built into the application on those. I suspect this may be related to DST, since these units are still running an older version of Crimson 3.0 that probably has a different Daylight Savings Time calendar.
Last week, I had a similar occurrence from a customer with a CR3000 running on the latest version of Crimson 3.1 where at the moment of (present day) daylight savings time change, his HMI clock reverted to 1-1-1997 and he didn't catch it until 3 days later trying to review a flow trend. I don't think that unit triggered a software exception. It made for some funny looking trends with dashed lines running off the edge of the page.
I just wanted to report this and find out if there are any recommendations to prevent this going forward aside from, obviously, upgrading them to 3.2.
>>> start=datetime.datetime(1997,1,1)
>>> end=datetime.datetime(2024,3,22,1,16)
>>> d=end-start
>>> d.total_seconds()
858993360.0
>>> d.total_seconds()/(math.pi*1e7)
27.342607865423194
>>> math.log(d.total_seconds()*10)/math.log(2)
32.9999998333918
>>> math.log(d.total_seconds()*5)/math.log(2)
31.999999833391797
>>> datetime.datetime(1997,1,1)+datetime.timedelta(seconds=(1<<32)/5)
datetime.datetime(2024, 3, 22, 1, 17, 39, 200000)
The function computes an integer representation of spacecraft time in milliseconds by taking the spacecraft clock represented in seconds as a 64-bit floating point number, multiplying it by 10, and casting it back into a 32-bit unsigned (i.e., non-negative) integer. (“Floating point-to-integer conversion” is necessary in order to convert a decimal number issued by the clock into a binary value recognized by the computer.) The computation does not guard against an overflow condition where spacecraft time in milliseconds can no longer be fully represented within 32 bits. This occurred when the spacecraft clock reached 429,496,729.6 seconds, which corresponded to the date “DOY 223” (2013). At this point in time or beyond, the computation results in a floating point error that ultimately triggers a processor reset.