Hoist/Lifting Lowering Application-Allen Bradley Comms

[Stuntman]

I have a question concerning a communication loss from the plc to either the power flex drive or point IO listed in the diagram.

Since this is a lifting the application either the brake or the vfd must have control of the hoist at all times.

If the vfd has a loss of communications to the plc the plc has to realize this quickly and tell the brake to engage. If the point io has a loss of communication to the plc the point io must fail the brake output off. I under stand how to set up how you want the point io to fail i.e. fail on/fail off etc.

What determines how soon the controller realizes that the drive has had a comms loss? What determines how soon the Point IO Ethernet comms module realizes it has lost communications to the plc? I am needing <1sec. response rate from the drive and the point io on comms loss.

 

[Lancie1]

Since this is a lifting the application either the brake or the vfd must have control of the hoist at all times.

It seems that for this critical function, the brake should be engaged any time the hoist motor does not have control. For all the crane controls that I have worked on, that is the way it worked. The brake was nevered triggered by a PLC, but simply by the loss of power to the motor (either by a switch on the motor shaft, or by a brake coil that dropped out upon voltage loss).

If safety is paramount, then I think depending on the PLC is not a good idea.

 

[Stuntman]

Lancie, The current way that the process which is a dip bath is being controlled is using the plc to control the brake and to tell the drive to run fwd/run rev. The plc communicates to a remote io module which controls the brake and also to the drive which also has a remote IO module. The best way to control this process would be to have a drive with a torque proving feature and have the drives onboard IO control the brake itself. But I still have an issue because the run fwd/run rev commands are sent from the PLC via comms. If i send a signal for the drive to run rev (Lower Load) and the plc loses communication with the drive the drive should continue to lower the load until is has detected a loss in communication and fault the drive which would stop the drive immediately.

 

[Lancie1]

If i send a signal for the drive to run rev (Lower Load) and the plc loses communication with the drive the drive should continue to lower the load until is has detected a loss in communication and fault the drive which would stop the drive immediately.

You need a drive that can be programmed internally to apply the brake upon loss of communications. That could be done with a VFD auxiliary programmable output (most VFDs have those). Use that VFD output to control a method to locally apply the brake. That could be in parallel with and addition to the existing brake controls.

 

[Stuntman]

I agree but how long does it take the drive to detect a communication loss? This doesn't appear to be setting in the drive. I have pulled the ethernet plug from a power flex 70 and it appeared that the drive didn't fault until around 3 seconds after being unplugged.

 

[Lancie1]

I don't think that you want to wait for a drive fault. Instead look in your VFD Manual to find what programmable parameters are available to detect the Loss of Communications. It will probably have a settable time delay before taking action.

The drive fault is probably set to happen much later. The time delay may be too long even at the shortest setting. That is why most hoist brakes are designed to be automatic and not dependent on any external controls.

 

[Lancie1]

Looking at the PowerFlex 70 & 700 Reference Manual, on Page 2-82 "Direction Control", it describes a firmware revision 3.001 for PowerFlex 700 drives that allows Parameter 379 [Dig Out Setpt] to control a VFD Digital Ouput based on loss of Datalink communications. The descriptions metions a 5 milisecond update time. This output could be used for local control to apply a brake.

The nearest equivalent in the PowerFlex 70 might be the Parameter "Digital Input Status". I don't know if you can pull out your comm link and somehow make it produce a digital input for your PowerFlex 70 drive.

Another PowerFlex 70 method that might be used is set 238 "Fault Config 1" to Shear Pin Fault. Then you can set a Current Limit Value to be used. If your drive communications link allows you to continually update that Current Limit Value, then perhaps you could send periodic messages updating it to some value that prevents the Shear Pin Fault shutdown. When those messages stop, the value should default to some low value that causes a Shear Pin Fault Shutdown. I can't try this, so don't know if it could be made to work.

 

[Lancie1]

What determines how soon the Point IO Ethernet comms module realizes it has lost communications to the plc?

