drbitboy
Lifetime Supporting Member
Wow.
I apologize for distracting us from the main story of the thread, which seems to be that the code could not be fixed in the original SLC, because ... communications (am I getting warm)?
@I_Automation: am I understanding this right that the customer-supplied story suggests between-shift changes in the EEPROM (we know the code is coming from the EEPROM because it is powered on each day and S:5/8 is 1)? And as @Ken Roach mentioned, wouldn't there be a checksum or CRC tested when the code is loaded from the EEPROM, to catch such an event? Occam's razor and all that.
Is there a timestamp embedded in the data on the EEPROM?
There is so much more to this field than the easy part i.e. coding.
I apologize for distracting us from the main story of the thread, which seems to be that the code could not be fixed in the original SLC, because ... communications (am I getting warm)?
@I_Automation: am I understanding this right that the customer-supplied story suggests between-shift changes in the EEPROM (we know the code is coming from the EEPROM because it is powered on each day and S:5/8 is 1)? And as @Ken Roach mentioned, wouldn't there be a checksum or CRC tested when the code is loaded from the EEPROM, to catch such an event? Occam's razor and all that.
Is there a timestamp embedded in the data on the EEPROM?
There is so much more to this field than the easy part i.e. coding.