1756-L55 upgrade

Hello all,

First off just want to say thanks for all the tips I've received from this site. Very helpful in times of the good ol' google search for a PLC rookie. I've been reading these forums for a few years now and decided to register as I'm not having much luck with the current venture we are on.

We currently have a machine with a l55 processor v16.3. 3 times in the past 6 months while the line is running fine we were told that the PLC faulted out and cleared the program. Unfortunately this happened during off shift and our technician did not connect to PLC to look for faults prior to reloading program??? after 1st time we installed new battery. Each time the battery fault was on and a new battery was installed. Fault was never recorded. Sorry...

has anyone heard of similar issues with an L55??

Long story short boss man wants a l72 processor installed.
Any recommended versions to go along with the l72?? I've heard version 29 isn't very reliable??
Any programming issues to look out for??


A few years back we had similar issue with an L55 and replaced it with an l62 and had the line down for 2 days as our PID loops were no longer working properly. After several attempts troubleshooting with rockwell one particular engineer let us know it was a problem with our scan time.

Compatibility chart on rockwell's website indicates there are no known issues or dependencies

Just trying to get my ducks in a row prior to the upgrade.

If you need some more information please ask.

Thank you for the help

We had 3 L55 , fortunately they never had any problem only aging (weather and relative humidity down here are terrible). We replaced the with L71 almost 3 years ago (V30) with no problem at all.

I have had 2 similar issues, one a L55 & another a newer CPU.

Both were wiping their program with a good battery.

Both were solved by replacing the rack power supply. Somehow it was either giving dirty power to the rack, or at powerdown was draining the CPU battery power and wiping it.

Neither have done this since replacing the power supplies.

Also - on the L55 I put in the CF flash card & put the program on it, set it to read on error only, and at powerup if the memory is corrupted or wiped it will read the program and run. This will have the program, but if any setpoints or recipes were modified those would be reverted to the original values.

Generally if a program becomes corrupted, the controllers will wipe the unsafe program and present a Major Non-Recoverable fault.

I believe that the L55 could not store a fault log if the program has been corrupted. Once the program was wiped there was no fault code available to tell you what happened.

I'm with Aabeck that it is probably a power issue not a controller issue. But moving from a now obsolete controller to a more current controller isn't a bad idea. But that might be solving a problem that doesn't exist.

I'd take a look at the incoming power and see if maybe that is the issue.

OG

Welcome to the participation side of the PLCTalk community !

I've got a handful of comments:

1. If your controller served for years and only recently started failing, firmware or manufacturing defects are probable not the issue. Actual failed equipment might be; hardware does fail over time.

2. The 1756-L55 had a few months of production in 2007 or so where the backplane chips had a very high failure rate (like 2%). Most of those were identified and remanufactured or destroyed years ago, but it's like that some still lurk in storerooms or aftermarket.

3. Version 16 had a few bugs, and a lot of changes/improvements and new features. You probably have 16.003, and version 16.023 is the current release.

4. I've worked on systems where CPU upgrades (usually PLC5 -> Logix) resulted in horrible PID tuning problems. These are systems where the PID was programmed wrong, so that it ran based scan rates, not on an actual clock. It wasn't really the CPU's fault for running faster, it was the programmer's fault for not using the control system's clock properly.

5. The problem is very likely a failed battery backup circuit combined with possible power interruptions. If the BAT LED is on, and the memory is cleared, and fresh batteries only last a few months, then CPU replacement is probably the right choice.

Ken Roach said:

4. I've worked on systems where CPU upgrades (usually PLC5 -> Logix) resulted in horrible PID tuning problems. These are systems where the PID was programmed wrong, so that it ran based scan rates, not on an actual clock. It wasn't really the CPU's fault for running faster, it was the programmer's fault for not using the control system's clock properly.

Click to expand...

+1 to this. It amazes me how often I come across PID instructions not properly timed. It's not just a problem for when you upgrade your processor, it means your PID loop will get mroe and more unstable every time you change the logic in your PLC, as each change very slightly affects the scan time.

If you have any PID instructions in your program that aren't being executed on a timed basis as they should be, you'll definitely need to account for that in your migration. The quick-and-dirty way is, before the upgrade, check how fast your task is being executed. Then, after migrating to the newer faster processor, place the PID instruction in a periodic task that executes at about the same rate.

Of course, when I say quick-and-dirty, I really mean it. I'd be less than impressed to find that in my system. You'll have a PID configured to be scanned at x milliseconds, but it's actually being scanned at y millisecond, and it only works because the tuning values are incorrect directly in relation to the incorrect scan rate. It'll work, but it's ugly. Just last month I went through the process of re-calculating tuning values so that they worked correctly once the scan time was correctly configured. If you're interested in going down that path, this thread and this thread might be of interest to you

