Retentive data lost Micrologix1000

Quick reply, before my Retentive Data Lost bit is set...

Just a little addition to, and qualification of, the previously mentioned and aplied fix, possible causes of, and to put an official stamp on what is being perceived as an obscure method of recovery...

NicolasP said:
...clicking in the error bit box and manually replace the '1' by '0'...So strange!! but it worked..

gbradley said:
...The thing that surprised me was that the Clear error didn't go in and reset the bit, I had to reset it myself.

NicolasP said:
Lol Byron, I'm just reading your message. So you know that 'manual clear" solution.

Isn't it strange?? I mean, almost frustrating when I think about all those who had to buy another one without knowing that. I'm pretty sure AB knows that solution. Do they propose it?

That's a Roger...

19267 - MicroLogix 1000 : Major Error S:6 = 5h, Retentive data is lost
Access Level: TechConnect

...which informs you that the Retentive data is lost bit must be manually written to "0" and which mentions and provides links to information regarding electrical interference and elimination thereof.

This technote is quite similar but somewhat less informative...

38762 - MicroLogix Controller 5h Fault
Access Level: TechConnect

...although it does additionally mention good grounding of the controller chassis, which has also previously been advised in this thread.

There was also an issue with substandard SRAM components for a particular batch of MicroLogix 1000 controllers manufactured between mid 2004 and mid 2005. These controllers could intermittently fault with the following error codes...

34047 - MicroLogix 1000 : Solid Red Fault Light, Error Codes 0009h (Fatal Internal Hardware Error) or 0005h (Retentive Data Is Lost)
Access Level: Everyone

Users are advised to check the date code on the controller label. If of the affected batch then the controller should be eligible for a free-of-charge replacement. Whether Rockwell are still honouring this I'm not sure but I can't imagine you would be left with no recourse.

General reasons as to why certain installations, not properly grounded or with loads not surge supressed, may run trouble free for many years before suffering electrical interference issues may be the introduction of new unsupressed and relatively heavy loads in or around the controller system, degredation in component noise immunity due to age, including the power supply, or field devices powered from the controller power supply, if 24 VDC, failing intermittently or permanently, such as shorting on a cable or damaged sensor head.

That was the "quick reply".

Just to add some insight into the following thinking and to explain what many here are finding a strange thing to have to do...

alive15 said:
Is it wise to create a rung that automatically updates that bit to 0 if we keep getting this error?

rupej said:
...Probably not...

Let's take "probability" out of this and apply some "wisdom"...

There are different types of MicroLogix Major Errors...

Where poor grounding or lack of surge supression is the root cause of a MicroLogix processor throwing a Major Error, the first error it will most likely throw is Major Error 0002h - Unexpected reset occurred at power up. Major Error 0002h is a Non-user error. This means that it is caused by conditions outside of the user program and so does not execute a user-fault routine. This 0002h power up fault may clear certain memory and so retentive data is now indeterminate and so cannot be trusted. The Retentive data is lost bit is set. This does not yet throw Major Error 0005h - Retentive data is lost.

The Non-user error 0002h - Unexpected reset occurred cannot be automatically cleared. The processor is taken to Fault Mode and this error may only be reset by software or a power cycle. Using either method, when the processor next attempts to go to Run Mode, it will first perform a prescan. The prescan examines the Retentive data is lost bit and if still set the processor will then throw Major Error 0005h - Retentive data is lost and put the processor into Fault Mode.

Because this can only now be cleared by manually writing a "0" to this bit, successive power cycles will not clear the error and users are forced to investigate further. Once this bit is found set to "1", users may now believe that this error, alone, faulted the processor and may know nothing of the original 0002h Major Error which was the root cause i.e. 0005h may be a by-product of 0002h. Not always, mind you, but where interference is the cause, most likely.

