Internet PLC Forum

General => Technical support => Topic started by: can on February 04, 2011, 10:48:41 AM

Title: Motor Speed control
Post by: can on February 04, 2011, 10:48:41 AM
Hi. Currently trying to use a MD888 to control the speed of a motor. The motor is connected to a motor driver. MD888 will output a 0-5vdc analogue output to the driver and the driver will adjust the speed of the motor accordingly. When I use hscdef to stop the motor when hscpv[1]=0, the driver indicates an error of overload, meaning the stopping of the motor is too fast. I know this may be a problem of the driver but does anyone know how to implement a function to decelerate the motor accordingly and stop at the correct position with high repeatability? Thanks.

Regards
Ken
Title: Re:Motor Speed control
Post by: support on February 04, 2011, 11:10:47 AM
You can set HSCDEF to start decelerate the motor when HSCPV[1] = xxx and then in that custom function you re run HSCDEF at the next decrement (e.g. xxx/2) so that the same function will trigger again and you can SETDAC to yet a lower value. The third time you will HSCDEF so that it triggers when HSCPV[1] = 0 and stop.

Structured properly you can even give it a smooth deceleration by breaking it down to say 5 steps and each step you use the SETDAC to a lower value until it finally stop when HSCPV[1] = 0.
Title: Re:Motor Speed control
Post by: can on April 08, 2011, 01:40:00 PM
Hi. Had tried the method that you mentioned. Looks ok now. However, I have another problem. HSCPV[1] appears the same for both setdac[1],1000 and setdac[1],3500 but the actual distance travelled by the motor is different. The motor is having good repeatability when set at any speed using the method you mentioned but the distance travelled varies even though high speed counter claims that the motor has travelled the same distance. Any idea how to solve it?

Thanks.
Title: Re:Motor Speed control
Post by: support on April 11, 2011, 09:23:31 AM
The HSCPV function should return the correct value with respect to the distance as long as the incoming encoder pulse does not exceed its maximum frequency limit.

Please re check your data and ensure that your program did not reset the HSCPV somewhere during the changing of speed etc.
Title: Re:Motor Speed control
Post by: can on April 12, 2011, 09:34:33 AM
sorry. Any idea what's the maximum frequency of 888 or fmd88? Will putting in the negative phase of the encoder from the motor helps? The encoder on the motor is currently 1024 pulse per revolution and top speed of 1500rpm. What can i do to get an accurate reading? Thanks
Title: Re:Motor Speed control
Post by: support on April 12, 2011, 02:05:22 PM
The HSCPV should be able to read accurately if the incoming pulses is < 10,000 pps.
Title: Re:Motor Speed control
Post by: can on April 14, 2011, 01:44:38 PM
Hi. Am I right to say that the 888 does not support a motor encoder that is travelling at 1500rpm that gives a pulse of 1024 per revolution? Any idea what are the options available to me if i need to get the encoder readings accurately? Thanks.
Title: Re:Motor Speed control
Post by: support on April 14, 2011, 03:25:05 PM
that means 1500/60*1024 = 25600 pps? That's out of specified range. You may need an encoder that output 1/4 the number of pulses per revolution.
Title: Re:Motor Speed control
Post by: can on May 23, 2011, 01:00:32 PM
Is there any recommendations on anything that can take in the pulse and tell the PLC the current position if the encoder is 1024 pulse per revolution running at 1500 rpm? Thanks
Title: Re:Motor Speed control
Post by: support on May 23, 2011, 08:23:28 PM
Are you able to replace with an encoder that output just 256 pulses per revolution? That would put it within the maximum pps that a T100MD888+ HSC can handle.

