Calculate Revolutions from VFD RPM Feedback

[rzuhair]

Hello Forum,

I am being told to implement position feedback mechanism for a Winch which does not have encoder mounted on it. I am running the Winch in Open Loop mode via a VFD. The PLC in use is the s7-1500. I am trying to calculate the number of Revolutions it makes going off only the Motor RPM feedback.

What I tried is: Executing a routine from OB35 at 100ms interval and in that routine I was dividing the RPM by 60 to get Revolutions Per Second (RPS) and then Multiplying it by 0.1 so it is Revolutions Per 100 MilliSeconds. If there was any movement, then I was adding or subtracting this Revs per 100 ms data accordingly to the Total. I tried this test in the lab where I have a motor with encoder but the problem is I am off. When the 1024 PPR encoder shows 1024 pulses, my Revolutions counted is like 0.7 or 0.8.

Is there any precise way you guys can suggest me for this?

Thanks.

 

[JRW]

Are you familiar with TO’s or technology objects?
My first thought is using a virtual master. Take your vfd speed actual and feed to the vm
The vm mechanics can be scaled in any way you need. Use linear not rotary
Play around with it , you can simulate too without using real hardware

 

[rzuhair]

Are you familiar with TO’s or technology objects?
My first thought is using a virtual master. Take your vfd speed actual and feed to the vm
The vm mechanics can be scaled in any way you need. Use linear not rotary
Play around with it , you can simulate too without using real hardware

I did take a look. which TO should I use? Under Motion Control, there are:

TO_SpeedAxis
TO_PositioningAxis
TO_ExternalEncoder
TO_SynchronousAxis

 

[JRW]

Positioning will work
Experiment

 

[VAN]

I am being told to implement position feedback mechanism for a Winch which does not have encoder mounted on it. I am running the Winch in Open Loop mode via a VFD. The PLC in use is the s7-1500. I am trying to calculate the number of Revolutions it makes going off only the Motor RPM feedback.

Is this for school or a real application?

Why can't you use sensors or other devices? You say winch... does this account for stretch etc?

This sounds like you wont have repeatable results, especially if weight changes.

 

[rzuhair]

Is this for school or a real application?

Why can't you use sensors or other devices? You say winch... does this account for stretch etc?

This sounds like you wont have repeatable results, especially if weight changes.

This is for a real application. My company tech tried for days so we could get it in Closed Loop control with an Encoder but for some reason, when the encoder was mounted, it just didn't read pulses so I am left with this approach. Even though there is isolation between motor shaft and encoder, it failed to read.

I just want to achieve whatever accuracy I can as the customer insists on implementing some control for it. And yes, I do understand the results won't be repeatable amounting to changing weight and motor slip. However, I am having them calibrate to 0 every time they come down to the floor.

 

[I_Automation]

How about a rotary encoder with a wheel that rides on the cable leaving the hoist. A second wheel holding the 2 wheels tight in contact with the cable.

The OD (or PD if it's a shaped wheel to grip the cable) of the wheel on the encoder will be the wire feed length every revolution.

 

[Manglemender]

Closed loop vector control would definitely be better.

Rather than integrate speed over time, monitor the encoder position. From memory, the encoder position is stored in the drive as a double int. Every scan: Read the encoder position and subtract the position stored from the previous scan and sum the result with the distance moved, store the current position for use next scan.

Do all the mathematics in double ints to handle the wrap around. Scan rate must be sufficiently fast that the encoder cannot wrap around between scans.

I used this technique years ago to write a Phase Gear function block for an S7-300 plc.

The suggestion from @I_Automation about using a rider wheel encoder may be a good solution so long as the wheel doesn't slip.

Either way be careful what the end user might want to do with a potentially unreliable height indication!

Nick

 

[AustralIan]

"The encoder I bought isn't working so I'll just program something less accurate."
If you can't get an encoder to work... then you really should learn how to get an encoder to work. Call the guy that sold you the encoder and the guy that sold you the encoder interface.

 

[lfe]

What I tried is: Executing a routine from OB35 at 100ms interval and in that routine I was dividing the RPM by 60 to get Revolutions Per Second (RPS) and then Multiplying it by 0.1 so it is Revolutions Per 100 MilliSeconds. If there was any movement, then I was adding or subtracting this Revs per 100 ms data accordingly to the Total. I tried this test in the lab where I have a motor with encoder but the problem is I am off. When the 1024 PPR encoder shows 1024 pulses, my Revolutions counted is like 0.7 or 0.8.

Thanks.

Assuming that an induction motor is going to rotate at the revolutions of the supply frequency is false, that is why it is called an asynchronous motor.

In addition the starting and braking times are not instantaneous, and the winch will not travel the same distance at the same time raising or lowering the load.

If you want to control the position the loop must be closed with a position feedback normally through an encoder.

 

[GaryS]

the best way to do what you want is with a quad encoder and high speed counter
with just using the vfd freq you still have the motor slip to consider and with time base you have motor acc and decc to account for you will never e the repeatability you need with out an encoder

 

[VAN]

I just want to achieve whatever accuracy I can as the customer insists on implementing some control for it. And yes, I do understand the results won't be repeatable amounting to changing weight and motor slip. However, I am having them calibrate to 0 every time they come down to the floor.

Well, for fun try just using a timer. Then if you wanted to "get creative" you could add some kind of weight parameter that is entered on the HMI that could +/- the time the motor runs.

This is just a "fun" solution to at least get something going but like others say encoder would be great. But how a bout other options, like laser measurement or say cognex or hell here is https://www.kellertechnology.com/blog/7-types-of-sensors-for-object-detection/ 7 types of sensors. "Other devices" are almost limitless.

 

[JRW]

rzuhair

I played around with using a virtual master.
Granted, an encoder is better and more accurate
But what you originally asked for , a VM could work for your simulated length

I think it would work better if the VM controlled your VFD with the velocity actual (scaled for your vfd) rather than the vfd controlling the vm

Let me know if you want this project for your lab testing- its V16 and uses the Laxis blocks

https://support.industry.siemens.com/cs/us/en/view/109749348



Heres something else you might consider
But it uses G120 drives and profinet
Just something to look over

https://support.industry.siemens.com/cs/us/en/view/109767951

 

[jraef]

As others have said, the frequency that the drive tells you is what it is TELLING the motor to run at. In Open Loop control, you have no idea what speed the motor is ACTUALLY turning. As the load changes, so does the motor speed. In fact if you STALL the motor, the VFD will tell you it is giving it xx Hz, but the motor may not be moving at all! Bottom line, using the VFD frequency output in an Open Loop control method is all but useless.


In Vector Control, the VFD is watching the rotor move because it creates disturbances in the magnetic fields of the stator coils, which has effects on the current going to those stator coils and the VFD is looking at the coil current all the time. So a VFD in Vector Control does have a better idea of the ACTUAL motor speed. Sensorless Vector Control (SVC) still uses an "approximation" because of the way it does the sensing. Flux Vector Control usually needs the encoder feedback, which is absolute (to the resolution of the encoder), but some higher end drives are now actually capable of "Encoderless Flux Vector Control, which is a quantum leap more accurate than SVC and does not need the encoder feedback..

 

[Peter Nachtwey]

I SMH and wonder.