The reason the Retentive data is lost bit is not automatically cleared is to explicitly alert the user that retentive data is currently indeterminate. If this is not so important to the process when going to Run Mode, the user may explicitly write a "0" to the bit and then go to Run Mode, but they are now aware of the fact before doing so. The process will attempt to begin with whatever Data File table values are currently present. If retentive data being indeterminate is important to the process when going to Run Mode, then the user may alternatively download a copy of the program with determinate or initialized values, if one exists, and then attempt to go to Run Mode.

As I've mentioned, Major Error 0005h - Retentive data is lost may be a by-product of Major Error 0002h - Uexpected reset occurred if interference is at play and as such you cannot use the user-fault routine to reset the fault condition - the processor is taken into Fault Mode. However, Major Error 0005h may also be thrown on its own under other conditions. But, it is only ever thrown when attempting to go to Run Mode. It is never thrown when already in Run Mode.

Time to add this quote in here...

rupej said:
...Alternatively, if it doesn't stop the program from faulting, it won't help because the program can't get to run mode to automatically clear the bit.

It does not have to...

When attempting to go to Run Mode, and Major Error 0005h is thrown, and because it is classed as a Recoverable error, it may execute a user-fault routine. As such, the user may attempt to clear the Retentive data is lost bit - S:5/8 and Major Error Halted bit - S:1/13 in this routine. This routine is executed before the processor attempts to go to Run Mode. If the fault condition was temporary, then clearing the Major Error in the user-fault routine should recover the processor from fault and attempt to go to Run Mode once again.

Note: Major Error 0005h is special in that it is only thrown when attempting to go to Run Mode. Therefore, a user-fault routine is used here to attempt to continue to Run Mode. For other Major Errors that may occur when the processor is already in Run Mode, a user-fault routine may be used to prevent the processor from going out of Run Mode and into Fault Mode.

In a futile effort to be as brief as I can, I am not going into great detail on exactly how you configure a user-fault routine. But, by using one to attempt to automatically clear a Recoverable Major Error 0005h, you are implementing exactly what you have asked, alive15. Whether one should do this, or not, is down to the application and whether there are any concerns with losing retentive data, such as those expressed by rupej, during power cycles or cycles of Run Mode. If not an issue, then this method is available, permitted and supported by Rockwell.

Users need to know, or look up, the individual Major Errors and determine which type they are. Then, if possible, users must decide whether attempting automatic fault clearing is suitable, or not.

Just to mention the other type of Major Error - Non-recoverable. This error is classed as an error caused by the user that cannot be recovered from. The user-fault routine is executed when this fault occurs. However, the fault cannot be cleared. A power cycle or software must be used to clear these Major Errors.

Some instructions on ways to automatically attempt to clear these faults...

43075 - SLC 500/MicroLogix Processors: Automatically Clearing Faults
Access Level: TechConnect

Note the first method - setting the Fault Override at Powerup Bit S:1/8. This one is powerful in that it allows anyone power cycle a faulted controller and it will automatically attempt to clear all Major Errors and go to Run Mode. The down side is, it is more of a blind reset. If the processor recovers, they will never know which Major Error faulted the controller, unless they can go online to investigate at the time. Some OEMs and integrators use this bit to provide their customers with a quick recovery method where they may not necessarily care what happened, but just want to get going again, if possible.

Using a user-fault routine, or routines, the user can decide which individual Recoverable Major Errors they want to include for user fault recovery, and also may add logic to record these events for later analysis before clearing them. The other Recoverable Major Errors not cleared in a user-fault routine will go ahead and fault the processor.

However, due to the fact that this particular Major Error may be caused by poor wiring practices, it would be best advice to rectify the external root cause, rather than masking it.

Dang, hit the 10k word wall, again...

Regards,
George
 
I know this is a long old thread but Searching "RETENTIVE DATA LOSS " on this
forum found me this and Geospark was correct as I had "Unexpected Reset Occurred"
as my Fault and when I cleared fault and put in run it faulted again with " Retentive Data Loss" and a Clear Fault would not work. I manually entered the 0 in Retentive Data Loss
and cleared to go to run. This little brick was installed by an OEM for retrofit to replace
an obsolete DynaPro HMI to Giddings & Lewis Pic90
The program in it basically has push button inputs each just fire a B3:X/X and has
some B3:XX that fire a few outputs. I will have to look int suppression and grounding.
 
