controllogix processor stuck in run mode

Can anyone help with this one I never ran into this before.
I have a controlLogix 1756-L63 Processor and when I turn the key
to program mode the processor stays in run mode. Tried to reboot with key in program mode but same results.


Thanks Dan

Greetings Dan ...

and welcome to the forum ...

this is a weird one ... just grasping at a straw here - but is there any chance that you have more than one processor networked together (Ethernet, ControlNet, etc.) and that possibly you're "online" (communicating) with the WRONG processor? ... that's about the most logical way for something like you're reporting to happen ... specifically, MAYBE you're looking at the "mode" indication on the computer screen - but MAYBE you're looking at the wrong processor? ... just a guess ...

if that's not it, then it sure sounds like you've got yourself a processor with a bad keyswitch ... what's the "RUN" LED on the front of the processor doing? ...

good luck ... and please come back and let us know what you eventually find out ... this is the type of stuff that keeps some of us awake at night ...

Thanks Ron,

You were right on. I'm also trouble shooting this over the phone on call for the holidays... Two Processers on the same network with the same processor names and was logged into the wrong PLC. they were tring to change a servo peramiter in the wrong PLC.

Thanks again for ther great reponce.

Have agreat Holiday.

Dan

Excellent perception, Ron !

Although this is demonstrably not the problem in your case, I figured I'd post that I have seen a similar symptom in older 1756-L1 controllers that was caused by Message (MSG) instructions.

In some old firmware versions of the -L1, the controller won't transition out of RUN mode if you have Message instructions still in the execution queue. Sometimes users will write MSG instructions that execute repeatedly without checking for target device availability and don't have a way to intervene in the instruction execution in ladder, therefore you'd get a processor that wouldn't respond to it's keyswitch. Rebooting in Program mode, of course, flushed the buffer and caused the controller to come up in normal Program mode.

To add to what Ken said above. I have seen a V15 firmware L63 take a long time to transition (did not stick as described above) to program mode from Run. If I remember right it was something like 5-10 seconds. This occured when we were messaging from a CLX to a SLC 5/05 over ethernet and the SLC was not available on the network. If the SLC was up and running (sucessful messages) the transition from Run to program was percieved to occur at normal rate.

Darren

dash said:

To add to what Ken said above. I have seen a V15 firmware L63 take a long time to transition (did not stick as described above) to program mode from Run. If I remember right it was something like 5-10 seconds. This occured when we were messaging from a CLX to a SLC 5/05 over ethernet and the SLC was not available on the network. If the SLC was up and running (sucessful messages) the transition from Run to program was percieved to occur at normal rate.

Darren

Click to expand...

That issue was/is in V13 as well. I took over a Clgx project that had major 'hang-up' issues with MSG instructions to basic modules.
Transitioning from Run to Prog took about 5 -10 seconds as well before I put code in to better manage the MSG instructions.

That reminds me that I also had to do the same. The original code sent the message without regard to multiple request for the same info before the previous request had a chance to error out or complete sucessfully (toggled based on not enabled bit, VERY bad idea). After cleaning up the bad code it worked much better.

What is the best way to manage the message instructions? I have an upcoming project where status data will be messaged via Ethernet between several ControlLogix, CompactLogix, and FlexLogix processors. It is possible that a few of the processors will be powered off from time to time for maintenance and I want to avoid the problem described in this thread.

For that selection of controllers I would look at using produced/consumed tags.

Especially if the status of one controller (producer) is required by multiple consumers. Of course you may also need to investigate if your network switches can properly handle multi-cast data. This will be indicated if the switch supports IGMP snooping. If these are not industrial switches there may be several settings you will need for the switch to maintain the subscriber information.

Darren

danny.michael said:

What is the best way to manage the message instructions? I have an upcoming project where status data will be messaged via Ethernet between several ControlLogix, CompactLogix, and FlexLogix processors. It is possible that a few of the processors will be powered off from time to time for maintenance and I want to avoid the problem described in this thread.

Click to expand...

I normally manage the messages one of two ways. If the status of one processor must be known by one or more processors on a predetermined basis, then Produced/Consumed tags are the way to go, assuming all processors are of the Logix family.

For non-logix MSGs , I usually use a timer, or a bit shift to enable each message in a sequence.
For the timer method, testing for the absolute value of the timer's accumulator is not always reliable, therefore, I use a limit of about 10-15ms around the time value. If the messages need not be sent at a high rate, i set the timer's preset at 5000ms, if the messages need to be sent faster, then I reduce the timer preset accordingly.

Ian

In my project, there will be one "Master" ControlLogix processor that will request data from the other processors in the system. The request will be via a message write. When the other processor (could be ControlLogix, CompactLogix, or FlexLogix) receives the request it will respond with the requested data via a message write to the master.

Is there a way for the master ControlLogix processor to know if the other processor is online before initiating the message write?