VFD encoder PPR 1

[sensij1]

The question in general is:
When using a PPR to provide feedback to a VFD, is there a maximum value above which higher PPR can actually hurt?

I understand that a higher frequency signal may be more prone to error than a lower frequency signal, so that is one aspect to consider. In this specific case, I'm using an ABB ACS850 drive in DTC, with a FEN-31 encoder module that drives a 15 V signal and can process up to 300 kHz, according to the data sheet.

A 10000 PPR encoder will generate a 292 kHz signal at max speed, and the cost relative to a "standard" 1024 PPR encoder is insignificant. The motor is turning a 100:1 speed reducer, which is driving the master speed roll for a forming mill. Speed fluctuations in the drive may translate to tension fluctuations in the mill, although I would guess that the reducer substantially dampens the response. I would also imagine that at some point, the speed reference filter in the VFD (currently set at 8 ms) and the speed controller PI settings may become more important than encoder counts, but I'm not sure at what point that is.

I currently have a 600 PPR encoder installed, and the speed control difference with and without it (using the DTC speed estimate instead) is observable. The encoder cable is about 8 ft long, twisted pairs for differential A/A' and B/B' signals, with an overall shield grounded at the VFD. I've just sent an inquiry into ABB, but thought I would ask here as well for some real-world feedback.

 

[mikekilroy]

NO (you already checked that you will not exceed the vfd or encoder max freq response)

I understand that a higher frequency signal may be more prone to error than a lower frequency signal, so that is one aspect to consider.

NO, false. You are using a quality vfd, there is NO concern since you have differential signals. Whoever told you this is flat wrong.

Now to the meat of your question: will a 10,000ppr encoder give you better performance than the present 600ppr one?

NO. If someone told you that they are again wrong.

Of course sensorless will perform poorer than the present 600ppr encoder. Now this was a hi performance servo requiring 50% of motor rated peak torque output changes in less than 4 msec, sure, higher than 600pr will help a lot. but on a vfd with such hi inertia motor and mill with super hi inertia roll load, there is NO WAY you will see ANY improvement in using a 10,000ppr encoder instead of 600ppr - ok, I may exagerate, you MAY see 0.00021% improvement in whatever term you are measuring....

Don't waste your time or money on this.

http://www.KilroyWasHere<dot>com

 

[sensij1]

Great, that's just the response I was hoping for. In terms of load inertia, the motor is 1.5 HP and the roll it is turning (through the speed reducer) is 18" in diameter and weighs about 100 lbs. The inertia is probably still high enough to wash out any improvement from the encoder, but maybe isn't as high as you were imagining.

I've been looking at the echo of the encoder to judge the speed stability. With the 600 PPR encoder, it is holding speed around 0.2% or so. That is somewhat worse than what is suggested on page 22 in the link below, but it may be that in this application that is the best I'll see.

http://www05.abb.com/global/scot/sc...83e941d57852571c3006b0194/$file/speedtorq.pdf

 

[sensij1]

Ah, I think maybe I was defining speed regulation incorrectly to compare it to that chart. The same white paper defines it this way:

The speed regulating capability of any constant speed motor or adjustable speed
drive is defined as the maximum speed change as a percentage of base speed that
results from increasing the load from 5% of rated load (essentially no load) to full
load while holding constant all other variables that might cause a speed change.

I can see that is different than looking at the speed stability under a nearly constant load, which is what I've been doing.

 

[Skogsgurra]

I agree totally with mikekilroy!

I helped SKF to sell their Sensor Bearing Unit many years ago. SKF is mainly a mechanical engineering company and there were some difficulties making the salesforce understand hoe useful the sensor bearing actually is. I think that they have got it now.

The presentation is old, yes, and has lots of details, yes. But it covers most aspects on rotary encoders. Slide 5 from the end is about what resolution you need. It was valid then - and it is still valid. Go read it here:

http://www.gke.org/presentationer/files/SKF Sensor Bearing 1a.pdf

I have been working with paper machine drives - you need high precision in a newsprint machine running at 1800 m/min (around 6000 FPM) and winders with threading speed being lower than 1% of running speed. I have been using 500 PPR and 600 PPR encoders for that. No problem. The 1024 PPR used today is totally adequate. Anyone saying anyting else is just another salesperson that doesn't really know what he is peddling.

There is also the cable capacitance aspect. A single-ended 15 V encoder pulse is quite robust. And some filtering at the receiving end (a 10 nF capacitor is usually all you need) makes it even more so. If you go to 10 kPPR, you need differential pairs to handle the signals and you cannot filter much. So, whatever the "specialists" are telling you - don't listen.

Gunnar Englund

http://www.gke.org

--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

 

[sensij1]

Ok, thanks for the suggestion. I had seen a few of your posts about sensor bearings in the archives when I searched this topic before posting. I had not been aware of them, but I can think of a few places where they would be a much better fit than traditional encoders. I'm definitely filing that away for future reference.

I guess the only other reservation I have is that when I'm monitoring the motor torque under light load, very little more than what is just required to turn the speed reducer and master roll, the reported torque seems jittery. For example, running at 500 RPM results in a torque value that jitters between 9% and 15%. Is it just that asking the 1.5 HP motor to run at 0.08 HP (~5% capacity) is too far from where it is optimally tuned?

