AB Charging to fix "bricked" CLX

Anyone run into this? Had a CLX get bricked during a flash upgrade and our distributor said AB wanted $1,300 to fix it. Our PLC contact from that distributor was here this morning, and after much razzing, he went out to his car and brought us in a brand new CLX. But he stood by the story that AB is charging to fix them.

I can only remember one other bricked CLX, and that has been several years ago, but it seemed like they fixed it for free. I searched the forums here and didn't run across anyone else mentioning a charge for this.

It seems like they SHOULD fix it for free, since they apparently can't make a robust flash upgrade process.

I can't speak to the issue of charging, but as far as flashing goes, the flash capability is only as "robust" as your comm connection.

For example, you should really never flash using ethernet. Ethernet is the least robust and most likely to cause a "bricked" system.

What should you use? Serial, point-to-point. It will be the most reliable connection. It doesn't need power and no one else can disconnect you.

But who actually uses serial? Hardly anyone due to the speed. Who uses ethernet? Most everyone I would assume, again due to speed.

I saw a post on here in the past couple days where someone was telling a poster that they shouldn't flash using serial but they should use ethernet. If time is your only concern, then have at it, but you really want to ensure a reliable connection, it isn't the way to go.

OG

If this is a new processor or under warranty then it should not be charge as far as I know.

If processor is out of warranty - this is a normal repair cost.

L6x processors have fixed bootloader that allow recovery.

Regarding 'bricked' CPUs (and I was the one who was advised to only use Ethernet because of the longer timeframe to update using serial gave more opportunity for a power glitch to occur) why isn't the program which supports the 'firmware upgrade' in its own ROM? The system should start up in this ROM, check the integrity of the 'firmware' then jump to it if OK. Else it should stay in the ROM code and await a command to download firmware. The code in the ROM would be the '1.1??' level. That way if some power glitch does hit the worst thing that happens is you start over again. I like upgradable firmware but the upgrading code should not be part of the upgrade.

They could even have two levels of upgrade code, an incredibly basic one which resides in a minimal ROM (possibly only supporting the serial port). It's only purpose would be as a 'bootstrap' to download more powerful upgrading code into the flash. Once that was done the upgrade process could jump to that new upgraded code (which could possibly support Ethernet upgrading). Thus you would never have a brick as probably only the high level firmware would be the target of a change.

I'm thinking here of the early microprocessor CPU board with the 'monitor/debugger' in ROM and which would be the first code called. It then supported downloading of a program or other functions. The 'monitor/debugger' was not the object of any downloading.

I agree with Bernie

I have to agree with Bernie. I just don't understand how AB can have a product that can be bricked in the first place???
The core operating system of the CPU or of some other smart module needs to be non-brickable. I have managed to brick out few modules myself and know how frustrating this can be. The worst part is that it isn't just the CPU's that can be bricked out it's all the modules!
I have worked with bunch of different embedded systems but I have never seen one that could be bricked without some sort of recovery procedure. The download code required to move the data in to the module is undoubtadly not changing, why should it, it's probably an Intel HEX or a Motorola S format, so why not have a secure and protected memory area that holds this code?
I just don't get this anymore than I get the idea of introducing a new pvserv.exe driver for Ultra5000 and not having any version control on it, DUH!
Maybe if you buy a tech connect for thousnads of Dollars they will not charge you for un-bricking your module?
Man how far is AB willing to go?

I have heard of many terms before, but, I don't ever recall hearing the term "bricked"

What causes a PLC to be "bricked"?

You had talked about it occurring during a flash upgrade.

You can "brick" only L1 and L55 PLCs. These PLCs were designed well over 10 years ago.
All new PLCs using bootloader that prevents bricks.
There is no reason to buy L55 any longer. L1 is discontinued while ago.
L6x is way to go.

Stephen Luft said:

I have heard of many terms before, but, I don't ever recall hearing the term "bricked"

What causes a PLC to be "bricked"?

You had talked about it occurring during a flash upgrade.

Click to expand...

On L1 and L55 CLX plcs, when upgrading firmware in flash memory, if you have a communications or power failure then the PLC turns into a brick - a hunk of worthless plastic and copper. There is no way to go back to the beginning and start over on the firmware upgrade.

<Quote from Jiri > ..... have worked with bunch of different embedded systems but I have never seen one that could be bricked without some sort of recovery procedure......

