SLC 5/04 comms.... again

Hi all,

The gurus on this forum have helped me indirectly many times for which I am forever grateful, but now I feel the need to ask my own question.

Sorry to start a new 5/04 comms thread as I know there a plenty of them. Problem is I haven't found one that helps much with my problem.

I've come across a processor with a fault that won't reset and I'm unable to get online to it through the RS232 port to see what the problem is. Going online through the DH+ isn't really an option as I don't have all the required equipment and The Boss is very reluctant to stump up with cash for something we'll probably never use again (5/03s and 5/05s are our usual poison).

I have an offline copy of the code which shows the channel 0 setup:

Driver: DF1 full duplex
Source ID: 9
Baud: 9600
Parity: None
Stop Bits: 1
Control Line: No Handshaking
Error Detection: BCC

I have a 1747-CP3 cable and a laptop with a built in serial port (com1). The RS232 DF1 driver in RSLinx fails to autoconfig (check cables, etc...) so I manually entered the settings:

Baud: 9600
Station Number: 00
Parity: None
Error: BCC
Stop Bits: 1
Protocol: Full Duplex

The PLC is then refuses to show itself, which I find rather rude. I know there is no problem with the cable.

The customer suggested replacing the processor with a new one but I'm reluctant to do this because the fault may not be with the processor.

Any help is greatly appreciated and I shall sacrifice a kiwifruit to the deity of your choosing if you can help me sort this one out.

Are you sure that there is nothing else trying to use the comm port on your PC?

Are you absolutely sure the offline file is correct? And is a up to date program
file. If so then you might try resetting the processor to its default condition,
by removing the battery then short out VBB to GND. ( only do this if you are certain you have a good backup and the PLC is not working anyway)

9600 baud rate is not the default rate. Is there anything connected to the processors serial port?

The FLT LED is important; if it is flashing red, that's a recoverable fault. If it's solid red, it's an unrecoverable fault and you won't be able to get communication established in any way.

The usual way to perform a full reset is to disconnect the battery and short out the Vbb and GND pads on the back side of the main board. This is described in detail on page 161 and 162 of the SLC-500 Modular Hardware Style User Manual, publication 1747-UM011.

If the LED stays solid red after you've drained the capacitor, replace the controller.

Thanks for the replies guys,

There is definately nothing else using the port on my laptop as I'm able to connect to a couple of other PLCs we have lying around using the same setup. The program was sent to my customer by the OEM so I'm reasonably confident that its all good. I don't know if something is connected to the port because the machine is out of town and they've just brought me the PLC to have a look at (chassis and all).

The fault LED is on continuous so I gave up and got a new processor. When I downloaded the program I was kicked offline because of the setup change and now I can't get back online just like before. I've put the processor into run with the keyswitch and the fault hasn't come back so I'm going to assume that everything is fine and get them to put it back in and try it. I'll try the full reset on the old processor later and see what happens.

I can only assume there's some crazy stuff going on in the logic that is preventing me from touching it. I'll have to investigate that when I've fot a few spare seconds later. There is a Prosoft MVI46 communication card in one of the slots, could this be causing some sort of issue?

Try one little test if you get a chance.

In the DF1 Full Duplex driver, select "1770-KF2/1785-KE" as the Device Type, and try browsing through the serial port again.

If you just downloaded to the controller, and the serial port configuration isn't set up for DH485 or Modbus or ASCII, you should absolutely be able to get back online. The complication I'm thinking of is if (1) the DF1/DH+ passthrough feature is enabled, (2) the SLC-5/04 DH+ node number is not Node 1, and (3) the DH+ port isn't connected to a network.

I'm thinking that if the DF1/DH+ passthrough feature is set up that the driver will send a command to Node 1, and the SLC will dutifully try to pass that through to DH+ Node 1, instead of responding to any destination node number, as it will when it's normally set up for DF1 Full Duplex Point-To-Point.

Doublecheck also the CRC vs. BCC error checking. CRC is both default and typical in SLC-500 systems.

Can you post the program file? (.RSS file , zip it first)

Mickey said:

Can you post the program file? (.RSS file , zip it first)

Click to expand...

I'm not sure that I should as its owned by the OEM and is passworded. They also made me sign over my first born child before they would send me a copy.

If what I've done gets the thing going again I'll quite happily forget about the whole thing and go back to a state of blissfull ignorance. Otherwise I'll see about posting something.

Thanks heaps guys

Just had a quick look through the program. It would seem that there is definately supposed to be something plugged in to the RS232 port and there is some programming doing an ASCII read and write through the port. I'm not really all that well versed on this sort of thing but I would assume that is what is causing the issue. I guess they only intended for any programming to be done over the DH+.

If the port is set up for ASCII protocol then that would explain it. Look at channel 0's configuration to be sure. If the mode says user then it is ASCII.