If it helps to know, the refresh time / data freshness of the display is around 100 ms. The drive is capable of communicating more quickly than that (<10 ms), but I haven't found a reason to pursue more frequent polling. The torque value is communicated digitally via Modbus TCP from the drive to the display. The drive does not have a digital filter that can be applied to this "Actual Torque", although I can report a smoothed torque if I point one of the I/O registers to a "display" parameter not used in the control calculations. Is the torque fluctuation under these conditions typical / healthy? If so, I'll just ignore the jitter and pay attention to the smoothed value. I am interested in the torque because it can provide feedback about the consistency of the forces in the forming mill.

 

[itsmoked]

The jittery torque can be the tuning. The PID that controls the spindle speed may not be happy at no load. A slight change in the tuning could solve that but you have to then watch the loaded tuning.

Keith Cress
kcress -

http://www.flaminsystems.com

 

[Skogsgurra]

It is also about the resolution of the torque measurement.

I once had a case where the A/D for current measurement (used to calculate torque at the end of the day) was 8 bit.

Of these eight bits, seven were used in either polarity. Also, there was a 4x overcurrent ability (you lose two bits there). So, the actual resolution was five bits, which translates into 100/32=3% of rated torque.

It was impossible to run that drive at light loads. The action was more like an ON/OFF controller and no tuning could make the drive behave well. We had to change the drive to be able to run the machine at low loads.

Lesson learned: It is sometimes more important to have good resolution in the torque loop than in the speed loop. The former is often forgotten and the latter gets too much attention.

Gunnar Englund

http://www.gke.org

--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.

 

[mikekilroy]

Not necessarily


You can learn little from 100ms resolution other than what avg and max min values are.

You can also learn little from 10msec resolution. To get data you could use you need <about 2msec max. Then you can see REAL current rather than simply aliased current. So to get this you need the drive to scope it for you and send you the data AFTER it records it. Your ABB likely has this capability.

Then with this data you can see IF there is an issue with the current loop oscillating, velocity loop oscillating, o no issue at all.

With your reported 9-15% current range I would predict you would find NO oscillations but rather just the drive changing the current as it should in response to your feedback - perfectly normal.

9-15% is a perfectly nice range for current hash; without it, your drive would not be holding speed so well - it is how it all works.

http://www.KilroyWasHere<dot>com

 

[sensij1]

This particular drive won't do much more than collect data on min, max, and average. It can also create a histogram showing the distribution of current readings in 10% buckets, but that isn't what I'd need either. I've checked the manual, and setting the communication speed to "fast" will bring the read/write time down to 0.5 ms, at the expense of more CPU load. If I modify my communication software for this purpose, I might be able to capture it quickly enough to be useful. It sounds like I'm out in the weeds, but I'll pursue it just to satisfy my curiosity at this point. Evening / weekend type work.

One other observation is that every time I try auto-tuning the PID with the preset control types (smooth, middle, or tight) for this light load condition it errors out before completing. The manual doesn't offer much to explain why. Instead of the preset types of auto-tuning, there are also user-enterable fields for tuning bandwidth and damping that I haven't tried playing with. The auto-tuning can ignored completely and PID values, weights, and filters can be manually set. I don't expect to go down that road unless something shows up in the data log that suggests it would be worthwhile, which seems unlikely.

Thanks for sharing some of your knowledge about this with me, it really does help calibrate my expectations for what the system should be doing. The process has worked well enough for 20 years on a DC motor with an open loop SCR drive, so I'm sure it is already running better than that.

 

[sensij1]

With my hardware, the quickest average cycle time I've been able to get for capturing the speed and torque is around 3.8 ms. I logged at least 30 sec of running under the conditions I described above, and got the following:

Estimated speed feedback
Avg Speed = 411.81 RPM
Std Dev Speed = 1.67 RPM
Avg Torque = 15.0%
Std Dev Torque = 1.98%

600 PPR feedback
Avg Speed = 411.81 RPM
Std Dev Speed = 0.46 RPM
Avg Torque = 11.5%
Std Dev Torque = 1.76%

1024 PPR feedback
Avg Speed = 411.81 RPM
Std Dev Speed = 0.52 RPM
Avg Torque = 11.2%
Std Dev Torque = 1.76%

The speed setpoint was (obviously) 411.81 rpm. The 1024 PPR encoder was from the maintenance pile, with more wobble to it than the 600 PPR encoder had. The distribution of speeds from the 1024 encoder was skewed, which I'm guessing was somehow due to the wobble. The time series on the 600 PPR did show some cyclic content, but with a period of 3.75 sec, I'm thinking it is something higher frequency that is aliased. That is not a period that corresponds to anything I can see on the motor or speed reducer.

The motor shift that the encoder is mounted to has 0.002" runout. The differences in average torque surprised me, but otherwise, it looks like the results are consistent with everything you've shared with me in this thread.

If you are interested, a link to the histograms is here. The first three slides are the speed data, the next three slides are the torque data.

 

[Skogsgurra]

Thanks for the data, sensij1. LPS for you!

There is no obvious difference in speed and torque variation between the 600 and the 1024 PPR encoders. It is always nice to see one's opinion verified.

I even think that you can use the Sensor Units without much problems.

Gunnar Englund

http://www.gke.org

--------------------------------------
Half full - Half empty? I don't mind. It's what in it that counts.