Jiri, I have a bunch of computer motherboards I have had to throw out from big name companies (Dell, ASUS....) that have had this same problem.

Upgrade the BIOS, something flakes out and wha la...a bouncing baby brick!

OG

I have worked with bunch of different embedded systems but I have never seen one that could be bricked without some sort of recovery procedure.

Click to expand...

All processors can be unbricked, but not by the customer as it require software tools, that's why processor should be sent for repair.

slight tangent here....

Jiri, I have a bunch of computer motherboards I have had to throw out from big name companies (Dell, ASUS....) that have had this same problem.

Upgrade the BIOS, something flakes out and wha la...a bouncing baby brick!

Click to expand...

At least with the ABIT card I was playing with a couple of months ago...
You can't do anything to FIX the bricked bios chip, but they were perfectly willing to mail you a replacement chip with the correct bios loaded in it for a $6 handling fee and whatever the shipping costs were.

To Stephen Luft - in case you haven't figured it out from the discussion so far, the upgrading of firmware on a Logix processor (and it's always necessary at least once, the new processor comes with just enough smarts to accept a firmware upload) programms the whole flash memory, the code receiving software being temporarly resident in RAM having been loaded from, you guessed it, the flash ram which is now being erased and overwritten. If this process screws up in mid upgrade (power glitch, comms loss whatever) you end up with a CPU about as useful as a 'brick'. Maybe good for holding down papers on a desktop but, until repaired by AB, not much else. Thus my remarks.

What is needed is a debugger with a JTAG interface. This is what we use and I am pretty sure that is what Rockwell uses on the CLX PLCs. I know they use the JTAG on the motion modules. The JTAG interface allows one to load code directly into the CPU without the need of a boot loader. As stated above, the PLCs with boot loaders that are never erased can always be recovered barring any other problems.

I am not suggesting that everyone goes out and buys their own downloader. I just want to let everyone know that the PLC is not really being repaired, it is just being reprogrammed.

Bernie,

Thanks for offering an explanation.

Jiri, I have a bunch of computer motherboards I have had to throw out from big name companies (Dell, ASUS....) that have had this same problem.

Upgrade the BIOS, something flakes out and wha la...a bouncing baby brick!

Click to expand...

Hello Tom,
I was referring to an embedded system such as NetBurner (great system it will never brick out), Rabbit, Tiny from Dallas Semi etc.
These systems are bullet proof. You are talking about PC mother boards, a little different scenario.


Another bricking story:
About 4 years ago I had a 1756-DNB module that was about 2 years old (definitelly less than 10 years old!!!)
I needed to re-flash it to the latest of that time. I got the latest Control Flash files, read the Readme.txt file on how to do it and proceeded with the re-flash. I managed to brick it.
By re-tracing my steps I figured out that the readme file had WRONG INSTRUCTIONS that caused me to brick out the module.
I called AB's tech support and after 2 days of arguing with various people and trying to explain in detail where the problem was I finally managed to get a new module sent to me.
Tech person I was talking to was very unreceptive to what I was telling him (or so I thought), he told me that there was nothing wrong with the instructions. To my amazement couple of days later I got an official e-mail informing me that AB has discovered an error in their re-flashing instructions. The same guy used my input to make himself look good and could not even say thanks.
Nowadays to get this guy on the phone so that you can help him de-bug their own system will cost you large tech connect fees.

While it may be true that the new CL CPU's and modules can't be bricked, you need to keep in mind that there are many legacy systems around. I think that the CL modules of 6 years ago were
still brickable and 6 years in terms of an automation system is not a long time. If you have a large system including legacy modules you should always exercise extreme caution when re-flashing (have a spare on hand).
Re-flashing via an RS-232 as was mentioned earlier would be preferable, however on a large installation it will also be very unproductive if you have to walk to each individual CPU.

I also think that AB's blanket tech connect fees are badly conceived.
While I am not arguing that there are many people who would abuse the tech support by not reading the manuals or not having enough brain power to comprehend the material you need to look at the other side of the issue.
There are many experienced people who call tech connect only when
they experience issues beyond their control, i.e. lack of information, inaccurate information, issues with bugs etc.
These people are in fact helping AB!
There should be some sort of "pay according to the type of help you need" system. This blanket system where everyone pays the same is not right!