Falting SLC 5/94

I have a weird situation with my SLC 5/04 processor. I had to edit a rung to split it into two rungs. After completing my edits while online, I verified the first rung and it went fine. I went to verify the second rung and it faulted out the PLC and wiped the program from the processor.

I have to download the program back to the processor after I make my changes offline and all works fine. Once power is cycled; however, the processor again faults out and wipes the program.

I have not changed anything besides splitting that code, and any other rungs edits I make, besides this one rung, are just fine and compile good.

Any ideas? I don't have Internet access with that computer so I can't supply the code until later tonight unfortunately.

Are you sure the program was wiped? Did you try to go online to see what the fault is?

Yes I am sure. When I look at the processor in RSLINX it says "Default" next to the processor and if I select "Online" it says I need to download a program to it.

I think I may have found it. I was using B3/368 as an output on the rung causing issues. I changed that to B3/120 and it stopped faulting out.

Any thoughts?

Well that didn't really fix it... Still looking for some help. Thanks.

We will have to see the program thats causing the fault.

Post when you can. Zip the file first.

Well after working on a couple more machines, I have determined it is not a code issue. It must be in my computer, or the program used to compile the program.

there's not nearly enough information here to nail this problem down – but here's a situation that we ran into during a student exercise the other day ...

we were downloading a simple program into an SLC-5/04 processor – and it did exactly what the OP has reported ... specifically, the processor was wiped out completely and went into the "default" name condition ...

we "think" that we figured out that the problem was related to an active DDE/OPC link between the processor and Excel ... the problem repeated itself multiple times – but once we turned off the DDE/OPC link, the problem never repeated itself again ...

suggestion:

make sure that nothing else is trying to communicate with the processor before you do a download ...

just for the record, all of the communication in our exercise involved using the Channel 0 port – RS232/DF1 ... specifically, we were not using DH+ in any way when the problem cropped up ...

my best guess (so far): maybe there was too much traffic (unrelated to the program download) on the communication link – which fouled up the download operation ...

If you are online via an ethernet WIFI router or multihopped network online edits can cause faults unless you limit the Max "Fast", Max "Slow", and Max "Unconnected" messaging connections in RSLinx under the Configure CIP Options pulldown in the communications menu.

I have found setting them to 1 and leaving them seems to make online edits more stable no matter how I am connected.