Need help with winding application VFD speed control

[kamenges]

As you can see from the equations that are being referenced, the hard part about caculating diameter based on caliper is not the baseline equations. Even the equations that Peter linked to are just tweaks on the equations for the area of a roll face. The hard part is coming up with caliper.

But, you say, the operator enters that. But, alas, the operator will enter a spec value. The caliper will not be exactly that number. If the operator happened to enter the exact average AND the error distibution is Gaussian there isn't much of a problem. However, it is more likely that the actual caliper will spend significant time on one side or the other of the setpoint. All this time the caliper error will be integrating with respect to wraps, producing an accumulating diameter error.

In a torque based system this isn't a huge deal. However, in a velocity based system this can be completely unacceptable. Without some method of correcting for caliper variation the systems that count solely on caliper integration will not work effectively in a velocity based system. And, as Peter inferred, if the transmission losses are great enough a torque based system gets hard to implement. From past experience, anything over about a 25:1 gear ratio gets pretty hard to do purely in torque unless you have a very small build ratio (say 2:1 or 3:1). This all assumes you need a tension that stays within about +/-30%.

Peter, given the right options the PowerFlex 700S is more than capable of doing the job. The 700S can be optioned with the Logix control engine onboard, so it's just like programming a CLX processor. I have yet to use one but I've seen some demos and I think I like.

Keith

 

[SilverLoop]

As you can see from the equations that are being referenced, the hard part about caculating diameter based on caliper is not the baseline equations. Even the equations that Peter linked to are just tweaks on the equations for the area of a roll face. The hard part is coming up with caliper.

But, you say, the operator enters that. But, alas, the operator will enter a spec value. The caliper will not be exactly that number. If the operator happened to enter the exact average AND the error distibution is Gaussian there isn't much of a problem. However, it is more likely that the actual caliper will spend significant time on one side or the other of the setpoint. All this time the caliper error will be integrating with respect to wraps, producing an accumulating diameter error.

In a torque based system this isn't a huge deal. However, in a velocity based system this can be completely unacceptable. Without some method of correcting for caliper variation the systems that count solely on caliper integration will not work effectively in a velocity based system. And, as Peter inferred, if the transmission losses are great enough a torque based system gets hard to implement. From past experience, anything over about a 25:1 gear ratio gets pretty hard to do purely in torque unless you have a very small build ratio (say 2:1 or 3:1). This all assumes you need a tension that stays within about +/-30%.

Peter, given the right options the PowerFlex 700S is more than capable of doing the job. The 700S can be optioned with the Logix control engine onboard, so it's just like programming a CLX processor. I have yet to use one but I've seen some demos and I think I like.

Keith

these drives are equipped with a control engine board. i was told that they will function as a servo, but i am not far enough along with the project to confirm that.

perhaps someone who is familiar with this drive and the control engine may have an idea of how it may be used in this application.

 

[kamenges]

Originally posted by SilverLoop:

perhaps someone who is familiar with this drive and the control engine may have an idea of how it may be used in this application.

You may be putting the cart a little ahead of the horse here. The problem will not be the programming. With the exceptions of available memory, processing speed and fieldbus master access, the DriveLogix package will look and feel like a ControlLogix processor. If you have used CLX before you will be pretty comfortable with DriveLogix.

The big questions in my mind have to do with the basic mechanics of the application. Do you have enough information coming into the processor to make intelligent decisions on the state of the machine? Is it really that critical? How fast are you going? How much tension variation can you live with? What is your build ratio? Do you have the freedom to add components if needed?

I think you have all the processing capability you need. The question is do you have everything on the machine that you need?

Keith

 

[DickDV]

Trying to construct your own winder algorithms to acheive constant tension is doing it the hard way. Most drive manufacturers including AB have their own custom winder software which takes a lot of the difficulty out of the picture.

Generally, winder software will need to be told the diameter of the core, the caliper of the sheet, the line speed, and the desired torque and the software does the rest. Some of the more sophisticated packages also can take a material density input to calculate roll mass which is handy for holding constant tension thru speed changes.

I'd definitely investigate the availability of this software before trying it on your own. Center-driven winders and unwinders can be bewilderingly complex to set up properly.

 

[russrmartin]

In my experience, center driven unwind and winder apps are best off addressed in the following way, and there are other posts on this site that address this type of application.

Method 1 is to provide a dancer between the "line" and the unwind drive, and or winder drive. This dancer is then used to trim the speed of the unwind or winder drives according to it's position.

Method 2 is provide a fixed surface roller to which an encoder is attached. This fixed surface roller measures the actual feet of material being unwound or wound(depending on the end of the process). The feedback of this roll is then used to trim unwind/winder speed.

Your problem is a common problem with all center drive applications. At our site, we have tried 3 or 4 times in the last 3 years to work around this problem, to no avail. We have even tried using lasers to sense the diameter and adjust speed according to said diameter, but this can be a problem if materials are threaded up differently(roll off the top or the bottom). IMHO, rather than cause yourself headaches trying to make something extremely complicated work, I would follow either method 1 or 2 above.