Does this Ethernet Module have any auxiliary outputs that could be used to send a digital signal to a PowerFlex 70 programmed Digital Input [Parameters 361 - 366] set for "Auxilary Fault"? The Auxilary Fault Input can be used to unconditionaly stop the drive and send it to Fault Mode. See Powerflex 70 Refernece Manual page 2-73.

Perhaps you have some other remote I/O modules near the VFD that could be used to detect a loss of communications. Then just create a PLC output that goes off when the comm signal is lost. Wire that output to one of the unused VFD Input Terminals, and program that terminal to be the Auxiliary Fault Input.

 

[Liam Moran]

I think you should not consider communications into the braking circuit for a hoist. The brake should only be controlled by the drive itself, directly. 2 functions need to be taken into account.
1. Motor frequency greater than a preset value, say 5hz.
2. Motor current also greater than a preset, to assess the drive is actually taking the load.
This is done using a digital output from the drive, which should be directly wired into the brake control relay/contactor.
Also take into account the status of the Drive, by using the contact of the status relay indicating the drive is not in fault.
This is important particularly on a hoist where you have 4 quadrant control. A braking resistor is normally used to dissipate the energy
generated by the motor on overrun.If anything happens to this resistor causing a connection to be broken, then the DC bus voltage of the drive will increase to a level where the drive has to shut down to protect itself. This Status relay will engage the brake in this case.
The brake must be failsafe, that is only release if ok to do so.
I would not channel the brake control I/O through any remote I/O system
unless the failsafe criteria are fulfilled.

 

[padees]

For lifting safety, the brake should be a mechanical fail safe device. Outside of the electrical control scheme.

Some genius used the same output to engage a clutch and fire the indexing motor on a robotic weld cell. The output on the PLC fried "ON" and the logic gave an index complete. 5 robot's came in to do their thing and got busted up pretty bad.

Mind your P's and Q's when it comes to safety.

 

[2rlp]

You could utilize a counter to count the number of Ethernet packets received. If this counter has not incremented itself within the next 100msec or whatever period you feel fit, you could command the PLC to engage the brake routine

 

[OkiePC]

You should treat the brake/PLC transfer control correctly when switching modes in either direction. I argue that there are times required in which BOTH the brake and the motor have control of the load (vector full torque and zero speed command, hadwired VFD fault relay to interrupt brake current), some time to occur (drive preset), then release the brake automatically while transferring to velocity mode without disabling the drive.

That is the ideal thing, simple slam bang brake timing settings will work well too, but again, always one or more devices must hold the power required to stop the load, and the fault drop distance should be tested and measured (if the drive faults, there will be a measurable drop in height of the full load before the mechanical brake stops it.).

You want to use the drive's built in hoist mode and timing capabilities or consider a special firmware vfd for a crane/hoist, especially where safety is involved. The PLC can do a fine job of controlling the timing, but why get the PLC involved and widen the scope of potential for failure? The drive has to be involved anyway, so use its timers...Let the PLC tell the drive what to do (stop, go up, go down, speed), but let the drive manage the brake and motor.

You may not want the drive to fault when comms are lost, you may want to hold 0 RPM at full rated torque until the brake has had time to engage. I believe you can configure parameters for comms loss action to achieve this.

 

[dondon_alba]

Hi,
Just few questions?
1. Are you using PowerFlex700VC?
2. Are you using 20-comm E Ethernet adapter?
3. & electro-mechanical holding brake?
I had a lot of installation regarding hoisting application, if the above questions are true, I think you do not the to worry about loss of comms. Just simply let the drive control the electromechanical brake using one of its DO, and set the VFD to Torque Proving application.

 

[Lancie1]

Hi,
Just few questions?
1. Are you using PowerFlex700VC?

I can answer that for Stuntman: NO.

I have pulled the ethernet plug from a power flex 70 and it appeared that the drive didn't fault until around 3 seconds after being unplugged.