You are not registered yet. Please click here to register!

plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!

Go Back - Interactive Q & A > - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Thread Tools Display Modes
Unread March 23rd, 2018, 10:28 PM   #16
Lifetime Supporting Member

Geospark is offline
Geospark's Avatar
Join Date: Feb 2012
Location: Kildare
Posts: 2,793
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...

Originally Posted by NicolasP
...clicking in the error bit box and manually replace the '1' by '0'...So strange!! but it worked..
Originally Posted by gbradley
...The thing that surprised me was that the Clear error didn't go in and reset the bit, I had to reset it myself.
Originally Posted by NicolasP
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...

Originally Posted by alive15
Is it wise to create a rung that automatically updates that bit to 0 if we keep getting this error?
Originally Posted by rupej
...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...

Originally Posted by rupej
...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...

"A little nonsense now and then is relished by the wisest men".
  Reply With Quote
Unread August 13th, 2019, 07:29 AM   #17
Lifetime Supporting Member
United States

roxusa is offline
Join Date: Nov 2008
Location: NJ
Posts: 753
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.
if you are going to assume, assume you're wrong.
  Reply With Quote
Unread August 13th, 2019, 10:00 AM   #18
Lifetime Supporting Member
United States

gbradley is offline
gbradley's Avatar
Join Date: Apr 2002
Location: Corona, Ca.
Posts: 1,554
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.
  Reply With Quote
Unread September 6th, 2019, 04:10 AM   #19

bmn123 is offline
Join Date: Mar 2018
Location: Fimincio
Posts: 3
I had an emergency case open and I was waiting for a call back. But I was using Endpoint backup for a physical server and it failed. I brought in an ESXi host and restored the server as a VMDK to that ESXi host. When attaching the disk and booting the VM it doesn't find the hard disk looks for network boot and fails with an "Operating System not found" error. Thankfully, I was able to recover it thanks to DiskInternals VMFS Recovery: but it was a close call. It worth giving it a shot. It helped me to find out how to restore vmdk file.
  Reply With Quote
Jump to Live PLC Question and Answer Forum


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Micrologix retinative data lost micah123 LIVE PLC Questions And Answers 15 May 12th, 2017 10:40 AM
Devicenet Error Code 77 ganutenator LIVE PLC Questions And Answers 22 January 9th, 2014 08:43 AM
MPI comunication Manuel Raposo LIVE PLC Questions And Answers 22 July 16th, 2007 07:24 AM
Siemens MMC's & those damn actual values Mylo LIVE PLC Questions And Answers 55 March 23rd, 2005 04:49 AM
retentive data with compactlogix wnkook LIVE PLC Questions And Answers 2 July 25th, 2004 07:49 AM

All times are GMT -5. The time now is 06:24 PM.