packman said:

Long story short boss man wants a l72 processor installed.

Any recommended versions to go along with the l72?? I've heard version 29 isn't very reliable??

Click to expand...

I disagree that v29 isn't reliable. My company used it as our standard version for a good couple of years with zero version-related issues and pretty much zero software crashes. We only moved on to v32 recently because the newer 1756-L8 and 5069 safety processors required a newer version.

Thank you all for the input. We were suspecting incoming power possibly. Forgot to mention in first post that we are installing new power supply as well.

1. If your controller served for years and only recently started failing, firmware or manufacturing defects are probable not the issue. Actual failed equipment might be; hardware does fail over time.. --->>Assuming you mean hardware as in possible chassis/power supply issue??....Is it recomended to have a UPS inline of the PLC?

2. The 1756-L55 had a few months of production in 2007 or so where the backplane chips had a very high failure rate (like 2%). Most of those were identified and remanufactured or destroyed years ago, but it's like that some still lurk in storerooms or aftermarket.

3. Version 16 had a few bugs, and a lot of changes/improvements and new features. You probably have 16.003, and version 16.023 is the current release.

4. I've worked on systems where CPU upgrades (usually PLC5 -> Logix) resulted in horrible PID tuning problems. These are systems where the PID was programmed wrong, so that it ran based scan rates, not on an actual clock. It wasn't really the CPU's fault for running faster, it was the programmer's fault for not using the control system's clock properly. --->>> Maybe a stupid question but I'm not good with PID Loops. How do I tell if its ran off scan rate instead of actual clock??

I've wrote about 10 PID loops for air control with a flow sensor controlling electric actuators. I have them working but really struggled on fine tunning them to keep the valve somewhat stable. KP is at 2.0, KI @ .15 KD @1.0..... Deadband is at 2.0. Measuring SCFM. My valve constantly overtravels +/- around5 scfm which is acceptable. This might be for another thread. SOrry

5. The problem is very likely a failed battery backup circuit combined with possible power interruptions. If the BAT LED is on, and the memory is cleared, and fresh batteries only last a few months, then CPU replacement is probably the right choice.

In regards to V29 I will try and gather some more information to share on what issues we ran into. This was another techs task with our compressor system

ASF

Forgot to ask how do I check how fast the task is being executed

You can view scan times by right-clicking on any task in the Controller Organizer and selecting properties. You'll see a tab on the far right, I think it is called Monitor. It will show the last scan time which will be changing, and it will show the Max scan time.

The default name of the Continuous task is MainTask. Although it could have been changed. The scan time of the Continuous is your overall scan time. If you have other tasks, you can view those as well. You can also view scan times for Programs but not Routines.

And my comment on power was really targeted at incoming power, not the power supply itself. A UPS would help as long as it is conditioning the power, not just providing backup.

However, I missed that the battery fault light was on. That leads me back to the controller itself being the problem. As Ken mentioned, the v16 firmware had some issues. It might be worth moving to a newer v16 firmware version.

OG

Also check your Chassis ground. Proper grounding of the chassis corrected our issue of program loss on a L55.

How do I tell if its ran off scan rate instead of actual clock??

Click to expand...

I will try to keep this simple, at the risk of not being comprehensive.

First, clarify if you're using the ordinary error-based PID (in relay ladder logic) or the rate-of-change based Enhanced PID (PIDE, in function block).

The PIDE function block generally runs in "Periodic Mode" and adopts its loop update time from the task that is executing it, so that's a separate discussion.

The ordinary PID instruction performs its calculation every time the rung is executed.

The classic mistake is to put the PID on an unconditional rung in a continuously executed routine (in a Program that is executed by the Continuous Task), and to enter the approximate scantime of the controller as the loop update time.

That can be made to work, of course, but if the scantime changes (a faster CPU, or more or less logic in the program) the PID will function differently.

In your system, just go search out every PID instruction and look at the rung pre-conditions. If it's being executed off a .DN bit on a timer, go examine the timer and compare its Preset to the Loop Update Time.

If it's being executed unconditionally on the rung, then examine the Routine and the Program and the Task to see if it's being executed periodically in some other way (usually a Periodic Task, in ControlLogix).

packman said:

....Is it recomended to have a UPS inline of the PLC?

Click to expand...

I have built panels with the PLC powered by a UPS.

It wasn't for the power conditioning (for that I use line conditioners) but the PLC needed to know if the main power went off and for how long, also if the hydraulic pressure dropped in a press, or the temperatures dropped too much.

If the power came back on within 30 minutes and the pressure and temperatures were OK then it would continue the cycle, otherwise it would abort and the product in the press would be scrap.