Monitoring motor current

Eric,
I seen that in the manual and I'll try it. Thanks.
Tim

Tim, for simplicity and faster response it would be preferable to have the drive itself do the protection function. If you can direct me to an on-line copy of the drive's instruction manual or if you can email me a copy, I will take a look at it and see if there is an internal way to do this. Use this email address--- [email protected]

It sounds to me like your best bet is buy an analog input for the PLC, and a power or current transmitter for the motor. Then you have absolute control of the events and sequences that cause a trip. We've had good luck with this brand:

http://www.nktechnologies.com

You could also try:

http://www.loadcontrols.com/

If you don't want to get an analog input I think both brands have models available with limit alarms and contact outputs as well as analog signals. Note that if you are using this on the output side of a VFD you need to make sure the model you select can handle the non-sinusoidal current waveform!

Just one caution here on motor lead current or power sensing devices. Since the output of the drive is far from a sine wave, most current sensors will not read true rms current accurately and are probably not suitable for this application.

There would be a temptation to put the sensors on the input side of the drive to accomplish the same thing but, due to the large energy storage in the DC bus of the drive, response time sensing the input would be far too slow for protecting a conveyor.

DickDV,
Here's the link. I have the instructional manual IB(NA)66813. I haven't had a chance to download the technical manual to see if it will offer any help.
http://www.meau.com/eprise/main/Web...2520115&Line=00015200252011520780&ManualType=
Thanks to all,
I'm going to bundle up all these ideas and come to some sort of decision.
Tim

Ok. This may sound stupid in the multitute of information that you have all ready gotten but...... Do you have overcurrent protection other than the drives internal settings in the hard wired motor line? We use telemecanique GV series overload blocks on most of our drives. Mind you they are controlling 6 or more motors from one drive. An AC current relay or overcurrent pot might do the trick as well. They can be set up as an instantaneous trip and automatically reset themselves if so desired. This might be enough to stop the process and stop the breakage.

Good Luck

OK, Tim, here's the scoop as I see it. Go to pg 147 in the IM. Para 150 & 151 set an overcurrent detection level. Set Para 150 for the current level that represents a jammed conveyor (if you set this too low you will get nuisance stops). Set Para 151 to 0 since you want fastest possible detection to avoid damage.

Then go to pg 155 in the IM. Para 190 and 191 control the signal assignments on the two open collector outputs. I would only use these if the internal fault relay represented by Para 192 is being used in your system. Assuming it is not, change Para 192 from 99 to 12. This puts the overcurrent signal on this relay. Use the relay contacts on terminals A,B, & C to stop or fault the drive, whichever you prefer.

If the relay is already in use as a fault relay, then change Para 191 from 4 to 12 instead and attach a relay coil to the open collector output at FU. Use this relay contact to do the stopping or faulting as above.

You may well find that this is too sensitive and produces false tripping. You can increase or decrease the current level sensitivity with Para 150 and add or remove time delay with Para 151.

If you get false trips when you do the fast decel at the prox switch, you may need to "cover" the relay contacts with a plc output when the prox switch is engaged. As most of you folks know, I'm not much of a PLC guy so I'll leave the details of that up to you.

Let me know how this works out. After all, this is the first time I've ever messed with a Mitsi drive!

DickDV,
You have made me feel smart. Okay, maybe not too smart. The reason is I know that you are very good when it comes to motors and drives. I can count the number of drives I've messed with on two hands. I have already done exactly what you have said except mess with the decel timing.
I went back to work the day after the original post and thought about this situation, "transfer crashing". I got a little more info on what it crashes into. See, it depends on where a part falls off. It could get jammed between something that has a little "give" to it, or it can jam on something that's very solid. This concerns me with reaction time going through the driver. Just my thoughts though. I also thought that it would be good to monitor the transfer at all times, FWD, REV, and slow down points. Reason is, if sometime down the road leaves a wrench or something in its path, then I'm back to having damaged parts. This gets me dirty looks, because I was supposed to have this taken care of. Anybody been through that? So my thoughts are to protect the whole cycle.
I also found out that the Hakko touch screen on the machine will read, write and monitor a FR-E500 inverter. This might still be a problem with reaction time in the occurrence of a crash. I would probably have to have two monitoring points, one for accel,decel and one for the in-between. I again, think that I will have the reaction time problem, but I'm going to try.
Dick, if you think that the reaction time will not be a problem or overtime as the motor deteriorates I'm not having to adjust the high limits then I'll be sold to the idea. Do you think that the concerns I have in reaction time might be better off by putting a torque limiter with a tripped LS between the motor and the worm shaft?
Thanks, beerchug
Tim

There is no question in my mind that the fastest response method is as I described above.

It also has the advantage of being equally sensitive at any speed and in any direction. A limit switch on the motor-gear would work in only one direction and would be unpredictable due to lubrication of the pivot point and, if in a dirty environment, the weight of dirt piling up on the motor and gear. Depending on how the gear is coupled thru to the conveyor, belt tension or chain lubrication would also affect sensitivity.

Did I understand you correctly to say that you have already tried the drive software changes I suggested?

It seems to me that the key to success here is to evaluate the difference between operating current and current when a jam occurs. If there is a large difference between the two, then my solution is OK.

If, on the other hand, there is no difference or if things like decel and accel current exceed the jam current, then neither software nor limit switches will do it since the same torque (current) occurs in both conditions.

I suggest you sort out the current issues first. With the results, we will be able to judge which way to go.