You can also try with a FMD88-10 PLC. Although FMD88-10 is also spec at 10KHz maximum but since its CPU runs 3 time faster, my guess is that it may be able to handle the 25KHz incomg pulses (we can't guarantee it so you have to try, but if it works it could be the easiest solution).
Title: Re:Motor Speed control
Post by: can on May 28, 2011, 12:39:21 PM
Hi. FMD88 seems to be the same as 888 from what I see after trying them. Maybe you can try and verify in case I'm not doing it correctly? Thanks.
Title: Re:Motor Speed control
Post by: support on May 30, 2011, 04:13:24 PM
What if you try compare the HSC readings from slower speed settings (so that the HSC is subject to < 10Kpps) and see if the two settings travel the correct distance?  That way is to check whether it is other factors (noise pulses, mulitple pulses received from encoder etc.

Also if you try to stop the motor when HSCPV[] readings hit a certain value, then the motor may need some distance to stop. What are the readings of the HSCPV[] when the motor come to a complete stop? Does it correspond with the actual distance travelled.
Title: Re:Motor Speed control
Post by: can on June 03, 2011, 02:45:27 AM
Hi. Will a frequency divider helps?
Title: Re:Motor Speed control
Post by: can on June 07, 2011, 12:02:23 PM
Anyone knows if a frequency divider can help to lower the 1024 pulse per revolution sqaure wave ttl to 400 pulse per revolution? Thanks.
Title: Re:Motor Speed control
Post by: garysdickinson on June 07, 2011, 03:26:25 PM
If you are talking about a quadrature encoder (2 outputs: A and B phase) then ignore this reply.  

If you are talking about an encoder that simply generates pulses as the motor turns and does not provide any direction information, then read on..

To go from 1024 pulses / revolution to 400 pulses / revolution is not a simple task.  1024/400 = 2.56... The answer for this problem is way out of your depth.

Why not divide the 1024 by 4 and get 256 pulses per revolution?

Dividing by 4 is pretty simple task using both sections of a CD4013 (dual d flip-flop).

Another device to consider is the CD4040.  It can divide an incoming signal by 2,4,8,16,..4096.  If you picked the divide by 4096 output you would get 1 pulse every 4 revolutions.

Gary D

Title: Re:Motor Speed control
Post by: can on June 09, 2011, 12:20:20 PM
Hi. thanks for the reply. Why is the A and B phase output not applicable? Can I put the flip flop onto the 2 phase before feeding to the hsc of the plc? Both phase will be lowered and plc may be able to read the signa?
Title: Re:Motor Speed control
Post by: garysdickinson on June 09, 2011, 02:50:23 PM
I assume that if you are using a quadrature encoder (A and B phase outputs) that you are building some nature of servo positioning system.

Using a simple circuit such as what can be done with a CD4013 or CD4040 to divide the incoming frequency of both phases by 4 will not preserve the phase relationship of the original A and B signals. This will confuse the crap out of the quadrature decode mechanism in the PLC.  

If you are using a quadrature encoder and "looking" at only a single phase, then I assume that you are only interested in counting shaft revolutions.  If this is the case then, I'd ask, "why are you using an expensive encoder when a cheaper one would be fine?".

If you are only interested in counting shaft revolutions, and cannot use a more appropriate encoder, then a simple divide by 4 circuit might be a reasonable method to better match your system to the PLCs capabilities.

Gary d





Title: Re:Motor Speed control
Post by: can on June 10, 2011, 07:46:12 AM
Hi Gary, you right. I'm trying to build a servo positioning system using the 888. When I first had the idea, people were telling me that the positioning system can only be built with better and more expensive PLC. So I'm currently trying to prove them wrong. Any idea how to do it? If there's no solution, then maybe I will have to use a linear scale with the PLC to get the linear position. Any experience with linear scale output? thanks.
Title: Re:Motor Speed control
Post by: garysdickinson on June 10, 2011, 02:14:19 PM
I'd suggest using stepper motors.  The PLC provides very good support for steppers. You will probably need an external stepper driver to handle converting the PLC step and direction signals to the high current drive required by most steppers.

If you are looking for very low cost, RC servos are the cheapest approach to moving stuff that i've ever found.  The PLC's PWM system can be tricked into controlling these servos.  

Are you trying to build a multiple-axis system? If this is the case then you should listen to the people.  I consider this to be beyond the capabilities of the PLC unless you spend big money on external hardware.

Gary d
Title: Re:Motor Speed control
Post by: can on August 02, 2011, 10:37:10 AM
Hi Gary, thanks for the information. Can you show me how to use CD4013 or CD4040 to divide a single phase by 4 or 2? I'm only interested with counting the number of revolutions of the shaft. Beggers cannot be choosers. Have to make do with what's on the ground. thanks.
Title: Re:Motor Speed control
Post by: garysdickinson on August 02, 2011, 06:21:06 PM
Can,

This schematic is typical for a divide by 4 circuit using a CD4013 (dual d f/f).

The CD4013 works well with voltages from 5 to 15 VDC.  The diagram shows 12VDC.

A typical optical isolator is used for interfacing your encoder to the CD4013.  If you encoder can operate on the same supply voltage as the CD4013 you can probably eliminate this circuitry.  If the output from the optical isolator is "noisy" or slow to rise, you may need to add additional circuitry between the optical isolator and the CD4013.

I show a single section of a ULN2003 to interface to the PLC logic. Even if your PLC were running at the same voltage (12V) as the CD4013, you will still need something like the ULN2003. The CD4013 cannot sink enough current to wiggle the PLC inputs.

If you only need to divide by 2 then connect the ULN2003 input to the directly to CD4013 pin #1. Connect CD413 pin #11 to GND.

Not shown on this diagram are supply bypass capacitors.  These are typically used to ensure that electrical noise from external sources is suppressed and will not disturb this logic and to avoid any noise generated by the CD4013 (not a real big issue with CD4XXX devices...) from causing issues with other circuitry.

Good Luck,

Gary D