ML1K Fault code

[stvsas]

Hello all, It's been a while since I've been here or involved with PLC's. My old company complains that a ML1K dies on "fault" about 3 times a week. They have to clear the fault and download the program and all is well.......for a while ...until it happens again. S6 equals 5h. Does anyone know what that means?
Also, i want to change over to a SLC 5/03. I have a used 5/03 but I cannot communicate with it. I have to use the PIC. How much do I hate the PIC? It seems to me there was some trick to making the PIC to work. I think it was something I did with the comm port, but I don't remember what that was. Can someone clue me back in? I know one of you has the answer. This site has never let me down. Thanks in advance.
stv

 

[KP_EENG]

The Major Error code 5h for the Micrologix 1000 is "Retentive Data is Lost", but this is a Going-To-Run error which occurs when the controller is going from any mode to REM or any Non-Run mode to Test mode. This doesn't seem to match your particular problem. Is it possible that the Micrologix is momentarily loosing power possibly due to a loose connection? The voltage spike could dump the processor memory or the battery may be faulty.

Changing over to the SLC 5/03 should not be too bad, but I have always had trouble getting the PIC driver to work with Win2K and XP. Another option would be to use a CP-13 cable and DF-1 driver and program the SLC over Channel 0 or a PCMK card and the DH485 driver to program via Channel 1 (expensive).

I hope that this helps.
Regards

 

[vettedrivr]

I have seen the major error code 5h in a couple of micrologix 1000's where I work. The cause was the first ML1000 was that it was not grounded, the second ML1000 was turning solenoid valves on and off and had no spike protection on the outputs. After a call to RA and installing a ground wire on the first (machine was built for us without the ground lead hooked up) and installing spike suppressors on the second (machine was built for us without spike protection) the problem went away. The errors were occuring on both processors at least once a week. After installing the ground and suppressors it hasn't happened for over a year.

I use the PIC driver for almost all of my communications with our 25+ micrologix controllers on a laptop with win 2K with no problems.

 

[Lancie1]

It seems to me there was some trick to making the PIC to work. I think it was something I did with the comm port, but I don't remember what that was. Can someone clue me back in?

Stv, I think it takes more than one trick.

1. First trick is to check your Windows Device Manager to see if your computer COMM port is being used already. If it is, then you must delete or disable whatever driver is using the COMM port.

2. Second trick is to use RSLinx program ("Communications", "Configure Drivers" to check to see that the PIC driver is loaded, running, and not Stopped or in Error mode.

3. Third trick is to use RSLinx to set the PIC box as one of the browsed nodes. Make sure there is only 1 PIC driver loaded, and it is being browsed. Disabling (stopping) all other driver nodes helps, if it is possible to do that without shutting something down.

4. Fourth trick is to open the RSLogix PLC program, then go to "Tools", "Options", "Systems Communications". Set the PIC as the current driver for this program. Then ON THE SAME MENU, click the "Online" button. If it doesn't connect (usually it will if the port connector and the PIC cable are good), then go back to the System Communications menu and try Uploading the program. Sometimes that will reset the baud rate (9600 or 19200) communications parameter between the PLC and RSLogix that does not match.

 

[Eddie Willers]

Vettedrvr is right on; MicroLogix 1000 fault 0x05 problems are virtually always caused by insufficient ground or unsuppressed inductive output circuits.

There was a batch of 120VAC MicroLogix about five years ago that were more susceptible than usual to dirty AC line power. They still met the test standard, but normally the MicroLogix exceeds the test standard by a healthy margin.

Check your ground wire, and examine the output wiring.