Let me know what the various current reading are. Thanks.

Regarding accel and decel currents, it seems to me that you could set up a timer in the plc to cover the accel and decel times.

For example, if the only accelleration occurs on start, and accelleration requires 2 seconds, set up a timer to close a contact for 2 seconds beginning on a start signal. If decel takes 1 second and only occurs when the prox switch is made, set up a 1 second timer to close a contact for 1 second starting when the prox switch is made. Wire the accel timer and decel timer contacts in parallel and then in parallel across the overcurrent relay contact on the drive. (I'm assuming that the stop or fault circuit is activated by an open circuit).

I think, no matter what, you should install some type of a mechanical overload clutch. If for no other reason than as a backup to an other type of overload detection you implement. It will also come in REALLY handy as you try to get the electronic version working. With the mechanical overload clutch, you'll know you can safely "test" the drive's current detection without destroying the machine in the process...

I have had good lick with Mayr Overload Clutches, but there are many other manufacturers you can investigate. You'll have to select one that can be set to the max. torque that occurs during accel/decel. You might think that would be too high to protect the drivetrain during "at speed" (low torque) movement, but it shouldn't be. Remember that the drivetrain doesn't explode during accel/decel, so it's capable of handling that torque. You just don't want any MORE load (like when a jam occurs).

As far as the "current" (no pun intended) topic...

Have you determined whether or not you can set up the drive to ONLY give an output (and not fault the drive) when a set current is exceeded? If so, then Dick's suggestion should be easy to implement (though you don't need the external contacts... You can accomplish the same thing within the PLC program). You still won't have protection during accel/decel, but that's where the mechanical clutch comes into play...

Using the Hakko is a very good idea, but I doubt you'll be able to use it to detect an overload condition. As you stated, it probably won't respond fast enough to be of any use...

Keep us posted!

beerchug

-Eric

Dick,
Yes, those were the original parameters I had set up in the beginning.
I got the alarms at the acceleration and the deceleration points in the transfer cycle. I monitored the current and then it dawned on me that this wouldn't work, because the accel and decel current was higher then my preset in the output current detection level parameters.
I would assume that the output current would be a lot higher in a crash situation then in normal operating current. You should see the damage it does! I don't know how I'm going to be able to see the current value on a crash situation.
The VFD does alarm out when it crashes, but only after severe damage. I'm going to have to get a lot more information on this. I'll see what I can do on the motor currents. I know I definitely want to monitor the accel and the decel current. I know I'm stepping backwards from my original post, but I need to prevent any crashing in the whole cycle. I guess this might be a problem using the timers to bypass the alarm contacts, if I'm understanding you correctly. I've made a hard solution into a harder solution.

Eric and Dick
This is what I'm worried about...What if the operator, or someone puts a wrench or takes a part off one of the carriage arms and lays it down somewhere he or she shouldn't? They then forget about it and start the transfer. The jamming point "where the part or wrench is", is near the start of the motor cycle. The acceleration current is going to be higher then regular speed of the transfer. The parameters I have set up will only look for an over current condition after the accel point. If I'm thinking right this is not going to stop the transfer before damage occurs. I think this covers parameter 156 as not catching problems in the accel and decel points, unless as you've suggested Eric, by protecting the accel and decel with the overload clutch. I'm going to be back on this project Monday, so I'll let you guys and others know what I come up with, since you took time out of your day, or "days" to give me some advice.

Eric, the Hakko can receive the output current value from the VFD in Hex with 0.01A increments and I can allocate this value to a plc register. I don't know about the timing of this, but I'll have to see. I got a new E500 VFD and Hakko back in the shop to mess around with, so I'll try this approach as well.
Thanks again, excuse any spelling errors, its getting late!!
Tim
beerchug

Tim said:

Eric, the Hakko can receive the output current value from the VFD in Hex with 0.01A increments and I can allocate this value to a plc register. I don't know about the timing of this, but I'll have to see. I got a new E500 VFD and Hakko back in the shop to mess around with, so I'll try this approach as well

Click to expand...

Yeah Tim, I get what you up to. Definitely worth checking into. My concern is how fast the information will get updated in the PLC.

In other words...

• 1 - Current goes above limit (jam occurs)
  ...
  "A" µs passes
  ...
• 2 - Hakko gets around to reading the value from the drive
  ...
  "B" µs passes
  ...
• 3 - Hakko gets around to transferring the data to PLC
  ...
  "C" µs passes
  ...
• 4 - PLC gets around to analyzing the new value and says "Oh ****, better stop the drive!"
  ...
  "D" µs passes
  ...
• 5 - PLC's "Drive Enable" output turns OFF
  ...
  "E" µs passes
  ...
• 6 - Drive is (finally) disabled

Question: How much time has passed between 1 and 6?

Answer: "A"+"B"+"C"+"D"+"E" µs...

beerchug

-Eric

Eric has a very valid point---since the accel/decel currents don't destroy the conveyor, you should be able to set the detection current in the drive above that and still get good jam protection. Or am I missing something here?

Good, question Eric, I have another.

If the obstructive force can be detected within a microsecond, can damage be avoided ( Think kinetic energy and dissipation of energy ).

We do position/pressure/torque control/limiting all the time using hydraulics. We can measure the forces every 122 microseconds. The force limiting capabilities greatly reduce breakage. We do this with motors, too but to a much lesser degree. Motors would be easier to control if the instantaneous currents truely reflected the torque/force.

I don't think montoring current is going to work. It isn't fast enough.