Position/Velocity Measurement

[kamenges]

Originally posted by Peter Nachtwey:
What time is being measured? The time the pulse takes to get to the maganet, the time the twist takes to get back or both?

Effectively you are measuring both. But I would think that the time it takes for the stress pulse to travel from the magnet to the sensor head would be several orders of magnitude longer than the time it takes the magnetic field due to current to reach the magnet. So the domonant time would the the stress pulse time from the magnet to the sensor head.

Originally posted by Peter Nachtwey:

So how does one synchronize to a analog MDT?

I don't know that you can. I've never used any synchronization method if one exists.

Keith

 

[Peter Nachtwey]

The pulse goes down the rod at the speed of light or something close to it so the pulse gets to the magnet almost instantly. It is the time it takes twist to come back to the MDT head that is being measured. This twist comes back at about 9.1 microseconds per inch. This time will always vary depending on the position. What should NEVER change is the time between sending the pulse toward the magnet since is it pulse that detects the position of the magnet.

We do all of this in hardware so there is no jiiter due to software.

 

[Alan Case]

As someone started to mention earlier if you set the CLX analog input to give CST time stamped data, (you need to use the high speed analog card)then the analog position will arrive with a timestamp correct to a microsecond.
No need this way for a periodic task, though if you dont have the fast input card then the periodic task is the best way. It all depends on the accuracy the original poster required.
Regards Alan Case

 

[Alan Case]

The logic to perform this lends itself to a "add on instruction"
There have been quite a few things lately where I wish i had a preconfigured instruction to perform a task. I will add this to my wishlist and wait for version 16.
Regards Alan

 

[Peter Nachtwey]

Not good enough unless you can measure over long periods of time. The control logix has an operating system where interrupts must be disabled for many microseconds plus it takes many microseconds for the operating system to respond. During this time the object moves. One MUST control the interval at which the pulses are sent down the rod.

No one has mention recirculations yet. What are they? How do they adversely affect position readings?

There is a quantizing error caused by the resolution of the timer. A 1 microseond delay results in a about a 1 microsecond / ( 9.1 microseconds / inch ) = about .111 inches. On the average you will be off by 1/2 of that if your timer measures microseconds. We use a 240 Mhz timer now.

There is also a 'beat' frequency type of error. While accelerating and decelerating the object will move through different speeds where the quantizing has more affect.

 

[Alan Case]

Hi Peter. I was mistakenly under the impression that the sensor was a linear potentiometer style. I thought you guys were having a semi off topic discussion about how a magnetostrictive linear transducer works.
To all please take my earlier post in the context of a simple 4 - 20mA current loop type input.
Regards Alan

 

[kamenges]

