AB SLC 500 OS/2 Communication - lost password

Hi everybody,

We are repairing a stretch-forming machine that we bought heavily used and seriously dismembered. It has a HP computer running OS/2 Warp 3 as a programming HMI and AlanBradley SLC 500 PLC with some 40+ I/O modules. The previous owner of the machine is out of business for 8 years already.

The problem I'm facing currently is - to connect PC to PLC the software requires a password, and no one knows what it is. Software under OS/2 is DeMott custom stretch forming interface. They are willing to "start looking at it without any guarantees of success" for a substantial sum of money, which we, being already hit hard by purchase of the machine and several months of working on it, would prefer not paying, especially if it may be a dead end.

So the question is - is there any way of recovering that password? I'm unfamiliar with OS/2, AB PLCs, but hope to get some advice that will help us solve this.

Thank you!

Password recovery or bypassing is sort of a taboo topic on this Forum, but yours is an unusual situation.

Is this password appearing on the OS/2 computer, in the custom software ?

Or are you asking about connecting the general-purpose RSLogix 500 programming software from Rockwell Automation to the SLC-5/02 controller, and seeing a request for a password there ?

It's often possible to "hack" the pasword on an old SLC-500 controller but the specifics are not discussed here in public.

As for an old OS/2 system... I don't think your management could possibly have put any value on that software, knowing how old it is and that the OEM is out of business. If it were me, I wouldn't even start.

Thanks for reply, Ken.

I was asking about the connecting via machine's computer interface (run on OS/2 PC) to PLC RS232 port. This software is the only way to set up the machine and communicate with it, so I think the OS/2 stays for now.

While looking for an answer to this, I have figured another problem we'll most likely face: the battery is dead and memory module was never there - does that mean that we don't have the program on the PLC at all? Then we'll have to contact the manufacturer in any case..

The old SLC-500 controllers without a battery or EEPROM module could hold the program for a week or two. If this system has been powered down for months or years without a battery, the odds are very good that the program is gone.

Do you know exactly which part number of SLC-500 controller you have ?

Do any of the LEDs on the controller light up when you power it on ?

The part number of SLC 5/03 - 1747-L532 C 1M, OS - 1747-OS301 a 6.

The FAULT light is steady red, FORCE and DH485 is toggled with FROCE, DH485, BATT and RS232.

The machine was down for several years...

Ouch.

That's not just a faulted controller, but rather one that's been damaged and is failing its power-up self-test.

First, remove the controller and check the position of the J4 jumper on the main board. It should be on pins 1 and 2, the "Protect" position.

If that doesn't get the controller back to a flashing red FAULT LED, then you can try to clear the user memory by shorting the Vdd/GND solder pads on the back of the controller board (there are lots of hints on this on the Forum and in the User Manual) for about a minute.

Never remove or insert an SLC module under power; always remove chassis power before plugging or unplugging SLC controllers and I/O modules.

Oh gods... I knew I'm up for some exciting times, but didn't think it'd be that much fun. Thank you, Ken!

The jumper was at 2-3, I moved it and nothing changed, will try to do master clear tomorrow. Looks like we will absolutely have to order in a tech from OEM.

aaa75 said:

It has a HP computer running OS/2 Warp 3 as a programming HMI [..]

Click to expand...

Programming or HMI ? Two different things.
Was there ever a programming software for SLC500 under OS/2, or does it run APT in a DOS BOX ?

aaa75 said:

to connect PC to PLC the software requires a password, and no one knows what it is.

Click to expand...

You didnt answer the question exactly where the password appear.

What I am thinking, if there is a programming software on the PC, then there is probably also a program backup on this PC. You must locate and get the backup off the PC so you have a chance of migrating the program to something newer. Without the program backup you may have to write a new program from scratch.

Jesper, you're right.. Looks like it's both, program in OS/2 partition is used as HMI and MS-DOS for programming.

The password appears in the HMI program, when I try to connect to PLC.

DOS partition failed to load.. I'm frustrated... I have files from the old hard drive, but seems to me that reloading the program to another PLC is a bigger piece than I could swallow, at the moment at least...

Gentlemen,

I replaced the battery, shorted the Vcc/GND points, made sure the jumper is where it should be and still get the same flashing sequence. Would that mean that the PLC can be declared irreparable? Do I need the new processor module? Can it be a problem with power supply (we have 3 blocks, all PS lights are lit and all I/O blocks seem to be functioning)?

I am in talks with the manufacturer of that machine, hopefully he can provide the ladder program.

Thank you for your help!

If the fault light is steady on solid red as you indicated earlier, then the processor module has probably failed and needs to be replaced. If the Fault light is now flashing then you may yet be able to get it working. Be sure you have the battery disconnected/removed before you short Vcc to GND points for at least 60 seconds or even longer if you have the time.

Thanks for reply, I did remove the battery when shorting those.

Just got off the phone with a local automation professional, he says that this error happens when the PLC loses memory (OS and ladder program) and until we upload the program it wouldn't know how to wake up.

He also says that instead of using the 1747 UIC module we can get a USB to RS232 adapter and update a DB9 cable to suit the DH485 standard, sounds like blasphemy after reading this, but has anyone had success with that?

I'll be charitable and suggest that your local automation provider may not be experienced with the SLC-5/03 controller.

It's very difficult to physically corrupt the operating system firmware in an SLC-5/03 controller without also causing unrepairable damage to the controller. Heck, lightning strikes usually only cause loss of the User Program.

The operating system firmware can only be loaded using an EEPROM module. That 'Protect' jumper is part of the process, which is why it was my guess that maybe the controller had been interrupted during an upgrade attempt. That's one of the few ways to corrupt the OS.

SLC-5/03 firmware cannot be downloaded through one of the communication ports.

A general-purpose USB/RS232 converter can be used with the SLC-5/03 to connect to Channel 0 when it is in the default DF1 Full Duplex protocol mode.

But you cannot use a general-purpose USB/RS232 converter with a RS-232/RS485 converter of any type to connect using DH485 protocol. That includes connecting to the DH485 network port on the SLC-5/03, or connecting nto the Channel 0 serial port when it is configured for DH485 protocol.

Hi again,

A quick update - got the password for HMI, got the APS working (DOS within OS/2), got PLC .rss program, started creating processor files.

Please confirm my assumption - I do not need the 1747 PIC if I'm using the DB9 port on the 5/03 controller? Here's excerpt from the manual:

"If you are using an SLC 5/03, SLC 5/04, or SLC 5/05 processor, you do
not need the 1747-PIC interface. You can program via the RS-232
channel using DF1 full-duplex protocol or DH485 protocol and RS-232
program cable (catalog number 1747-CP3)."

Any other advice regarding reviving this machine is appreciated!

P.S. had to write this three times, "token expired" message and text disappearing completely was pretty saddening.

Yes, you should be able to program the PLC, if you are using the RS232 serial port from your computer to the 9-pin serial port on the PLC.