Position/Velocity Measurement

I have an application where I am measuring the position of a hydraulic ram press. I have a Balluff Transducer that is giving me a 4-20ma signal to the Controllogix PLC. My customer has asked that I calculate a velocity on the Hydraulic Ram. Has anyone calculated this with a PLC with a Position Transducer? Let me know..

Velocity is distance traveled per unit time. You will need to keep track of a "last position" as well as the current position.

Set up a timer that resets itself at some convenient interval. Each time the timer resets itself, compute the difference between the current position and the "last postion". Divide the result by the timer interval. Then save the current position to the "last position" register for the next time the timer resets itself.

Curious

Does the press have different stamping speeds? If not then not sure why you would need velocity but on the linked page are 2 Excel files...One will calculate velocity and the other will calculate the natural frequency of a cylinder...ie the optimum extend and retract speed. http://www.patchn.com/hydrauli.htm

The one thing you have to be careful with when doing calculations of a hydraulic cyclinder is that extend and retract speeds will or may differ...EX: extending and stamping may take .75 secs but retract may not take but .5 sec.

The other thing is verify what they actually want; velocity is basically speed in one direction, the formula is v = d/t. Do they want to know the velocity when its going up or down, OR do they actually want to know the speed...ie the cycles per sec?

BTW: I am not strong on hydraulic presses.

At what point ? maximum (peak) or average ?

If you want cycle time , then the stroke/valve open->valve close will do .

Since you mention a position transducer , then the same question applies , at what point ? or an average ? or at what sample period ? 1 second , 5 seconds , 250mSeconds ?

Use a periodic task. That is how I do it and I also use Balluf transducers for determing ram velocity.

You can hard code the task period, but you can also determine what the task period is programmatically with GSV(TASK, Velocity_Task_Name, Rate, TaskRate_MicroSeconds) where Velocity_Task_Name is the name of your periodic task and TaskRate_Microseconds is a DINT tag to which the task execution period is stored in microseconds.

I have a UDT that contains the tags needed for the ram piston and velocity as well as other ram control tags. Included in the UDT are the following tags:
CurrentPos Real Current Position of the hydraulic Ram in mm
LastPos Real Position of ram in mm last time velocity was calculated
Velocity Real Velocity of Ram in mm/sec.

I create a tag of the UDT type for each ram.

In ST the routine looks similar to this:
GSV(TASK, Velocity_Task_Name, Rate, TaskRate_MicroSeconds);
Ram.Velocity := (Ram.CurrentPos - Ram.LastPos)/TaskRate_Microseconds/1000000.0); //Units/Sec
Ram.LastPos := Ram.CurrentPos;

Alaric-

Do you have any noticeable issues with jitter? The rate attribute you are reading is the specified interrupt interval for the task. This is not necessarily the true time between interrupts. I would think doing a difference on the WALLCLOCK attribute would give you a more correct reading.

But in the greater scheme of things that probably isn't a big issue either relative to the device update rate. I don't know that you have any particular control over the update point. So the jitter in your data is probably much greater than the jitter in the interrupt call.

And all this washes out anyway if the ram is moving very slowly and you can filter the result. I'm just wondering if you are seeing any jitter issues with this.

Keith

We measure positions and velocities of hydraulic rams all the time

Why? It will be hard to do with what you have got.

Depends what his boss thinks he wants to see , all the time people want to achieve something with a pile of junk - at least this guy has half a chance with the equipment he has .

plcengineer,

I dont know the CLx instruction set so the basic concept is as follows:

Your PLC likely has a clock pulse in the form of a spicific contact, for 1 second, .5 second, .100 second etc.. Presuming the ram is traving in the direction that will increase the value..

PD

---||-------------LOAD

1 sec. POSITION (CURRENT transducer value)

OUT Mem 1 (save this value) 

PD

--|/|-------------LOAD

1 sec. POSITION(Current transducer value)

Subtract Mem 1.

OUT Mem 2. 

 

In Mem 2 you now have the distance traveled in 1 second. You didnt mention the resolution & units of the tranduceror, or the desired speed result. (fpm, fps, mps etc...) or if you need to constantly update for a dynamic display, or trap the highest speed etc..So just take the units in Mem 2 and convert it to whatever you need.

kamenges said:

Alaric-

Do you have any noticeable issues with jitter? The rate attribute you are reading is the specified interrupt interval for the task. This is not necessarily the true time between interrupts. I would think doing a difference on the WALLCLOCK attribute would give you a more correct reading.

But in the greater scheme of things that probably isn't a big issue either relative to the device update rate. I don't know that you have any particular control over the update point. So the jitter in your data is probably much greater than the jitter in the interrupt call.

And all this washes out anyway if the ram is moving very slowly and you can filter the result. I'm just wondering if you are seeing any jitter issues with this.

Keith

Click to expand...

I haven't noticed any issues with the periodic task method. Velocity is an important process variable so the priority of the task is set fairly high. The slight variation between when the task is scheduled and when it actually runs is certianly less that what timer -vs- scan accuracy would be if the calcualtion relied on a timer in the continuous task.

Originally posted by Alaric:

The slight variation between when the task is scheduled and when it actually runs is certianly less that what timer -vs- scan accuracy would be if the calcualtion relied on a timer in the continuous task.

Click to expand...

I can't argue with that. Your method is certainly more accurate than that.

What are you running for a task rate? Also, what is your analog update period and how does that match up with the sensor update period? When I have done this on the CLX platform in the past I have used the free-running timestamp from the analog input for my time delta and run the calculation in the continuous task whenever I detected a change in the timestamp. That works pretty well but I think I get some jitter due to mismatches between analog input reads and device updates.

Keith

Steve Bailey said:

Velocity is distance traveled per unit time.

Click to expand...

What time?

I am often ask how well we can regulate velocity. We are given specifications such as 0.5%. Does any body know what is wrong with this specification?

BTW, does anybody know how that Balluff rod works? This is important.

I am writing an article on this very topic in an up coming Hydraulics & Pneumatics magazine.

Velocity specifications given in percent are usually relative to rated speed. So 0.5% speed regulation at a running speed of 0.5% max speed isn't so good.

I'm assuming Peter is talking about the magnetostrictive sensors from Balluff. They work by sending an interogation current pulse down a conductor running the length of the device. The magnetic field formed around the wire interacts with a magentic field from a magnet attached to whatever you want to measure the distance to. This interaction causes (I believe) a torsional stress in the conductor. The speed of the stress wave through the conductor is a very reliable physical property of the conductor. By very accurately measuring the time between sending the interogation pulse and receiving the returning stress wave one can accurately calculate distance.

There is a start/stop measurement mode where the controller triggers the interogation pulse and the sensor responds with the receipt of the stress wave. This method will allow the controller to sync the measurement with the controller update, providing the most accurate time delta for velocity calculations.

Keith

Peter Nachtwey said:

I am often ask how well we can regulate velocity. We are given specifications such as 0.5%. Does any body know what is wrong with this specification?

Click to expand...

It doesn't specify a time period.
You can call out a .5% for position, but being that velocity is a derivative of position, you must specify a time interval as well as the spec for %.

Crocop got it right.

Keith is right about the synchronizing. So how does one synchronize to a analog MDT? It isn't enough to know the position. You must know when it is valid.

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?