following error and contact

[shoneill]

I am currently using a motion system which has been neglected for a while due to some shortcomings for the original application.

I'm trying to revive it by making use of the following error to detect when contact is made between two objects.  The main Problem I have is reducing the contact pressure in such an arrangement.  I have implemented a basic version where the axis moves until the following error goes above a certain value (say 30 = 30um) upon which the axis then stops.

The problem is that I'd like to choose a much smaller value, but the jitter is too large to allow this.  I get values anywhere between 0 and 20 while the axis is moving.  Of course the following error increases dramatically once contact is made, but the problem is detecting this contact point quickly enough so that the pressure created is as low as possible.

I've tried limiting the torque of the servo motors, but I'm not sure this has had an effect.

Does anyone have an idea what I can change to improve this apart from using a different algorithm to detect smaller changes of the following error (slope over the last 10 measurements or something)?  Do I need to modify the coupling between the motor and the axis?

Thanks

Shane.

PS, I have already got some micrometer switches hooked up to the hardware, and they work nicely, but the ACTUAL contact points between two non-micrometer switches is what I'm after.

[Jochen]

Shoneill,

a moving servo axis always tends to oscillate a bit, so a slightly varying following error is quite normal. You could try to improve the situation by using weaker PID parameters as an axis that is tuned very stiffly oscillates more than an axis that is tuned for slower response.
Still depending on your mechanical setup a following error variation of only 20 counts for a moving axis could indicate a system that is already tuned for smooth operation so I don't know if your PID parameters provide some headroom at all.

I don't know other means than that to get along with this approach. Of course I can think of other approaches like adding a proximity sensor but this would mean more time and effort and probably additional hardware.

Jochen Klier
National Instruments Germany

[shoneill]

Jochen,

Thanks for the answer.

I've tried testing it with a 1mm glass substrate between the axis head (flat steel surface) and the stage (also flat steel surface) so that the two steel surfaces are slightly tilted to each other (representing what I hope is a real-world scenario).

I can drive the axis with 5 RPM (enough for my application) and a permitted following error of up to 2000 without breaking the glass.  I think this already gives me enough information to continue.  Incidentally, the rising flank of the following error curve versus position allows me to work out the exact point of contact afterwards, thus giving me the required accuracy.

I think the clue to all this is the way the axis is coupled to the motor.  I reckon this is absorbing a certain amount of tracking error and as long as I don't drive the axes together with great speed os allow a huge following error, things should be fine.  I think I'll use 60 or 100 as my limit, then things should be OK.

A lot depends also on HOW the surfaces come into contact.  Edge on edge will break most things, but as long as they're more or less parallel to each other, the tolerance seems to be quite a bit higher than I originally thought.

Thanks again.

Shane.

[shoneill]

To follow up on the comment on my own question.....

Why can't I define a maximum following error as a stop criterium in the motion control software.

I currently have to loop fast, reading the following error and manually stopping the axis if anything happens with the following error.  Of course the accuracy of this is bound to windows (oops) so it would be really cool if I could define this as an "official" stop criterium for the move.

I can't be the only one who could use this surely.....

Shane.

[Jochen]

Shane,

in fact I have never come accross this requirement and I'm dealing with motion control for more than 8 years now

Still the idea is not bad at all. In addtion to setting an absolute maximum following error the board should calculate also the first derivative of the following error to detect the rate of change. In the board's settings the user would be able to set a "maximum following error rate of change" parameter.

This feature is not implemented, yet but the more I think of it the more I like it. I will post this as a product improvement suggestion for our R&D folks. Of course this won't be added in near future so unfortunately it won't help you with your current task.
By the way: Have you ever heard about the NI SoftMotion development module? This module allows you to create your own motion controller based on LabVIEW Real-Time and/or LabVIEW FPGA. With SoftMotion you can add every feature that you like but depending on your application it might be slightly oversized.

Jochen

[Jochen]

Shane,

I have just stumbled over this sentence:
"Why can't I define a maximum following error as a stop criterium in the motion control software."

So just for the case that you are not aware of this: Of course you can do that. Here is the setting in MAX:




Jochen

Message Edited by Jochen on 03-22-200604:27 PM

[shoneill]

Jochen,

Thanks for your replies.  Regarding the last post, what driver version and what MAX version are you using.  I'm stuck with LV 6.1 on Win98 contrary to what my sig says (Stop sniggering ;)) so I don't know what I might be missing out on.

Also, I know I can read the current following error, I can set a following error as a stop criteria but this only stops the axis as soon as the following error is BELOW the set value.  What I want is the opposite, or a combination of both.

Perhaps the setting you've outlined in the picture does exactly that, but I'd be happy if you could clarify a bit more.

Thanks again

Shane.

PS while you're at it, can you give in a R&D request for proper named axes like the DAQ named channels?

Message Edited by shoneill on 03-24-2006 12:13 PM

[Jochen]

Shane,

the screenshot was taken from NI-Motion 7.2 and MAX 4.0 but the following error setting was also available in earlier versions. With this setting you can't configure a move complete condition but the axis will stop immediately when this limit is hit so it might do what you want. In fact the axis is killed. That means that in this case the inhibit output for this axis becomes active provided that it is enabled in your settings. At least the move will be stopped.

In your case it might become a bit tricky to set the following error limit to a reasonable value as your axis operates already very close at the limit during normal operation. That's why I have thought a "rate of change limit" for the following error would be a nice feature as a high rate of change should clearly indicate if an obstacle was hit.

I have generated another Product Suggestion from your request (axis names).

Jochen

[shoneill]

Jochen,

Again thanks.  I wasn't actually aware of this following error setting.  It's not quite what I'm after, but it's half the battle.

Thanks also for generating the product suggestions.

Have a nice weekend

Shane.