Hypothetical machine control sensor

Lately been thinking about how to implement feedback to a controller for a machine that is either feeding wire/rope or a flexible flat,
wide material like plastic wrap or foam (even sheet metal) to a take up reel. Enough material would be visible on its way to the take up reel for an inspector to see any defects.
The material will break or stretch if a disturbance to the plant causes too much tension on the mat'l and the takeup reel drive would need to be slowed down until the plant is back up to speed, so consider a optimum amount of sag (maybe not perceptible in the case of wire/rope ) as the material is on its way to the take up reel. Naturally, as the amount of material on the takeup reel increases, the sag/tension will decrease/increase unless the take up reel is slowed down.
In either case, I'm thinking the machine output could be represented as a supply reel feeding material at a constant linear rate. Just for starters.
Case 1, wire.rope:
I was thinking that the displacement of a tension idler (placed near the material output would indicate the tension of the material. Either a straight line from the idler to the take up could approximate that component of the idler force vector, or the wire tension/sag (caternary) equation could be used in the analysis/derivation of the transfer function. The rate of change of force on the idler would indicate the speed difference between supply and take up.
Case 2, flat material:
In this case I thought that a few opto detectors above and below the "optimum" sag point could detect the increase or decrease in sag and the rate of change of sag would indicate the speed difference between the supply and takeup reels,
i.e., in either case, the linear velocity coming off the machine minus the linear rate that the take up reel is *trying* to take it up.
Typical disturbances would be, say, the machine encountering resistance in trying to get the material out, or the take up reel being out of round causing a cumulative decrease in sag.
Are these sensor arrangements prctical? I've never seen this done before so I have no clue how it might really be done in industry.
Any suggestions as to why this isn't practical or what would work better would be appreciated.
TIA
--
Best Regards,
Mike

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Activ8 wrote:

Why not a tension idler for both? For that matter, if you have a tension idler that can take up a material amount of slack you could make that your first line of defense against breakage, then control your take-up reel by the position of the idler.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

This is certainly the traditional way to solve this problem - and the most commonly seen in general industry.
The "modern" way is to use a vector-control variable speed drive (like the ABB ACS600 series) and use motor current and a rotary encoder for the tension measurement. This way all control is performed in the drive itself. Of course, you still need overtravel detection...
Cameron:-)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Cameron Dorrough wrote:

That would let you control the torque on the shaft, certainly. How do you correct for the diameter of the take-up reel? Or are we even talking of the drive on the take-up reel?
You may have problems if anything unexpected happens of a suddenness and magnitude that you can't control it with your take-up reel alone -- but I suppose you could just design your machine to not let that happen in the first place.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

most
the
itself.
That's where the rotary encoder comes in. You install it on the take-up reel. As the diameter changes, the speed of rotation changes. Using a combination of encoder feedback (precision speed) and the instantaneous motor torque (tension), the drive can do the rest..

True on both counts. You would usually install a couple of "overtravel" limit switches to detect (1) too much sag (speed up/increase tension) and (2) too little sag (slow down/reduce tension)
Cameron:-)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Tue, 20 Jul 2004 10:09:46 +1000, Cameron Dorrough wrote:

That's the idea, and good point, Tim. The spring tension on the idler [hopefully] damps the increased tension for an instant before the sensors tells the controller to kick back on the take up. But I really wasn't counting on that, considering that the inertia of the takeup reel ... look at the geometry ... maybe 10 feet from plant to reel or more. Intuition ... the longer the run, the less force against the idler spring by rate of change in tension, especially when you consider stretching.

Ok, with the right spring and geometry.

So I'm not too far off? Sounds ok.

On the take up? I hope that's what your talking. I couldn't figure what the ACS600 is really doing from what I glimpsed.

Yeah. That's what needs controlling, and yes, I did mention the changing dia of the reel, but that's not a fast disturbance.

Exactly. If the plant slows down, the take up reel needs to slow down or tension increases.

As i said.

We're on the same wavlength.