In the case of my Micrologix 1000 below, the Reset worked a few more times, and then the Little PLC finally gave up.

I replaced the stand alone Micrologix 1000 which did not have an HMI connected.
I used a Micro 820 and added a Red Lion HMI
Total cost was less than the cost to buy a used Micrologix 1000.
 
Solder joints

In an effort to look busy yesterday, I pulled out a ML 1000 I had set aside a long time ago. The only indicator as to what was wrong with it was my hand scribbled "Flakey." I powered up and got the solid, red fault LED. I tried repeatedly to get online, but I could not. Auto-configure kept failing. I came to work this morning and tried again for some reason, and it worked.
The fault was "retentive data lost." I cleared the major fault, and manually set the 0 to a 1 for the retentive data error. Then it faulted again as soon as I went into "run" mode. This happened a few times. Eventually, I couldn't even get online again.
I swapped the board with the I/Os and got the same thing. I figured that narrowed the problem to the power supply board. I checked all the capacitors. They all measured good. 24V and 5V measured good. I noticed the solder joints on the interboard connector cable looked like cold solder joints. I resoldered the pins.
I was able to get online immediately. I cleared the fault and went into "run" mode. It hasn't had any problems yet. I guess the bad solder joints and susceptibility to noise were the wrong combination.
 
... I noticed the solder joints on the interboard connector cable looked like cold solder joints. I resoldered the pins.
I was able to get online immediately. I cleared the fault and went into "run" mode. It hasn't had any problems yet. I guess the bad solder joints and susceptibility to noise were the wrong combination.




What is the date of manufacture? One of the earlier posts in this thread mentioned a bad batch ca. 2004-2005.
 
What is the date of manufacture? One of the earlier posts in this thread mentioned a bad batch ca. 2004-2005.

I saw that. I'm not sure what the manufacturing date is. A lot of times, my customers need to be up and running as soon as possible and can't wait for me to hammer out a replacement from AB.
 
I saw that. I'm not sure what the manufacturing date is. A lot of times, my customers need to be up and running as soon as possible and can't wait for me to hammer out a replacement from AB.


yah i was just curious. usually there is a sticker with a date of mfr, or at least a firmware rev. which might be a proxy.
 
Scot@Atlas said:
...The fault was "retentive data lost." I cleared the major fault, and manually set the 0 to a 1 for the retentive data error. Then it faulted again as soon as I went into "run" mode. This happened a few times...

Hi Scot@Atlas,

That was a good find on the dry solder joints. However, I just want to clear up some confusion on what you have written above with regard setting or resetting the fault bit. If the processor has set the Retentive data is lost bit, then it is now at a value of "1". To reset the fault before going to Run Mode, you would have changed the value from "1" to "0", and not from "0" to "1", as you have described. Otherwise, you were enabling the fault, not disabling it. But I don't think that is what happened? I just think you described your actions here incorrectly?

That's just for any astute readers who may "spot the difference" between what I have described and what you have described, and so may cause some confusion.

Regards,
George
 

Similar Topics

Need some insight into why this happened. After finally getting a VM to connect to a CPU 216 2 siemens processor, uploaded the program. made a...
Replies
5
Views
2,478
I witnessed an issue today with a ML1000, faulting on Retentive data lost (S:5/8). We could not establish exactly what 'retentive data' was lost...
Replies
6
Views
5,592
It would be clear to most, but not me. My ML1000 faults out with "retentive data lost" It is a simple program with one Proximity input, and two...
Replies
5
Views
4,124
I am getting a Fault 5h (retentive data is lost) on a ML1000 PLC I clear the fault, and it comes back.. I don't really understand what the...
Replies
6
Views
5,670
I have been having a big problem from moving to a Red Lion G308C100 to a CR3000-0700-00420. Let me say that I'm already working with red lion on...
Replies
1
Views
1,935
Back
Top Bottom