Hi All, I've been asked to design a CHEAP and “accurate” cut off system for a tube mill. Thought I’d put this out there for some feedback – perhaps save reinventing the wheel so to speak.

Basic principle is the length is predefined by down stream detector once activated a cut off saw accelerates alongside on a parallel track aiming to match the tube mill production speed and then cuts the tube. Then the cut off saw returns home for next cut. Mill production rate is slow at approx 6m per min.

Based on the cheep nature of the job I’m looking at the AB Micrologix range. Using an encoder or tacho to measure the production speed of the tube mill and get analog or Modbus feedback from a VSD to confirm speed match before cutting. It has been suggested that the cut is accompanied by a prior clamp to tube and electric / pneumatic drive disengage of the cut off saw drive mech. to avoid any issue with precise synchronisation.

· Has anyone achieved this sort of thing before?

· How do I accuracy and continuously calc line speed using an encoder?

· Any other points of potential failure of accurate measurement / speed matching?

Look for the key word "flying shear". This is essentially 99% of what you are proposing to build except that your cut length is fairly short. These are notoriously difficult to get right. I wouldn't even consider a Micrologix for this, or at the very least, I wouldn't even start with worrying about the PLC. I'd do the mechanical/motion control design first and then back into whatever PLC falls out.

The key here is that you have to match both speed and position simultaneously during the clamping process (if you insist on clamping). This isn't a great solution because then you have to clutch the drive motor for th linear motion...this alone adds cost and lots of mechanical reliability issues. This is not an ordinary PID loop since PID loops normally only have one variable to contend with and here you have at least 2, maybe more (acceleration/inertia, position/speed of the cutter). It might be possible to do a cascaded loop but then you've got to avoid loop tuning interaction problems. And since you want this to happen fairly quickly, you'll need feed forward/backward loop control...again, not an ordinary PID loop.

This is a classic problem in the motion control regime. And since you are pushing accuracy a bit, you can't just use any VSD. You're going to need one with full flux vector control. Your mechanical mechanism is going to be a major problem too because you will need to keep your system bandwidth up to be able to settle down to the right spot reasonably quickly while that spot is moving. If you're not running calculations for system bandwidth and treating this as a mechatronics problem, you are probably doomed from the start.

As to the encoder, that's simple and the least of your trouble. Simply mounting a spring loaded wheel contacting the tube with a decent high resolution encoder and feeding a high speed counter card does all the math for you. I wouldn't do it any other way. Usually tube mills don't change speeds all that quickly so resolution/accuracy shouldn't be all that hard to do. Use pulse counts for position information. Use pulse-widths for velocity.

You will still need linear position measurement of the cutter, and that's a very sticky issue. Measuring absolute position of the cutter shuttle car with any degree of accuracy is often a very tricky thing. Quite often I've seen designs which use both an encoder (for speed) and a separate position sensor. If you try to differentiate the position data for velocity, frequently the resolution is so coarse that you can't achieve smooth motion control. It might be possible to make something usable with an observer to simulate the velocity sensor but I've never actually tried to write one. Again...mechatronics is a very tricky field with a mix of mechanical, electrical, and controls systems.

It is POSSIBLE to do the calculations using pretty much any PLC. But you will have to be intimately familiar with motion control algorithms because that's exactly what you are going to be writing. It is POSSIBLE to use the on board PID supplementing it with your own trajectory calculator and external feed forward loops. I have personally done it even on a PLC 5 using non-servo hydraulics, although I just had to hit a fixed position/trajectory, not a moving object. I'm truly reaching the limits on the PLC-5 system and just itching to upgrade it soon. However if you haven't done this before, you are in for a rough time and the customer is going to be PO'd long before you get it right.


I suggest you take one step back and consider one of two routes. First, you can still use the Micrologix, but you will be way ahead if you inject a real motion controller into the mix. This would mean for instance an AB Kinetix or some other equivalent device. The PLC is going to be basically just sending commands (stop, run, match this speed and position) and handling the interfacing. It won't be receiving encoder inputs except possibly indirectly from the motion controller. The motion controller will be reading encoders, running drives, etc. This is the traditional route. Doesn't matter whether it's electric (rotary or linear motors), pneumatic, or hydraulic. Same design does it all. As soon as you talk to a motion controller company, they will be happy to give you all the information you need. You might not even need a PLC if you go this route. Be forewarned though that motion controller programming is a whole other world. Your ladder logic knowledge won't help a whole lot. Better if you are familiar with traditional PC programming languages for the most part, or signal processing systems.

