new 1756-L71: firmware installation not working

suraj2k

Member
S
Join Date
Nov 2012
Location
Calgary
Posts
12
I have a brand new out-of-the-box 1756-L71 series B ControlLogix controller. It comes with F/W version 1.010.1.
The controller is in Program Mode (using the keyswitch on the front)
I'm trying to use ControlFlash 11.00.00 to upgrade the firmware to ver 20.012.
The error I get is that the controller is not in the correct mode for upgrading the firmware.
The manual tells me that the controller must be in Program Mode or Remote Mode for f/w upgrade, which it is.

Any suggestions? Thanks! Much appreciated.
 
Are you connecting over USB or over Ethernet ?

Be sure that you're selecting the first instance of the 1756-L71 that you see in the RSLinx Classic/RSWho browse.

If you browse past the controller to the backplane then to the controller icon you see in the backplane object, you're essentially telling ControlFlash to run in a circle and it gets confused about placing the controller into a flash upgrade mode.
 
Ken Roach said:
If you browse past the controller to the backplane then to the controller icon you see in the backplane object, you're essentially telling ControlFlash to run in a circle and it gets confused about placing the controller into a flash upgrade mode.
Click to expand...

This causes much confusion to many who are unfamiliar with the set-up.

If RA want to show the connecting device on the backplane, (and they didn't used to in the early days) they should have shown it "greyed out", indicating that it is re-entrant. I believe that would remove a lot of confusion and misdirection.
 
Thanks a lot Ken Roach, that worked excellently! Previously, I was doing exactly what you said: I was drilling down to the backplane to the controller, which was failing.
 
I am having the same trouble upgrading my 1756-L61 controller firmware. I am using an ENBT card, and the RSLinx Classic/RSWho browse shows the controller in the backplane only. Should there be another instance of the controller in the path, perhaps under the workstation--> Linx Gateways, Ethernet directory?


The path I have is Workstation, HP-PC ----> AB_ETHIP-1_, Ethernet ----> 169.254.17.1 1756-EBNT/A - 1756-EBNT/A ---> Backplane ---> 00, 1756-L61 LOGIX5561
 
Welcome to the PLCTalk Forum community !

The original post mentioned an easy-to-confuse communication path because the 1756-L7x controllers have a USB port that makes it very convenient to flash the firmware, but also easy to confuse the communication path.

The 1756-L6x controllers have an RS-232 port. While it's also possible to confuse that communication path, it's less likely because most users don't connect using that port or attempt to use it for firmware loading (it's much slower than USB or Ethernet).

In your case, the path is correct: Driver, Network, ENBT address, backplane, Controller slot.

Make sure the controller is in PROG mode and that there is no CompactFlash card installed.
 
I tried it with the switch in both prog and remote positions. The transfer starts, runs slowly, usually times out before all blocks complete. sometimes all blocks complete, but even then I get an error message
 
I apologize for the delay in reply, I was just trying it "One More Time!" The message indicates "unknown communication error code"
 
Interesting !

In general if there's a configuration problem, the transfer won't start at all.

You could have a damaged controller, or a damaged backplane, or an unreliable network connection.

Because controllers generally fail their self-diagnostics instead of generating a bunch of recoverable errors, I would troubleshoot the Ethernet network first; replace the cable, try different switch ports, that sort of thing.
 
I bought this controller used, is it possible that I have a hardware issue? The OK light is always flashing, and every once in a while the battery light flashes red for a split-second. there are no other lights illuminated on the front of the controller
 
Before I tried the ethernet port, I tried to use the serial cable port, no joy there either. The download was super slow with the serial cable, never got more than 10% of the files downloaded before I got some kind of fault. The faults seemed to be kind of coincidental with the battery fault flash, but I had the same problem without a battery at all. The download will run without a battery, or at least the files will transfer without a battery. The battery voltage is 3.00 volts exactly. I did order another controller, which should arrive on Tuesday.
 
The battery light flickering is not normal. In general, it's OFF when the battery is in good condition, then latches on solid when the battery voltage drops below what will keep the RAM backed up. I've never seen a ControlLogix battery LED "flicker".


I just grabbed a 1756-L61 Series B controller off my test bench that's been sitting with a disconnected battery for months.

At startup, the OK LED comes on red for about ten seconds, then goes solid green at the same time that the BAT LED goes solid red. The other LEDs stay off.

You might have been sold a damaged controller. With the battery disconnected and no CF card loaded, you should see steady red BAT and steady green OK.

A flashing red OK LED indicates a minor fault, while a steady red OK LED indicates an unrecoverable major fault.
 
For firmware loading there's no reason to have the RAM backup battery, so disconnect it.

I just checked my blue-jacketed 1756-BA2 battery that the controller considers dead (solid red BAT LED when connected) and it's down to 3.12 volts. These are nominally 3.6V lithium batteries, so a cell that's down to 3.0 volts is good and dead.
 
I really appreciate your help with this!



I was evidently sold a damaged controller, as the OK light never was green.



I am pretty sure that the replacement card that I ordered, an 1757-L63, will have old firmware that needs to be upgraded. The people who sold me my serial cable made a video in which the narrator indicates that it is possible to "brick" the controller. Just how risky is the firmware upgrade?



Thanks Again
 
An undamaged 1756-L6x or -L7x has a very low risk of "bricking" the controller because they have enough memory to load and verify blocks of firmware without writing to nonvolatile memory live like some older controllers did.

In general you still don't want to interrupt power, or do the firmware download over a damaged or unreliable connection. I start my firmware upgrades then very carefully get up and go get a fresh cup of coffee, so I minimize the risk of snagging a cable or knocking over a computer. I'm... inelegant.
 

Similar Topics

E
1756-L71, 1756-RM2 and 1756-CNB firmware revision issue
Hello, Is there any issue in term of the firmware revision for all of these three devices to communicate with each other in one rack? I'm...
Replies
2
Views
4,262
epicnote
E
J
Adding Produced and Consumed Tags with redundant 1756-L71 controllers
Hello, I have a pair of redundant 1756-L71 controllers rev 24. These controllers currently have produced and consumed tag interfaces to 3 other...
Replies
2
Views
154
johnplatt55
J
R
1756-L1 to 1756-L71 migration
Hi All, We have a number of old discontinued 1756-L1 PLC systems that we are trying to support but recognize that we need to start preparing to...
Replies
5
Views
949
joseph_e2
J
M
Bricked 1756-L71
Two days ago I used Control Flash Plus to upgrade the firmware on a 1756-L71 controller from v20.13 to V35.12. The upgrade aborted soon after it...
Replies
8
Views
1,115
KuulKuum
KuulKuum
C
Messaging between Micro820 and a ControlLogix (1756 L71)
I have followed several videos and tutorials that suggest when using the MSG function to enter 2,xxx.xxx.xxx in the Path box in order to connect...
Replies
11
Views
1,368
Ckoch
C
Back
Top Bottom