[Originally posted by Peter Nachtwey:

Not good enough unless you can measure over long periods of time.[/quote]

That's why I asked Alaric what his task rate was. The longer you make the measurement period relative to the sources of timing errors the more accurate you will be. But again, this only works for slow moving items that don't require a high speed update frequency.

Originally posted by Peter Nachtwey:

One MUST control the interval at which the pulses are sent down the rod.

Is this necessarily true? Isn't it just as effective to know the actual time beween interrogation? Granted, this is just for measurement purposes and doesn't speak toward being able to use this value as part of a control system. But, strictly speaking, simply knowing the actual distance delta over the actual time delta should give you the same result as knowing the actual distance delta over a triggered time delta.

Originally posted by Peter Nachtwey:

No one has mention recirculations yet. What are they? How do they adversely affect position readings?

The stress wave created by the magnetic interaction will travel both ways down the interrogation conductor. I believe when this wave hits the non-head end of the sensor it will be reflected and sent back toward the head end. The same will happen to the wave sent toward the head end. I believe the add mechanical dampers to the conductor mounts but you still need to wait long enough between successive interrogations to allow these to die out.

Originally posted by Peter Nachtwey:

We use a 240 Mhz timer now.

I figured that would need to be pretty high to get the accuracies you need. I was thinking 100 MHz minimum.

Originally posted by Peter Nachtwey:

There is also a 'beat' frequency type of error.

In a rotary cuttoff knife project I was involved in several years ago we saw a similar phenomenon with an incremental pacer encoder. The knife cylinder system would make this varying pitch whining sound. The pitch was related to line speed, not cylinder speed. The whine would go through several cycles between 0 and 1000 FPM, with cycles stacking up much more closely at low speeds. It really was kind of a cool sound. Made you think the goofy thing was haunted.

Keith

 

[TConnolly]

I use a 500msec period. I'm also measuring velocity on huge hydraulic rams (12,000 metric tons) which do not move quickly.

Keith's point about using the analog input time stamp is interesting. It could be a good approach. It really depends on the accuracy that is needed. For us it works very well.

It it were a small bore fast acting long stroke cylinder then some of the issues Peter brought up might be a problem.

 

[kamenges]

Originally posted by Alaric:

I use a 500msec period.

I've done digital differentials on analog MDT signals at about a 20msec rate with a CLX. That got pretty jumpy. By the time I added the filtering to calm it down I would have probably been just as far ahead increasing my sampling time. Luckily signal stability wasn't extremely critical in my application.

Keith

 

[Peter Nachtwey]

Velocity and acceleration is critical for my( customer's ) applications.

I must know the velocity and acceleration at each scan which is usually about every 0.5 or 1.0 milliseconds. This data can not be filtered in the ways that have be discussed on this forum. There must be no phase lag. The reason for the fanatical question for accuracy is that the velocity and acceleration are necessary for the PID calculations. The derivative gain is basically a gain that is multiplied by the error between the target and actual velocity. The second derivative gain is multiplied by the error between the target and actual acceleration. With out accurate speeds and accelerations on can't use the derivative gains.

I have no idea how our customers will use our controller. That is why I must be fanatical about how velocities and accelerations are calculated.

Alaric, it is those big presses that would benefit the most from more accurate velocity and acceleration measurements. Even the press manufacturers want to go faster and faster.

 

[kamenges]

And there it is. Not only is Peter concerned with accuracy he needs an extremely high update rate. So sources of jitter that most of us don't worry about are a big deal to him. In addition Peter needs to know that his feedback data is 'fresh' at the beginning of his servo loop closure. That's why my point in post #22, while possibly as accurate, still doesn't meet Peter's needs. Accurate data that isn't in time with the loop closure is no better than inaccurate data.

Now to push this completely off topic:

Originally posted by Peter Nachtwey:

The derivative gain is basically a gain that is multiplied by the error between the target and actual velocity. The second derivative gain is multiplied by the error between the target and actual acceleration.

So why do you do that as opposed to taking the first and second derivative of the instantaneous error times their respective gains?
Keith

 

[Peter Nachtwey]

Do the math

Now to push this completely off topic:

It all depends on why one needs to compute velocity and what the specifications are. They were never specified.

So why do you do that as opposed to taking the first and second derivative of the instantaneous error times their respective gains?
Keith

Given:
The feedback resolution is .001 inches
The sample rate is every .001 seconds

What is the best velocity and acceleration resolution? Is this good enough?
What happens to the PID as the system decelerates from 10 inches per second to 0. At 9.7 inches per second the motion controller will see 10 counts most updates and 9 the rest. At 9.6 inches per second the motion controller will still see 10 counts but not as often. During these times, what happens to the speed and acceleration calculations?

I have a Mathcad worksheet that shows how the control output gets very noisy as the system ramps down when the actual speed is not an even multiple of counts per time period. As the system moves through 9,8,7 etc inches per second the sampling is in synch with the counts. At the speeds in between the output becomes rough unless the resolution is very high.

 

[kamenges]

I've got to be looking at something wrong.

Given the position resolution and sample rate the best you can do for instantaneous velocity resolution is 1 inch per second. But the best acceleration resolution I come up with is 2000 inches per second squared.

So one of three things is happening:

1) I'm calculating these values wrong (quite possible)
2) The control output IS actually very noisy (not likely)
3) You are doing something across multiple samples to produce a true value.

Keith

 

[Peter Nachtwey]

I've got to be looking at something wrong.

Given the position resolution and sample rate the best you can do for instantaneous velocity resolution is 1 inch per second.

Yes.

But the best acceleration resolution I come up with is 2000 inches per second squared.

Actually 1000 inches per second per second.

2) The control output IS actually very noisy (not likely)

If Kd = .1666 volts/(inch/sec), then an 1 inche/sec 'error' would result of .1666 volts of 'noise' on the output.

If Ka= .01 volts/(inch/sec^2) then and error 1000 inch/sec^2 results in an output of 10 volts. This is why you rarely see a second derivative gain being used, but you may in the future.

This 'noise' isn't really noise. It is errors due to quantizing.

BTW, the gain values are taken from a system that has a bandwidth of only about 2.5 hz which isn't very high. If the gains were higher the quantizing would affect would be higher yet.

3) You are doing something across multiple samples to produce a true value. Keith

No, just the data from the state before.