Sign in to follow this  
Followers 0
Gary Burton

Effect of "master position filtering" on an axis (CLX)

34 posts in this topic

This is one of the tabs in axis properties. What I'm wondering is, are you supposed see the effects of this filtering on say a velocity tag? If I have a noisy feedback how does this value (in Hz) affect the position of the axis? I tried trending the velocity tag and nothing I did as far as adjusting the filtering frequency made any diffrence...maybe I'm missing something? This noisy axis can obviously affect interpolated position.

Share this post


Link to post
Share on other sites
...and the help file isn't much help on this one. I have found through experimentation that it acts as a low-pass filter on the axis position when used as a master in a camming or gearing operation. There is accompanying phase delay, so you need to be careful how you use it. It's intended to remove "jitter" on a master axis so slave motion is smooth. By "jitter" I mean mechanically induced noise, not electrical noise.

Share this post


Link to post
Share on other sites
This is a huge problem. People often expect perfect camming when the master position, velocity and acceleration is imperfect. A motion controller doesn't have much choice if the master is not controlled by the motion controller. If the master is controlled by the motion controller then one should be able to do almost perfect camming usuing advanced techinques. The slave must execute a postion, velocity and acceleration profile as a function of the master postion but on top of that the chain rule ( calculus ) must be used. This means that the master position ,velocity and acceleration are important and here lies the problem. You can't just gear to the master position, you must gear to the master position, velocity and acceleration and even jerk if you can. Now you can see the big problem People have a hard enough time of trying to calculate the master velocity. This requires techniques beyond those dicussed on any of the PLC forums or used by most motion controllers. I bet no one knows what I am talking about but everyone understands the problem.

Share this post


Link to post
Share on other sites
My master is an auxilliary feedback...so no control. Is it possible to use a non axis tag to cam or gear to? Maybe build some filtering through ladder and gear to that? Or maybe it will make the problem worse....

Share this post


Link to post
Share on other sites
Don't filter in the PLC. I would use an observer or Kalman filter that looks at both the auxiliary feedback device and the control signal to that device. To do this you need to build a model of how the master responds to the control signal. You do this by logging the control signal to the master and the feedback from the master. This data can provide the model if you know the right mathemagic incantations. The observer then can take the control signal to the master and feedback from the master and calculated the position, velocity and acceleration very accurately and it is this data that you gear to. Simple, yes? Nasa uses Kalman filters and observers if they are good enough for them they are good enough for you. This is the right answer if you aren't going to fix the source of noise in the feedback. I would fix the source of noise first because it is a lot cheaper, then try the advanced techniques. Gary, I wrote this tonque-in-cheek but you provide so little information and I don't want to play 20 questions so I just told you how I would approach the problem. I have seen noisy encoders doom flying shear projects. In these cases the master feedback was a roll driven by friction. The material running through the roll was moved by other rollers. There was something wrong with the other rollers and the material would bind and release then bind and release at very short intervals. It was impossible to gear to. I got involved and found this binding and releasing. I took months to re work the machine so the rolls turned smoothly. Now the motion controller gets smooth counts.

Share this post


Link to post
Share on other sites
Peter - thanks for taking the time to answer my questions... On the noise, I have tried every concievable way to eliminate it - changed encoders, seperate shielded beldin run completely away from other cables etc etc...it remains. So back to mechanical noise. The drive is a eurodrive variable speed....variable shiv. It is rough in operation, vibration is present.....could this be it? The encoder is driven by a cogged belt and geared down... I don't know enough about this to make a judgement call on the mechanical side (Millwrights don't like to be told things like this)

Share this post


Link to post
Share on other sites
Make sure you have a high resoltion encoder and if the problem still occurs then tell the mechanical guys to fixit. Garbage in give garbage out. Even the mechanical guys have heard that.

Share this post


Link to post
Share on other sites
That is my next move - the encoder will be here Tuesday.....the advanced filter option sounds interesting will make for a good read - how would you filter it if not in the PLC? Edited by Gary Burton

Share this post


Link to post
Share on other sites
In the motion controller. Where else? The PLC isn't fast enough to provide smooth positions at the rate the motion controller needs. Throught all of this you still have given any indication of how bad the noise really is. 5% ? 10% ? ftp://ftp.deltacompsys.com/public/jpg/ref...er%20roller.gif This is a graph of the encoder for that flying shear I was talking about. Notice how the velocity ( blue ) slows down and then lurches ahead. This is due to mechanical binding and releasing. Get a scope, if your encoder looks like this you have a mechanical problem ftp://ftp.deltacompsys.com/public/jpg/ref...er%20manual.gif This is the same encoder when we turned it by hand. Notice that the velocity is smooth. The little jitter you see is due to quantizing. This is actually pretty good ftp://ftp.deltacompsys.com/public/jpg/flying%20shear.png This is the after. The mechanical parts are fixed and the encoder has been upgraded to a very high resolution encoder. The magenta ( target velocity ) and pink ( target acceleration ) are derived from the master encoder data. You can see that this data is very smooth.

Share this post