Good point, Tim. Take up reel inertia would limit response to major disturbances, but we'll take a break in that case as it's unlikely in this hypothetical case in my hypothetical noodle.

Yup. And that's really a MechE prob, but those things happen and if some shwag crap hits tha machine and chokes things, the take up reel needs to slow down, or we take an occasional break.

That's scary, Cam. Consider the inertia of 1000 lb reel of material on the take up reel. I think a simple limit switch set up might be too slow to ... react, ... but you might be right. It would work in some cases.
I'm still looking at a sag detector or tension sensor but take up reel motor current might work.
I figure that rate of change of sag is easier to translate into input/output speed diff and that's independant of the dia of the take up reel at a given instant. IOW. sag is proportional to tension and rate od change of sag is proprtional to dF/d = dV/dt. OTOH, increased current is dependant on take up reel dia.
Tim, I figured you'd jump in on this and thanks.
Cameron, likewise, thanks for getting in on this.
--
Best Regards,
Mike

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Tue, 20 Jul 2004 03:57:13 -0400, Activ8 wrote:

<snip>
^^ proportional

After sleeping on it, I suppose current sensing isn't that big a deal but other things could cause the current to rise, like gunk in the gearbox, so we'd still need to zero the setup.
That dancer arm jeff mentioned sounds about right and the encoder eliminates optos that will get covered with dust.
--
Best Regards,
Mike

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

If you use a vector-control drive this isn't a problem - gunk in the gearbox shows up as increased web tension, so when the line is started for the day, the operator simply adjusts the tension setpoint to get the feed tracking nicely between the two "overtravel" limit switches.

The biggest trouble with dancer arms is that they get fouled on things - cotton waste, binding straps, the operator's lunch wrap, maintenance guys clothing - and/or get snapped off if you get a really *big* feed jam.
In the past you just put up with it, but with rotary encoders you don't need them so why bother? Although if you're talking about a tiny one-off hardly-ever-used machine, the $$$ for a drive might not be worth it.
Cameron:-)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Cameron Dorrough wrote:

That seems pretty indirect, but I suppose if your machine is in good enough shape to do quality work it's in good enough shape for this type of control to work.
Speaking of indirect, if you're assuming that the reel torque is proportional to motor current (i.e. a fairly low-loss system), why not just use a constant-power drive to the motor? Assuming a fairly high motor efficiency a constant linear speed and a constant applied power should give you constant tension.
Of course if your line stops it'll try to drive things to infinite torque, but I believe this would happen with your encoder scheme as well, without appropriate limits on the control.
--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

That's exactly what the limit switches are for - to detect the feed as being either too slack or too tight for accurate control and to take appropriate action.
For example: On a sheet metal feed for a Can End manufacturing line, the limit switches we used were ordinary Square-D 900-series rotary arm mechanical limits - the ones with the roller on the end - mounted on struts above and below the "sag loop" between the two rolls..
AIUI (not being an ABB drives expert - I have better things to do with my time ;-) the ACS600 can have several configuration "pages" loaded into it's memory, allowing a complete change in control mode and drive parameters once a limit is hit.
A "solution in a box" so to speak..
Cameron:-)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Typical web processes as you have mentioned often use dancer arm controls where the arm is used to regulate tension and adjust for disturbances in the web. The dancer arm is a roll on the end of a pivot that has an angular encoder for feedback and uses a torque motor to maintain winding tension. The main reels will also be controlled by VFDs, however they typically do not have a fast enough response. A variation on this is a vacuum column that a loop of material drops into with opto sensors to detect the amount of material in the column.
Jeff
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Tue, 20 Jul 2004 11:42:39 GMT, Jeff Lowe wrote:

<snip>
They call them web processes, eh?
I saw a take up reel close to 1000 lbs manually adjusted for speed once. There was enough response time there, but maybe it wasn't a VFD? The reel sat on a rubber covered roller that was driven by a motor and gearbox. AC? DC? Not sure.
--
Best Regards,
Mike

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Activ8 wrote:

