1756-L61 Dumping program

curlyandshemp

Lifetime Supporting Member
curlyandshemp
Join Date
Jul 2005
Location
Toronto
Posts
1,903
Anyone ever see a 1756-L61 dump its program when switched from prog to run?
I was on site today and replace a L61 CPU with a good known working one. When I loaded mt V17 app into the good L61, program was wiped out when i placed PAC from prog to run.

This occured 3 times, so I knew something was up.

Upgraded PAC from V17 to V18 and dowloaded the app again, then no problem going from prog to run
 
If you had a CompactFlash card installed during the User Program Clear events, then the controller probably wrote a record of the fault code each time.

ControlLogix family controllers don't "lose" or "dump" the user program, though it's easy to think of it that way. They intentionally delete the User Program if the controller operating system decides that the user program is corrupt. Sometimes it's right; a voltage spike or other event has corrupted the RAM image. Sometimes it's wrong, like in the infamous v15 CRC miscalculation bug.

Was the OK LED flashing red, or solid red ? If Flashing red, the controller OS was still in control and there was useful information in the fault record (in RAM or on the CF card). If solid red, the boot code portion of the OS was in charge and there may or may not be useful information recorded on the CF card. Since you've installed a new OS, any 'crash logs' kept by the v17 operating system are gone from controller memory, but not from removable CompactFlash.

If I were experimenting, I would save the v17 program as a *.L5K then open that file in RSLogix 5000 to re-build the *.ACD file from its component elements, then try to download/compile and run that program.
 
Ken Roach said:
If you had a CompactFlash card installed during the User Program Clear events, then the controller probably wrote a record of the fault code each time.

ControlLogix family controllers don't "lose" or "dump" the user program, though it's easy to think of it that way. They intentionally delete the User Program if the controller operating system decides that the user program is corrupt. Sometimes it's right; a voltage spike or other event has corrupted the RAM image. Sometimes it's wrong, like in the infamous v15 CRC miscalculation bug.

Was the OK LED flashing red, or solid red ? If Flashing red, the controller OS was still in control and there was useful information in the fault record (in RAM or on the CF card). If solid red, the boot code portion of the OS was in charge and there may or may not be useful information recorded on the CF card. Since you've installed a new OS, any 'crash logs' kept by the v17 operating system are gone from controller memory, but not from removable CompactFlash.

If I were experimenting, I would save the v17 program as a *.L5K then open that file in RSLogix 5000 to re-build the *.ACD file from its component elements, then try to download/compile and run that program.
Click to expand...

Ken,

red LED was flashing and this was the fault in the PAC

ScreenHunter_01 May. 15 08.34.gif
 
Darn. Type 01 Code 60 is the catch-all "this code isn't identified yet" code. The only way for RA Tech Support to analyze it is to also get "crash dump" data that's written to RAM or to the CF card.

Since you've upgraded the controller firmware, the RAM copy was cleared, so unless you had a CF card in place, this is water under the bridge.
 
We use a 1769-L23E on a machine we manufacture.

We were having the same problem. The Fault only occurs on Power up and its not consistent.

We contacted Rockwell and this is a know "anomaly". They have discovered this fault and hence released further firmware updates.

We are currently using V19 and haven't had the problem come back yet. We updated ... aprox 5 months ago. Hoping the problem never comes back.
 
Ken Roach said:
Darn. Type 01 Code 60 is the catch-all "this code isn't identified yet" code. The only way for RA Tech Support to analyze it is to also get "crash dump" data that's written to RAM or to the CF card.

Since you've upgraded the controller firmware, the RAM copy was cleared, so unless you had a CF card in place, this is water under the bridge.
Click to expand...

Can a CF be installed and removed while the processor is running?

This application is a 24/7 operation.
 
Why you always have problems on weekends? :)
I recall last time it happened Saturday night?

Unfortunately this utility will not do anything since you already flashed PLC and all debug data lost.
I guess you were in hurry to flash it, should ask here first.

It will be much better to install CF card instead of FDU, CF card will have more details and you don't have to use serial port.
You can install CF while PLC is running.
 
Can you post your v17 program? Along with exact firmware rev. you had.
I can load it to my PLC to see if I can duplicate it.
Or just email program back to Rockwell to do the same.
 
Contr_Conn said:
Why you always have problems on weekends? :)
I recall last time it happened Saturday night?

Unfortunately this utility will not do anything since you already flashed PLC and all debug data lost.
I guess you were in hurry to flash it, should ask here first.

It will be much better to install CF card instead of FDU, CF card will have more details and you don't have to use serial port.
You can install CF while PLC is running.
Click to expand...

Always the case. Murphy's law.
What i discovered our panels are power by 120 VAC. The 120 in the building is not on a generator as of yet. All the other services panels and machinery operate on 600VAC and generate their own 120 vac. The 600VAC is protected by generator.
This is why our PLCs were the only ones to cycle during power blips
 
Since you must keep the system running 24/7, then upgrading the firmware will probably have to be scheduled. I wonder if the RSLinx Enterprise patches do any harm if those are performed first?

WIth that on the backburner, how about designating one of the three programmers to have ownership of all edits that involve adding/deleting tags, and schedule your online edit accept, test, and edits on mutually exclusive intervals to give the CPU time to handle that extra load. I think incremental online edits are more harmful to CPU rsources than larger planned ones. Can you perhaps develop program changes offline, then drag and drop new programs into a running PAC (with a unique strategized name) and then schedule them while running to swap in place of other routines? Would that help with the fragmentation of CPU resources?

I dunno, just a thought. But if you take the system down or it faults, I would at least take that opportunity by having a freshly compiled latest and greatest program ready to download, and burn to CF card. That should help clean up fragmented memory due to online editing and should only take a couple of minutes tops.

It could open up the dilemna of capturing real live running process values, but if the system crashes don't you lose that anyway?
 

Similar Topics

J
1756-L61 dumping its program
We have a 1756-L61 that dumps its program as soon as we enable a particular MSG. Sometimes it does it immediately, sometimes not for a couple of...
Replies
3
Views
2,469
jgreen2009
J
A
Upgrading from 1756-L61 to 1756-L71
Hi All, I'm trying to upgrade from 1756-L61 to 1756-L71 but I keep getting an error 25299-0. Is there anything that need to be complete to be...
Replies
3
Views
1,842
Ken Roach
Ken Roach
A
Low battery LED lit while battery is ok of AB 1756-L61
Hi; I am experiencing a problem with AB 1756-L61 controller that it doesn't retain the program while battery is connected. I have found that...
Replies
5
Views
2,783
parky
P
N
controllogix 1756-l61 firmware update
hello i had a 1756-l61 with firmware ver 13.24. a solid red made the processor not functioning. i ordered a processor that came with firmware ver...
Replies
13
Views
3,834
nmk34
N
A
1756-L61 PLC Firmware upgrade issue
Hi, we are using 1756-L61 PLC redundant system in one location . due to some minor faults , we upgrade the firmware from 19.52 to 20.58. after...
Replies
1
Views
1,343
collinsd70
C
Back
Top Bottom