Link to post
Share on other sites
How about this? http://www.cognitoquam.gr/en/tm/encdrf_b.html ...a little spendy though I'm using kinetix.....the noise is about 10 % Thanks for your answers Edited by Gary Burton

Share this post


Link to post
Share on other sites
So where is the manager? Don't tell me he can't tell the difference between electrical, quantizing, and mechanical noise. Sometimes you must be a hard booty and make the other guy prove he has done his job right and fire the manager for not knowing the difference.

Share this post


Link to post
Share on other sites
So I understand quantizing as the "smoothing" of the encoder inputs to make a nice "smooth" signal...how far off am I? Firing the manager is not an option

Share this post


Link to post
Share on other sites
Gary, could you go into a little more detail about what exactly it is doing?

Share this post


Link to post
Share on other sites
TW- basically what is going on is that when I try to cam to my master using the GSV SSV instructions to find the position of the master when the slave registered, the position that the master is reporting is bogus....because of noise......so its basically what Peter is saying, you cannot get accurate positioning untill you have reliable position information from the device you are camming or gearing to. I have to get a more accurate encoder input from my master axis.....its is noisy due to mechanical vibration, jerking etc My encoder is 5000 ppr which results in a resolution of 0.00125 pulses / .001".....it used to be .0025 pulses / .001" I guess I did not go high enough on the encoder counts / rev. in hindsight Edited by Gary Burton

Share this post


Link to post
Share on other sites
Get a system integrator to make your system work and fire you boss for being being clueless and not training you better. I am done. You should have told us about the GSV on your first post.

Share this post


Link to post
Share on other sites
Ah yes..... if only life was that simple. The system is working, I replaced a Delta Tau SMCC with this AB Kinetix system.....I am just trying to learn more about motion control as this was my first project. Right now I'm using gearing because my camming did not work due to noise. The tolerance that the machine is currently getting is within our spec.... Thanks for your contribution Edited by Gary Burton

Share this post


Link to post
Share on other sites
If I am understanding you correctly you are using a GSV to try to capture the position of the axis upon the registration. If this is true then this is be part of your problem. There are timing issues associated with the GSV and this is not the proper way to do this.

Share this post


Link to post
Share on other sites
Here is what the GSV SSV GSV looks like....A3 is my master and A1 is the axis that the registration input is wired to (the kinetix drive is A1) GSV(AXIS,A1,Registration1Time,A1RegTime) SSV(AXIS,A3,InterpolationTime,A1RegTime) GSV(AXIS,A3,InterpolatedActualPosition,A3PosWhenA1Registered) I guess I should have posted this code at the beginning......This is how I think I get the position of my master....and I think it is correct. What do you think TWC? Edited by Gary Burton

Share this post


Link to post
Share on other sites
I am not on a computer with RsLogix 5000 but I believe the command is MAR (Motion Arm Registration). This should log the the position at the exact point of seeing the registration input. It is done inside the motion module. No scan time to deal with There are severe variations in your method of using the GSV/SSV. It is scan time dependent for one, you method takes 3 scans to do it. If your scan time varies then it can vary your position. But if anything your average scan time is your minimum variation. If your registration is made at the moment before the scan starts then it will immediately begin processing. If it is made at the moment after the scan starts then it will not be processed until the next scan. You could use an EVENT to minimize this but it will still be there. The MAR is the way to get your position. There are instructions to synchronize your axis also. I would suggest you start by reading THIS manual. The big thing to remember is if it has to go through the ladder then there is a chance for variation Could someone look up the processing time of a GSV and SSV instruction and provide the link. I did a quick search but didn't see it. Don't have much time right now

Share this post


Link to post
Share on other sites
Hi TWC - Iam using a MAR to arm the input and the registration also sets off an event task...which is where the GSV SSV GSV are located. It all works perfectly ....except for the noise The time it takes for a GSV etc is not relevant because the interpolated position is used later in a cam....the cam starts after an offset.....

Share this post


Link to post
Share on other sites
If you are doing the MAR then why are you doing the GSV to get the position. That is the equivalent of staring at it and seeing where the switch is made at, then asking the guy across the room who wasn't looking where it stopped at and taking his word for it. He is going to turn around and guess and that is what you are doing Why are you doing the GSV when you are already doing the MAR. After that you need to get ride of the other GSV and SSV. Do you not understand the variation your program is causing? With this program written like this I don't think you can completely call it mechanical noise.

Share this post


Link to post
Share on other sites
Iam getting registration time not position with the GSV Read the 3 instructions again...I don't want the slave position (A1) Edited by Gary Burton

Share this post


Link to post
Share on other sites
I thnk you should read it. Gary's procedure is correct. He wants to know the position of the master axis when the slave axis has a registration event. The way to do this in CLX is by interpolating the position from the time (coordinated system time) of the registration event. The motion module (or sercos drive?) performs this function. I think (not sure) that the module has historical data that it uses to do the interpolation. Gary has two problems with the same root cause. The mechanically-induced "noise" on the master encoder signal not only makes the cammed slave axis do St.Vitus' dance, but also returns wildly variable posiiton data to his registration procedure. Gary needs the services of a good mechanic.

Share this post


Link to post
Share on other sites

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
Sign in to follow this  
Followers 0