Hello Activ8,
It looks to me as though you are going to end up with a custom motor control design. You may want to get a 'development system' that includes hardware, software, and an emulator to begin prototyping your solution on. Here's a quick 2 references: ST7MC-KIT/BLDS from STMicroelectronics, at $695, or the PICDEM MC development board from Microchip, if you want to spend less money. Both have lots of example applications and software that you can piece together to get a baseline design working. Then you refine the application, until your specific machine is purring, and you have 100% of the software.
It you decide to go down this path, let me know, I can help you, if you like. Often using semiconductors directly from semiconductor manufacutures, allows you to get your hands on exactly what you need. It will require a little programming in C or assembler, but those are not really difficult. Refining your specific control algorithm is much easier with an emulation tool such as the ones provided with these development system.
James
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

I know we've been down this road before, but here goes: If this is just a hobby project, then by all means, go with some variation of an embedded microprocessor. Check out the GNU tool sets available for these for free. Another possibility is to throw a PC at the task with DOS, QNX or RT-Linux. If this is a one-off manufacturing plant application, go with a standard industrial variable speed drive or a PLC with motion control. This will give you the minimum engineering effort and the best long term reliability and serviceability. If this has some odd high performance requirements then a motion controller card such as a Delta PMAC may be appropriate. This will give you simple platform upon which to build a motion system. Almost all the tedious programming such as trajectory generation is taken care of for you. If this is some really strange application or you have access to grad student labor, consider a D-Space system. With one of these you can spend untold enjoyable hours analyzing, modeling,simulating and testing with any control approach known to man. <G> Finally if this is a high volume cost sensitive application then again, consider an embedded micro, but only if you are fully committed to the long term engineering support such an approach entails. Jeff
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Tue, 27 Jul 2004 17:50:57 GMT, Jeff Lowe wrote:

Depends. That 1000 lb reel is just the *biggest* thing that came to mind.

Ok, I know of Scott Datallo's gpsim, for PIC. What else is available and really good in GNU. I didn't turn up anything better than gpsim.

It looks like Scilab is the ticket, but for D-space? That's a new one on me. Wassat? Not another name for state-space, is it?

It was a "hypothetical" question. The sag sensor was what I was pondering, i.e., what I measure should be easily worked into the loop equation without complicating the diff eq.
But thatnks for those responses, anyway. I did dig around a bit looking for differrent motor drives.
--
Best Regards,
Mike

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
We do a lot of web processing at my company and have approached the problem three ways.
1. We separated the take-up motor from the take-up shaft with a magnetic clutch. The take-up motor runs a constant speed. Voltage to the clutch controls web/roll tension. http://www.magpowr.com /
2. We put encoder feedback to the take-up motor controller on an idler roller to maintain constant web speed. The take-up motor slows down as roll dia. Increases.
3. We used a zero position dancer bar controller option on the take-up drive. This is the best solution for our needs. We use an air cylinder to put down pressure on the dancer bar. The take-up drive fights the air cylinder to try and maintain dancer bar position. This way we can control the tension of the web and how tightly the take-up rolls are wound by varing the air pressure. http://www.electrosales.com/warner/pdf/seco/Quadraline_Q7000.pdf
Bill Kneuper Miller Curtain Co.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On 27 Jul 2004 06:20:02 -0700, Bill Kneuper wrote:

Thanks. I didn't think about needing more tension than the weight of the web would cause on its own. I'll remember that. I *was* thinking of setting up a (very) small scale system for the hell of it, one day.
--
Best Regards,
Mike

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Mon, 19 Jul 2004 13:52:03 -0400, the renowned Activ8

I have done this when contact with the web could not be permitted (the material was very soft and optically transparent) by using sonar and vanilla PID control.
Best regards, Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
snipped-for-privacy@interlog.com Info for manufacturers: http://www.trexon.com
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Tue, 27 Jul 2004 15:06:21 GMT, Spehro Pefhany wrote:

Damn! Ultrasonic. Where's *my* head?
--
Best Regards,
Mike

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.