Application Ideas

[Evilbeard]

Ok, I'm in the planning phase of a project here in my facility. It's a V-fold machine. Basically, we take a "parent" roll of film and put it on the unwind of the machine. It's folded to specification, and then wound into the proper "fig" on the rewind. There is a nip roll between the unwind and the rewind that sets the speed of the machine. The unwind and rewind use dancers to set tension and speed to that set of nips. The parent roll is generally 4:1 or 5:1 of the end product.

The rewind has a turret with two winder shafts. Currently, it has obsolete DC drives and PLCs so old we don't even have a computer running old enough software to access them. My project is to rip the thing down to bare bones and create a control system from scratch. I'm going to go with 10HP GS3 drives for my system, because I know I can easily control them with Modbus RTU (and the secondary nip roll behind the machine has been replaced with a GS3). My question comes in the form of drive control. I was thinking of just using PID Loops to control the drives. I know these drives come with the capability, but I figured that the Do-More would be much better suited to control these loops, or am I wrong in this thinking?  The trickiest part of the project comes down to this for me:

1. The machine will auto-splice on the rewind. When the roll reaches the set footage, it will retract the layon roller, roll the turret over (enabling the second winder shaft and speed matching it, and then bringing the layon forward and cut the film with a flying knife.

2. While speed matching the shafts is fairly easy (simple ratio of diameters I will derive from laser measurement and multiplied by the speed of the current running motor), should the PID Loop be active during this time, or should I disable it while the splice cycle is active? Should each shaft have it's own PID Loop? For instance: PID Loop 1 for Shaft 1 is active, until the splice, and when the film is cut onto Shaft 2, PID Loop 2 goes active and vice versa?

I just want to make sure this will do what I want to do, and this is my first project with a Do-More. I thought I'd run the application and my ideas by the forum, because I know there are many people here with much more experience in automation than I have.

Thanks in advance!

[Mike Nash]

I can't recall ever doing a turret winder without tach or encoder feedback. Then again, diameter calculation methods tend to rely on accurate speed measurements. If you are full laser measurement, maybe.

I have never been confident that Modbus RTU would be fast enough to control coordinated drives that weren't running a pretty slow process, so I can't speak to that. The times I have used it or seen it done, involved calculating the required accel/decel rates for each drive, sending that out in advance, then sending the desired speed setpoint and let them handle it themselves. Used with forgiving processes and a lot of drives. I have run across a few ethernet capable (with option) drives that I didn't think could hack it either.

I would think the control mode during index would depend on how quickly it rotates. If slow enough, then PID should be OK. I typically see current/torque memory with boost/reduce trimmable if the index is quicker. There is typically a cut boost applied to tension the web between spindles for the knife fire. (But you know, with a Do-more you could maybe profile the spindle reference based on how much relative web speed would change as the turret rotates due to the web path geometry.    )

Don't leave the departing spindle trying to control dancer position after the incoming spindle has control of the web. That will get you a nice slack web to try to cut.

It's nice to ramp the PID (Dancer Position) setpoint from wherever the dancer currently is to the desired position when you enable the PID on the new spindle which should happen very shortly after the knife fires.

Lastly, at least it's not a turret unwind!

And I have done turret winders that ran in torque mode for all but the speed match and spindle jog. For whatever reason, these would just not tune out for me in speed with trim. But even those had encoders or tachs.

[Evilbeard]

The motors will have encoders on them (10HP Marathon Black Max with Dynapar 1054 PPR encoders), it's part of how I will calculate the speed match. If I know the current speed of shaft 1, shaft 2 is simply R1/R2 x speed of shaft 1. The process isn't particularly fast (they generally run production speeds of less than 500 FPM), and the turret index sequence (retracting the layon, jogging 180º, and the layon returning to the advance position) takes a little less than 20 seconds. I'm using laser measurement to give me the diameter of the running roll accurately without having to calculate it. So knowing I have a 16" diameter roll running as it indexes going to a 3.65" core on the other shaft means I'll get a much more accurate speed match, correct? Shaft 1 would be running on the PID, Shaft 2 would calculate it's speed based on shaft 1's current speed until the knife fires, at which point shaft 2 would take over PID control, if I'm thinking properly.

As far as the departing spindle controlling the dancer position, that's why I was wondering about two separate loops. They'd more than likely have identical settings, but when shaft 2 became "active" when the film is cut, turn on loop 2 (turning off loop 1), making it in control of the speed reference output (which would in turn control the dancer position by adjusting the line speed). Or is that just redundant? IF my PID loop is simply SETPOINT (middle of dancer travel's analog scale [5V]), PROCESS (actual position of the dancer in the analog scale [0-10V]), and Output (speed reference scaled 0-120HZ), would that loop work regardless of which drive was enabled? For instance, the setpoint would be sent to drive 1 when it was "active", and once drive 2 became active, the same setpoint would be sent to drive 2.

[Mike Nash]

If I am following you, you are going to speed match Spindle 2 to web speed based on ratio of diameters and Spindle 1 current speed. That's new to me though it sounds workable. It might give you a bit of trouble trying to do it during index since Spindle 1 speed will be compensating for turret motion and possibly layon-inflicted web path changes.

I normally see Spindle 2 speed matched to your master nip roll speed with some min core diameter used and adjust max speed to get it matched.

Are you describing a full PID control of the winder, not just a PID trim on Nip_Speed * Core_Diameter / Current_Diameter ? I could see that on torque control but not speed + trim.

I don't think one PID vs two is as much an issue, it just requires proper handoff and maybe resetting the bias/integral momentarily.

[Evilbeard]

If I am following you, you are going to speed match Spindle 2 to web speed based on ratio of diameters and Spindle 1 current speed. That's new to me though it sounds workable. It might give you a bit of trouble trying to do it during index since Spindle 1 speed will be compensating for turret motion and possibly layon-inflicted web path changes.

I normally see Spindle 2 speed matched to your master nip roll speed with some min core diameter used and adjust max speed to get it matched.

Are you describing a full PID control of the winder, not just a PID trim on Nip_Speed * Core_Diameter / Current_Diameter ? I could see that on torque control but not speed + trim.

I don't think one PID vs two is as much an issue, it just requires proper handoff and maybe resetting the bias/integral momentarily.

I was thinking of going with full PID control, but would you recommend going with just PID trim? I just thought it would be simplest to go with the loop being active when it was running, adjusting the speed of the winder to the nip at all times.

At the time the transfer/cut of the spindles happens, the turret will have stopped rotating for a few seconds, and I was thinking that the speed would have normalized for any deviation due to the rotation of the turret. The layon has to come all the way forward (the cut knife is located on it) and activate the advanced position prox before it will cut. This means the turret has about 1.5-2 seconds in its "in position" state where it has stopped rotating before it cuts/transfers.

If I wasn't going to speed match in this way, what would be the easiest way to do it? This is my first project with something like this. My only previous project with a PLC controlling a VFD was on this machine, and involved only the secondary nip which simply runs to the speed we set it to and I'll be integrating that control into this project.

[Mike Nash]

My concern with full PID is trying to make it stable. Torque winders can do this OK, but speed mode tends to be hard to stabilize and still maintain good control of dancer position. Using the actual diameter to ratio the ramped line speed reference or the speed feedback from the nip roll gets you into the ballpark and allows the PID trim to be maybe 10% trim authority so it can be responsive but not overwhelming.

If you were doing a diameter calculation rather than measuring it with the sensor, the trim from the PID is what forces the spindle to be at the right speed and that in turn gives you a new more accurate diameter which allows the PID trim to run closer to zero. The caveat is that any instability can be harder to track down because it could be from the diameter calculator. As the turret rotates, the spindle speed must change to compensate which causes a new but incorrect diameter calculation, so the "diameter hold" needs to be true before the index.

I don't see any reason off-hand that the speed match you are suggesting would not work as long as it is done after the turret is stopped. If the dancer is in motion I really don't know if it would be better or worse. If the outgoing spindle is still trying to control the dancer I can't see it being a good thing, but I've been wrong before.

BTW, I am not pushing towards calculating diameter from speeds. It works and is far easier with digital drives or PLCs than the old analog multipliers, but is still somewhat touchy since accurate calibration is required anytime something is changed.

[Evilbeard]

So if I follow, you're suggesting:

taking the speed I am sending to the secondary nips (line speed) and relate it to the speed reference sent to the rewind shaft. Then trim the speed reference (at like 10%) with the PID loop controlled by the dancer? For instance on the GS3 Drive, I could use Modbus communication to send the speed ref to the drive, and the trim (calculated by the Do-More as a PID loop) I could have as an analog output from the PLC of 0-10V to AI1 trimming drive. The Frequency Reference of the Drive would be FreqRef1+FreqRef2 (or FreqRef1-FreqRef2) which will be constantly updated by the PLC. FreqRef2 would be like 0-12Hz (10% of 120Hz max).

[Mike Nash]

That would work, but I would probably just control spindle speed with a single analog signal from the PLC to the drive. Do all the math in the PLC.

I really like communications, but the reality is they tend to be harder to troubleshoot and are the thing most likely to bite you if you have to replace a drive or PLC with one that is not identical. The "DUH? What were they thinking?" kind of things I run into have made me skittish that way.