AB SLC 500 OS/2 Communication - lost password

[aaa75]

Update -

Got a different CPU, that one seems to be working better, now I can connect via APS to the PLC and able to detect all the modules. The only problem - it won't recognize the CPU itself, despite it being same exact part, number, OS, you name it.

I'm suspecting it's the way I connect to it, from APS I have the choices:

DH485: 1747 PIC
Half duplex (slave)

Full duplex - this is where it detects everything, but the CPU.

I got these messages in various stages of connect attempts:
Warning: I/O module doesn't fit in the rack
Unsupported Processor
This programmer cannot support processor

Can anything be done in this situation?

Thanks!

 

[Ken Roach]

APS hasn't been updated in about 20 years or so, so it's very likely that the SLC controller's operating system is newer than APS can work with.

I know that you could use RSLogix 500 software and connect to the controller.

I realize you say that the part number and OS on the new controller are the same as the old one, but there were different Firmware Revisions within the same OS. OS301 FRN 5 is different from OS301 FRN 10, for example.

 

[aaa75]

Oh....

The processor numbers are exact same, OS FRN - was 6, now 8, everything else is same!

Is it possible to change that somehow? I really would like to be able to communicate with the PLC through the existing channel.

 

[aaa75]

Looks like these are the changes between the two releases:

• Selection of number of data bits and stop bits with generic ASCII communications added The Generic ASCII protocol has been expanded to allow 7 or 8 data bits and 1, 1.5, or 2 stop bits. Generic ASCII communications is selected when Channel 0 is placed into User Mode.
• Poll Time-out with DF1 Half-duplex Slave Communication The Poll Time-out feature associated with DF1 Half-duplex Slave communications on Channel 0 has been changed so that reply data packets queued to be transmitted when a Poll Time-out occurs will no longer be purged from the queue. The only event which will now purge the reply packets is reception of a NAK from the DF1 Master. This ensures that no matter how much time elapses between when a DF1 Master sends a command packet to the 5/03 and when the master polls that same 5/03, the reply to that command will be returned by that 5/03. Command data packets generated by MSG Instructions and which are queued and waiting for transmission will still be purged with their associated MSG Instruction being errored with the type 0005 code.
• Read of Initialized Data Files during download The 5/03 processor uses hardware to CRC data files. As a data byte is written, a CRC is generated in the next byte. When the data is read back from the processor, the CRC is automatically checked. If it fails, then a hardware error occurs and the processor resets. Therefore, by the way the CRC works, data cannot be read from the processor until it has been written. In one application, the user was continuously polling all of the processors for information by reading various data files. Since this polling could happen anytime, they were often colliding with a download procedure and causing processors to reset. A change was made in the firmware to not make use of the automatic CRC checking of data files during a download, thereby preventing this from happening.

I'm slightly confused - does that mean that I won't be able to use the new CPU with old PC?..

 

[Ken Roach]

It sounds like you found a "new" SLC-5/03 controller with OS301 FRN 8, which was released in April of 1995.

That's about the time that development was ending for APS. Allen-Bradley had bought ICOM Software and their AI-500 was a far better DOS product, and the fancy new RSLogix 500 software was coming on the market.

It's entirely possible that your controller is one or two firmware revisions too new to work with your revision of APS software. I can't find any revision histories for APS that will help us determine which SLC-5/03 controller firmware it will support.

My practical recommendation is to get a license for RSLogix 500 and run it on a modern Windows 7 computer. That will let you do your PLC editing on a modern platform and save your restoration efforts for the OS/2 based HMI.

 

[aaa75]

We are ordering the cable and looking at RSLogix licensing. Could there be an issue communicating with the HMI software? Or is the difference in firmware only influencing the APS handshakes?

Thank you for all the help!