Jump to content

Recommended Posts

Posted

I have a small issue while sending a move command to a stepper drive from a V130-33-TR34. We have a strange occurrence at a few speeds. We are sending a pulse train at 8650 speed with a distance of 20000 -this is basically a jog move to until a sensor is activated. Once the sensor is tripped we move a predefined distance (600 pulses) at the same speed of 8650. The way this is done is that in the ladder logic the jog move is started based on the rising edge of an input to the plc then on the rising edge of the sensor input a second move command is sent with the new distance. We do not issue a stop between the two move commands, we simply issue a second command while the first move is in motion creating a single smooth trapezoidal move. This works great with the exception of a handful of speeds (frequencies) 8650 being one of them. When 8650 is used the second move (600 pulses) is ignored and or is altered and overshoots the gap sensor and another gap is sensed with another rising edge and the system goes into a cyclic process with no end. If we use 8650 as the speed for the jog move and another speed (ex 8649) for the second move (600) the system performs perfect and stops exactly where expected.

post-4644-008082100 1315494186_thumb.jpg

Posted

Stepper motor/drive systems suffer from natural resonant frequncies at which they do not run very stable at. Usually you have to actively avoid the first two major harmonics. The first harmonic is usually at a low enough speed that it is standard practice to jump directly to a minimum frequency that it above that harmonic. The other one is usually found empirically. So you'll want to program a skip over that frequecy. The code could get complicated.

Posted

Stepper motor/drive systems suffer from natural resonant frequncies at which they do not run very stable at. Usually you have to actively avoid the first two major harmonics. The first harmonic is usually at a low enough speed that it is standard practice to jump directly to a minimum frequency that it above that harmonic. The other one is usually found empirically. So you'll want to program a skip over that frequecy. The code could get complicated.

thank you for the reply. I had thought that there may be an issue as you desctribed so i performed a test in which i took the motor and driver out of the system and just let the plc pulse while watching the PTO Status. It is interesting because the same thing happens i activate the first jog move with a speed of 8650 and manually trigger the sensor and it dramatically overshoots the target distance. when i use a speed of 8649 it works perfectly.

Posted

thank you for the reply. I had thought that there may be an issue as you desctribed so i performed a test in which i took the motor and driver out of the system and just let the plc pulse while watching the PTO Status. It is interesting because the same thing happens i activate the first jog move with a speed of 8650 and manually trigger the sensor and it dramatically overshoots the target distance. when i use a speed of 8649 it works perfectly.

Hi Joe,

I appologize. I did not read your original post very carefully. What you explain does sound a bit puzzling.

Have you monitored MI18 and MI10 to see if you get any errors? I don't see where you use MB27 or MB3, how are you detecting the end of the registation move (ie when motion is complete).

What happens when you increase the speed by on increment? Are there any speeds above 8649 that work?

Is it overshooting a consistent amount or is it all over the place?

Do you have the ability to count the pulses?

What is your stepping resolution?

Posted

Hi Joe,

I appologize. I did not read your original post very carefully. What you explain does sound a bit puzzling.

Have you monitored MI18 and MI10 to see if you get any errors? I don't see where you use MB27 or MB3, how are you detecting the end of the registation move (ie when motion is complete).

What happens when you increase the speed by on increment? Are there any speeds above 8649 that work?

Is it overshooting a consistent amount or is it all over the place?

Do you have the ability to count the pulses?

What is your stepping resolution?

Thanks for staying with this post. I dont believe i have monitored M18 and 10 for errors. I am not using MB27 or MB3 for any other functions within the program. The first move is not really supposed to complete, it is supposed to see the sensor before completion. Once the sensor is tripped we overwrite the previous PTO command with the one to terminate the move. We are not detecting the end of the move by any feedback device the move is completely open ended. Heres the puzzling thing - the code and stepper system system works perfectly at just about every speed from 3000 up to 18000 pulses. I noticed this condition while testing random speeds - so yes works great at higher speeds. When it overshoots it appears to be relatively conistent, but the overshoot is huge. for example my second move is 1/2 inch it overshoots anout 8 inches. My stepper resolution is set to 1600 PPR and can accept up to 200kHz. I have attached the program for you to evaluate. Maybe there is a better method??? Also, the program altered from the original in which i subract 11 from the first move's velocity decreasing the chance of the issue, but i would like to eliminate if possible. I have posted another entry in the forum asking in more detail for help with programming.

thanks,

Joe

gap sensor program.vlp

Posted

Thanks for staying with this post. I dont believe i have monitored M18 and 10 for errors. I am not using MB27 or MB3 for any other functions within the program. The first move is not really supposed to complete, it is supposed to see the sensor before completion. Once the sensor is tripped we overwrite the previous PTO command with the one to terminate the move. We are not detecting the end of the move by any feedback device the move is completely open ended. Heres the puzzling thing - the code and stepper system system works perfectly at just about every speed from 3000 up to 18000 pulses. I noticed this condition while testing random speeds - so yes works great at higher speeds. When it overshoots it appears to be relatively conistent, but the overshoot is huge. for example my second move is 1/2 inch it overshoots anout 8 inches. My stepper resolution is set to 1600 PPR and can accept up to 200kHz. I have attached the program for you to evaluate. Maybe there is a better method??? Also, the program altered from the original in which i subract 11 from the first move's velocity decreasing the chance of the issue, but i would like to eliminate if possible. I have posted another entry in the forum asking in more detail for help with programming.

thanks,

Joe

Hi Joe,

I tried to run your program on my V130, but unfortunately mine does not support the motion blocks.

Even though your move is "open loop" it would still be a good idea to use the MB bit for the second move to determine when it has completed sending out the pulse train. This will at least prevent an overshoot from re-invoking another move. I still think it is worth looking at the MI status registers to see if they are giving you some kind of information. You may find for example that at the magic speed that is giving you issues is also giving you some sort of error such as "out of range" or "Currently in Motion". You may find that the registration move is never actually happening at all and that the overshoot is really just the original move coming to completion, since that is setup as an index as well.

Damian

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

This site uses cookies. By clicking I accept, you agree to their use.