Since this may be an ideal design for a linear motor, you may want to involve some of those people early on. Their drives often include motion controllers and this is a classic application for a linear motor. Try to look carefully though at whether or not magnetic particles are going to be a major issue especially since you're cutting (open tracks with permanent magnets and shavings == BAD RESULT). Just be aware of this problem and design it out early on (or reject particular linear motor designs because of it).

The alternative is an integrated design. Use a PLC with motion control built in. Everything is in one controller, potentially saving some money. In this case you'd use a CompactLogix or ControlLogix. You can use almost any drive that does vector control, although I'd steer you again towards either a linear motor (very high bandwidth) depending on mass limits or a Powerflex 40 or 40S series (full vector control or possibly servo grade). In the end, this will be the most flexible and easiest design to maintain.

Thanks - have site meeting in coming days so will have more info - I am confident I can engineer a solution using a PLC and VSD but am concerned aout accuracy and this could lead to other options.

I have a Hill Engineering tube cutoff system on 2 of my tube mills.

Paulengr gave you a very good basic overview of a flying cutoff system. The Hill control system is a combo of a SLC 5/03, a servo drive & an AMS controller with encoder. The AMS controller watches the line speed & cutting position, starts the servo and then initiates the cut cycle in the PLC. The max tube speed for this controller is 250 fpm. The cutoff works fairly well, but it has a bunch of mechanical/controls idiosyncrasies - like losing the base setup in the AMS controller during brown-outs & slugs occasionally getting stuck inside the shear.

A couple of questions...
What's the tube OD & wall?
What's the cut length of your part?
Do you need a dimpleless cut?

A PLC will never be able to do this
ftp://ftp.deltacompsys.com/public/Picture...20shear%201.png
It takes just one command to go forward and one to go back. The cycles has only about 5 steps. Two of which are tell the shear to go down, waiting for indication it is down, tell the shear to go up and waiting for the shear to be up.

The black line is the line speed. It is constant in this example but on the real machine there is a little jitter. A little jitter is OK but the main headache when doing gearing systems is the master or line encoder.
I also calculate the line acceleration but I didn't show that in this picture. I think the line speed was 20 inches per second or 100 fpm.

The yellow line is the line position. It increments to the cut length and then is reset after the cut.
The scale on the left is in inches.

The red line is the shear traverse position.

The blue line is the shear traverse speed in inches per second. You can see it matches the line speed at the cut.

The green line is the control output. Notice that it leads the shear velocity. That is because feed forwards are used. Without feed forwards the PID would always lag in such a dynamic motion profile.
This is what you are trying to avoid.

The controller is limited by the mechanical design and available power. If the mechanical parts are designed right there should be no need for grabbing the pipe.

No PLC is required unless you have a lot of other I/O. A HMI such as a PV, Proface, Red Lion etc can communicate with the controller using Ethernet. If a PLC is required the controller will appear in RSLinx as a SLC500 and is addressable as a SLC500 or you can use Ethernet/IP.

Rolling your own flying shear software is difficult in a PLC because PLCs don't lend themselves to performaing complicated math like the nice s curves shown in the png file.

Hi All, After a site meeting I can confirm the line speed is going to range between 7 and 16 feet per minute (quite slow by some of the numbers I seen discussed) perhaps now the line speed is known some of you may have a different opinion on it needing to be a servo drive?



Other initial specs (need refinement) are -

• Estimated that a 0.55kw motor will drive the carriage (flying shear)
• Estimated gearbox / gear ratio is 100:1
• Rack and pinion system for driving / positioning the carriage (flying shear)
• Existing clamp arrangement included at this stage with option to include clutch to avoid over/under drive of VSD if speed matching an issue.
• AB PLC with encoder input for line speed / length determination and either analogue or comms (DeviceNet to enable fast access to drive parameters - speed ref, accel, decel, etc) to control VSD (Telemecanique Altivar 71)

Thanks again for your input.