The torque mode option is interesting, but has never worked for us due to some fragile webs. We've always had a problem stretching the web at some point due to erratic drive behavior. Every one of our apps at the current moment has either a fixed surface unwind/wind roll, or a dancer. Good luck.

Russ

 

[markhommer]

Another way to calculate the roll diameter is to measure the amount (length) of material that has been wound during a revolution of the winding shaft. The equation is then simply Roll_Diameter = Length / PI. Where "Length" is amount of material added during the revolution. To do this you would need to mount a target (or flag) to the winding shaft and use an inductive prox switch to sense the flag at each rotation. You would use an encoder you could keep track of the amount of material during the rotation.

Another method for diameter measurement is to use a following arm, with roller, that rides on the winding roll. The following arm could be mounted to a encoder or potentiometer for position feedback. A calibration curve would need to be established to correlate the arm position to roll diameter.

Regards,
Mark.

 

[russrmartin]

In response to Mark's post, calculating diameter is rarely the main complication of a system like this. Once the diameter has been established, one still needs a reliable algorithm to adjust the speed continually to keep a continuous feet per minute process running at a steady speed.

Regards.

 

[kamenges]

This may be just a case of semantics, but I respectfully disagree with russmartin's assertion. In a system like this diameter is one of only two complicating factors, with the possibility of significant inertia changes being the other.

If we didn't need to worry about accurately defining changing diameter, this application wouldn't be any different that a pull roll application and we wouldn't be talking about this at all.

As I said, this may be semantics. russmartin said:

Once the diameter has been established, one still needs a reliable algorithm to adjust the speed continually to keep a continuous feet per minute process running at a steady speed.

One of the big things in the reliable algorith referred to above will be how the spindle speed command relates to the web speed as diameter changes. This is accompliched through the diameter calculator. If you can correctly espablish diameter at all times this becomes a much easier problem.

One point to keep in mind with Mark's length per rev example is you need to measure right at the winding mandril. If you don't, material strain due to tension will influence your calculation. Ideally you would have a measuring wheel riding right on the material on the mandril. Then again, if you have an encoder at the mandril surface you could do a direct trim based on the speed difference between the material supply conveyor and the mandril surface speed. No matter what, these should always be close to equal.

Keith

 

[DickDV]

In view of all of the above, doesn't winder software sound at least a little interesting?

 

[kamenges]

I would agree with DickDV's assertion in many cases. Having said that I've never run across a piece of winder software that I have been completely happy with. There's always something I want to do differently. In addition, most winder packages try to be everything for everybody so the manual looks like a copy of 'War and Peace'.

One big point relative to DickDV's statement is that you have to have done a few of these systems before you know what you want to do differently than the base winder software. For your first time around (and in some cases continually after that) you are better off using canned software.

That doesn't excuse one from trying to figure out how the canned stuff works. The only way I know of to start making something better is to know how what you currently have works.

 

[SilverLoop]

In view of all of the above, doesn't winder software sound at least a little interesting?

it does! i would rather not reinvent the wheel, but i guess sometimes it is difficult to know when you are starting to do that. most of us would not build our own plcs and vfds from scratch. when it comes to software, there is a tendancy to start reinventing algorithms that others have proven works. i guess that is why i posted the question, to find out what it is that i don't know...if that makes any sense!

 

[rsdoran]

i am using two AB Powerflex 700s AC Drives. both have local encoders connected. one drive will be used on a winding conveyor and the other one will be used to feed a fiberglass sheet onto the the winding conveyor.

i am having trouble coming up with a way to calculate the outer surface speed of the material as it is being wound and the outer diameter is increasing. i would like to make sure that i slow down the winding conveyor as the outer diameter increases and match the speed of the feeding conveyor to the outer surface speed of the material being wound. i would like to keep the outer surface speed constant.

any help would be greatly appreciated!

I have a question. In most winder applications you are feeding some form of continuous material onto a winder, in this application it was stated a fiberglass "sheet". I never saw if the fiberglass sheet was defined as a continuous material or not.

IF it is continuous then ignore this post.

If it is not then how would you develop tension while winding sheet material that was not continuous?

 

[SilverLoop]

I have a question. In most winder applications you are feeding some form of continuous material onto a winder, in this application it was stated a fiberglass "sheet". I never saw if the fiberglass sheet was defined as a continuous material or not.

IF it is continuous then ignore this post.

If it is not then how would you develop tension while winding sheet material that was not continuous?

actually, i have doubts about how well the setup will work. the sheet is cut just before being transported by a feed conveyor that will feed the smaller sheet onto the mandrel. the mandrel is perforated and there is supposed to be a vaccuum pulled so that the fiberglass will hold tightly to the mandrel during the initial winding. the consistency of the fiberglass at this point in the process is slightly more rigid than "cotton candy". i do not believe it would be possible to control tension. in fact, the fiberglass is cut prior to winding with just a pinch roller.