Motor Control Stopping

I am changing over from a Honeywell motor contorl system. I am using a AB ControlLogix L61 processor to control the system (as well as other systems like drives). I have not changed the wiring compared to the Honeywell system, therefore I'm taking their wires and putting them into the equivilent IO on the AB system.

The Honeywell system uses Opto22 relays to control the motors. The 120VAC power is taken from a transformer in the Motor control buckets. Attached is a PDF of the wiring.

The AB modules that I am using is
1756-IA16I
1756-OW16I

The logic shows the status of the motor. If the input is dropped without the stop button being pressed, then the motor shows failed. This has been happening to me at 5:50AM ish for the past 2 days and I do not know why (we are a 24x7 operation so no system power fluctuations). I have 4 motors (not critical ones) on this system and they all fail at the same time.

I can put the motors in manual (which holds the contactor) and they do not fail. When on the Honeywell system they do not fail, so why do they on mine?
I have not yet put a logger on the input to ensure that the voltage doesn't drop too much, which I suppose is the next thing to do, but wouldn't that affect Honeywell system?

The system has teh main processor going to a N-Tron 508-TX switch then to drives, HMI pannels, remote IO. With all this the ethernet CPU is around 70% (when checking on the webpage) with some spikes to 80%. I have ordered another Ethernet card to put in the main system to try to stem this.
My RPI for the motor remote IO system is 100ms
My processor is 93ish percent but I have a continuous loop which has a scan rate of 3ms (watchdog is 500ms) as with all my other processor stuff.
My timeslice is set to 50% and as mentioned above the scan rate is very good.

Sorry for the long post, but I wanted to make sure you have enough info to try to help me.

'Help me PLC.net.... you are my only hope!"

So you are using 2 volt free contacts off a relay card.

Your connections at the AB end I would presume to be something like:

SP1-1 -- L 1.0
SP2-2 -- OUT 0

SP1-3 -- L 1.1
SP2-4 -- OUT 1

The STOP will be programmed to be ALWAYS ON unless a stop is required and the START will be an impulse start signal (not maintained).

Once turned on the contactor will maintain itself via ST1-4.

What is the device MOTOR SWITCH? is this an overload contact or something?

Is the RUNNING contact an auxiliary, is it loose??

Are you actually switching the NEUTRAL going to your status input? That rather odd.

You are correct in the wiring and logic (I should have included the truth-time table).

Motor switch is a 3-way switch so you can stop power going to the coil (OFF), put power directly to the coil (ON), or run it by the PLC (AUTO). The diagram is incorrect in its position. Sorry about that. I didn't check that part as I have only been focussing on the auto side.

All the motors that I converted from the Honeywell system worked on the Honeywell system and would work when the switch is put to ON.
The running contact is an auxilary contact.
I do not believe it is loose as today at 5:52AM all 4 motors showed failed on my system requiring the operators to restart them. The failed status is when the INPUT-RUNNING is dropped without the stop button being pressed. The previous day it was 5:54AM.

rdrast said:

Are you actually switching the NEUTRAL going to your status input? That rather odd.

Click to expand...

I did not design the system, just duplicated it. The Honeywell system used 1 input and 2 outputs, so I figured out the logic and wrote a copy, duplicating the hardware.

If there is a better way to re-wire them, I will be happy to do a change.

I would presume the neutral is being switched because the live supply is also being used for the stop/start outputs.

A better alternative I would have thought would be a separate supply, but that would mean an extra wire per drive.

Is the I/O going to the motors remote and over the Ethernet I/P? Is the Ntron a managed switch? I know some are and some are not. You may need to isolate the HMI from the I/O from the Drives (comms). The AB drives can be a problem playing nice with other Ethernet I/P devices. Your problem sounds oddly like one I had once on the dreaded Device Net. You might try adding a short time delay and some diagnostic logic on your aux contact to see if it is dropping out momentarily. Of course then you would probably have the same issue with the stop output. Hmmmm. This is all moot if your I/O is in the local rack - let me know.

My bet is that the EtherNet/IP connection to the Remote I/O panel that runs the motors is failing, which switches off the Outputs in that chassis, causing the motors to stop "uncommanded" and triggering the fault logic when the connection is restored.

First thing I'd do is point a web browser at the 1756-ENBT in the Remote I/O chassis and check its Uptime value, which should be right on the Home page. If the Uptime is since the last failure, you know that the 1756-ENBT was rebooted for some reason. Power is the most likely reason, but there are others, like programmatic reset or removal/insertion.

The second thing I'd do is use a similar diagnostic value in the 1756-ENBT web page that is in the controller rack (the "scanner").

Go into the I/O Diagnostics folder, then into the "Bridge Connections" (EN2T) or "I/O Connections" (ENBT) window. Find the I/O connection that corresponds to your motor-controlling remote I/O rack and check the Uptime of the I/O connection itself.


These quick checks will tell you if the network connection should be a suspect in your investigation.

Attached is a single line diagram of the network.
I am getting in another ethernet card 1756-ENBT to put in the local chassis to separate the drives from the rest of the system, which should reduce the ethernet CPU from 70-80 to 40-50.
I reterminated the Cat5e wire from the motor remote IO (one we are having trouble with) so hopefully that will help.

This system was done in piecemeal initially 2 remote IO, 1 HMI, 1 Operator PC, 2 drives. Then more drives and HMIs were added until we got to 15. I then put on the motor remote IO and this is to control the DCS system. This is analogue IO which was working great (port over a few loops at a time). Now I'm starting to port over motors and run into this problem. The major benefit of this is no long shutdowns for the drive changeover, then the PID loops are getting ported over while running.

Ken,
When I disconnected the cat5 cable to reterminate it I lost the motors as I thought. Looking at the webpage (what I used for the CPU usage) the uptime is 90 days for the main PLC and 44 days for the motor remote IO, which both correspond to when I rebooted the PLC and installed the motor remote IO.
As mentioned I reterminated the cat5, so the 'IO connections' uptime for the motor remote IO is only 2 hours. I will check on that next time I get a fault.

Thank you all for your suggestions, and hopefully I can post no drop tomorrrow!

No tripping this morning after the retermination.
Monday I will install the new network card so the drives will be running off their own network card, with everything else (PC, HMI, remote IO) running off the other network card.

An update.
I installed the new network card on Friday and moved the remote IO panel onto this one (only this as the N-Tron switch hasn't come in). Nothing failed over the weekend so I think that the Honeywell system flooded the network when printing the daily reports, therefore enough delay between communications on the network between the PLC and network card.

Good news is that now I can port more motors over.