Flying Shear Accuracy Issue

[MichaelG]

Peter

Using s-curves is much better but there is a cost.

Definitely - However on most systems that I have commissioned, by using Jerk I have been able to reach higher Accel's without the mechanical stress - I would not presume that curve to be for 69firebird until we know more plus I would change it for different lengths.

1. Calculating accurate speeds

Agreed - that is his problem which he will be able to get around if he can get the system to be repeatable

acceleration feed forward

I do not know about your system - In the rockwell look at the loop diagrams in http://literature.rockwellautomation.com/idc/groups/literature/documents/um/motion-um001_-en-p.pdf he is using the "Motor Position Servo" type

There is a time delay between the line speed encoder reading and the coarse update

Yes there is - Rockwell try to get rid of it by using Master Delay Compensation and I think that he has made it worse by using the master position filter

I wish that I could use splines in the rockwell but all I have are CAM's

kamenges
You are correct, in the code there is a Motion Axis Move (MAM) that overrides the cam profile to return to position - I would not use it I'd just set the CAM up correctly - The shake that you are seeing in velocity during the MAPC is caused by the master reference being so coarse

 

[Peter Nachtwey]

Good Questions, I have wondered about that too.

Just asking a silly question but why doesn't the actual velocity profile on the return move look anything like the expected velocity profile from the CamBuilder?

Yes, the motion profile in the trend does look a lot cruder than the cam editor motion profile.

Also, since this is a cammed move all the way, why is the forward steady state velocity during the cut so variable but the return velocity is so smooth?
Keith

This could be due to a problem I often see. If the shear speed doesn't exactly match the line speed it pulls or stalls the line which pulls or stalls the line encoder which effects the shear because the shear it geared to it. It is kind of a feed back problem. Reality draws a vacuum.

My motion profile is below. I shortened the cut length to 800 mm to get more resolution in the picture and get the profile to fit in the forum's 800 pixel width limitation. I plotted the acceleration which is the light purple line. The lower left has the color codes. This is simulating a line speed of 833 mm/s which is 50 mpm. I can move the hair line cursor to the acceleration peaks and with the s-curves the acceleration will be about 10.6 m/s. The max retract speed is about 1.44 ms. I used a cut time of 0.3 seconds and centered this part of the travel in the middle of the 450 mm of available stroke.
If I make the cut length over 2.2 x 450mm the max speed drops to about 1.23 m/s and acceleration to 7.6 m/s^2. When the cut length is greater than 2.2 times the stroke ( 450mm ) the shear must kill time by going back to the start position and waiting otherwise the shear will exceed the travel limits.

My technique has the same acceleration and decelerations when the cut length is short ( cut length < 2.2 x 450mm ). This is worst case and it is good to keep the acceleration and decelerations the same. Notice that there is just one motion back to the next cut. Cam tables are not used. There are simply two steps which you can see in yellow. One step gets to the synchronization position and the other steps waits for the shear to make the cut while geared 1 to 1. When the cut length is less than 2.2 times the shear's maximum stroke distance I don't even bother to go to a start position.

I think my peak accels and speeds may be a little lower than what 69Firebirds has and I am sure my accelerations are smoother. This will result in less overshoot, wear and tear on the system and increase accuracy.

 

[69FIREBIRD]

Hi Everyone - firstly thanks for your invaluable feedback to date. I am working through it as we speak.

As just mentioned their is a MAM that overrides/merges into the return to home / move to 0. This was implemented recently to get the die set back ASAP for when it was cutting short lengths (300mm). I'll be back with an update as soon as I've worked through your feedback.

A quick but of history this machine is a duplicate of an upgrade done on a sister machine some years ago. The only difference is that this mill has a requirement to run a configurable batch system for different lengths / quantities. Hence the “quick fix” to get it back to home / 0 with a MAM (the early stage of my motion control experience)

Again thanks to all for the support.

 

[Peter Nachtwey]

Good questions, I have wondered about that too.

Just asking a silly question but why doesn't the actual velocity profile on the return move look anything like the expected velocity profile from the CamBuilder?

Yes, the motion profile in the trend does look a lot cruder than the cam editor motion profile.

Also, since this is a cammed move all the way, why is the forward steady state velocity during the cut so variable but the return velocity is so smooth?
Keith

This could be due to a problem I often see. If the shear speed doesn't exactly match the line speed it pulls or stalls the line which pulls or stalls the line encoder which effects the shear because the shear it geared to it. It is kind of a feed back problem. Reality draws a vacuum.

My motion profile is below. I shortened the cut length to 800 mm to get more resolution in the picture and get the profile to fit in the forum's 800 pixel width limitation. I plotted the acceleration which is the light purple line. The lower left has the color codes. This is simulating a line speed of 833 mm/s which is 50 mpm. I can move the hair line cursor to the acceleration peaks and with the s-curves the acceleration will be about 10.6 m/s. The max retract speed is about 1.44 ms. I used a cut time of 0.3 seconds and centered this part of the travel in the middle of the 450 mm of available stroke.
If I make the cut length over 2.2 x 450mm the max speed drops to about 1.23 m/s and acceleration to 7.6 m/s^2. When the cut length is greater than 2.2 times the stroke ( 450mm ) the shear must kill time by going back to the start position and waiting otherwise the shear will exceed the travel limits.

My technique has the same acceleration and decelerations when the cut length is short ( cut length < 2.2 x 450mm ). This is worst case and it is good to keep the acceleration and decelerations the same. Notice that there is just one motion back to the next cut. Cam tables are not used. There are simply two steps which you can see in yellow. One step gets to the synchronization position and the other steps waits for the shear to make the cut while geared 1 to 1. When the cut length is less than 2.2 times the shear's maximum stroke distance I don't even bother to go to a start position.

I think my peak accels and speeds may be a little lower than what 69Firebirds has and I am sure my accelerations are smoother. This will result in less overshoot, wear and tear on the system and increase accuracy.

 

[MichaelG]

oooh wish I could do those curves

The only problem that I see is that in this case the slave has a maximum velocity of 1.04 m/s - it is the limit of the motor rpm, gearbox and servo controller fixed headroom.

 

[Peter Nachtwey]

Are you working on the same project as 69Firebird?

The only problem that I see is that in this case the slave has a maximum velocity of 1.04 m/s - it is the limit of the motor rpm, gearbox and servo controller fixed headroom.

Ouch.

Usually it is the acceleration/deceleration that is the limiting factor because of a torque limit. You can increase the acceleration and deceleration and reduce the velocity but that usually beats up the machine a lot more. Smoother accelerations result in better accuracy. When the acceleration is smooth all the lower order terms ( velocity and position ) are smooth too. When I get asked about flying shear calculations I just put the numbers into my program and I can simulate the machine.

To get the my maximum speeds down I would need to apply more traditional methods where. We have the IEC Clutch-By-Distance command that allows for specifying the ramp up distance and ramp down distance but it requires more parameters.

oooh wish I could do those curves

This is done with one command that generates one 5th order polynomial from where ever the actuator is to the desired sync position, gear ratio and gear ratio rate as the line position reaches a desired sync position. The idea is that you specify the end result and let the controller work out finding the best path.

 

[69FIREBIRD]

Page 1...

Hi Guys - I'm back! Spent the better part of the day reading through your posts and research. I'll try and comment on feedback and supply answers to questions posted since my last post (Sorry it goes on ….and ….on).

widelto:-

My guess is that your retrofit is an Alpha cutoff from Thermatool

The "Alpha" is an Alpha ASR-2500-53 by Alpha Industries Inc. Novi, Mich, USA. Can I ask what Event "Trigger" & "Tag" you used to trigger your motion event tasks?
I've had a look at the sample code on the Rockwell site it has a rating of 1.5 stars but looks solid - I'd be interested in what the others think.

MichaelG:-

"I see leftover code from using MAG in the program

Yes, I understand that gearing was the electrician’s first attempt and this was superseded by a CAM's. As I work through sorting this out I plan to lay the program out better and clean up void code.

The CAM in use has speed turning points causing the overshoots

How have you determined that it has "overshoots" - looking at the cam editor things look ok to the untrained eye.

The Auto Tune of the Axis was done at 25% of max speed - I usually use a minimum of 60% and sometimes reduce the Torque to 80%

Where did you find this info? So I need to retune the drive from the options on the Axis Properties GUI "Hook Up" and "Tune" tabs?

The soft ware limits imply that you have up to 960mm of slave travel ? please check

From the Axis Properties "Limits" tab I see Max. Pos. 800mm & Max Neg. -130mm = 930mm (I assume typo). Yes their is a reasonable physical distance that can be travelled this might be OK for 5.5m @ 70m/min but on a 300mm @ 20m/min the response needs to quick.(I had it confirmed today that this is the expected operational speed and range)

You have a Hydraulic Solenoid connecting to a Flywheel - speed Timing issue here

Yes we believe this could be part of the problem it's an all air actuated clutch system electric to shuttle air switching reservoir air to move the clutch. I added the FIFO to capture the time delay between activating the solenoid and the clutch staring to move. I see in the code I have posted that it ranges from 66mS to 87mS but I would assume that if the motion was synchronised that the delay / variation might not be a factor.

look at the help for MSGP (Motion Group Strobe Position) instruction

Have done - so you with each scan the strobe data is all relative - will consider adding this in.

on the Slave Axis the Master Position Filter is 4 Hz - lookup what it does to MAPC and MAG.

Still working on how it affects MAPC.

The CAM is recalculated every cycle based on the current speed - This makes commissioning the MAPC harder

I think I was seeing the cam profile moving around slightly the other day while online and in production - I assume this covers the line getting up to speed and down to zero - I will be looking at requirement /effect of this when next on site.

Master reference - get it smoother in speed do the maths to get the maximum possible counts per mm

The master line encoder used here is a SICK programmable unit. currently with a PPR of 2048, I have read the manual on it today and note that the physical disc is 8192 ppr and will program output to be that. As I see it that means (8192(ppr) x 4(lead&trail of A&B) / 480mm(measuring wheel circumference) = 68.26667 as opposed to original Master reference - 17.066666.

Get the Shear to stop at the same physical position Every Time

I have captured this also with a FIFO and note that the stop position does vary 4-5 degrees. but again I would assume that if the motion was synchronised that the delay / variation might not be a factor.

Rethink the CAM

Yes - After adding the our "quick fix" for a return to home with a merged MAM and reviewing the sample code cam profiles I am considering a cam that moves through to a linear line and once I have conformation that a cut is complete merge in a MAM to zero. - Probably sac-religious to the motion purists

Retuning the Ultra 3000 may also assist

Agree - haven't done this before assume you are talking about retuning the drive from the options on the Axis Properties GUI "Hook Up" and "Tune" tabs? or via the Ultraware interface to the drive - I note this has tuning options on it.

Create some logic (so that you can trend) that captures the Master and slave position's (and the difference) when the physical cut occurs e.g. flywheel position

Good idea will do.

Please verify that the flying shear diagram is correct

Not 100% sure of the mechanics of the shear but it looks to crank a solid guide rail around and the die set travels along that and the bed rail and somehow the knife is mechanically linked/cammed and performs a "peak" that clears material from the top of the tube and then a "cut" to "fully shear" the tube. This operation highlights any mis-synchronisation of speed as a "peak" score on the tube before or after the cut can be seen.
As mentioned above I had it clarified that for 5.5m @ 70m/min but on a 300mm @ 20m/min. the maximum travel can be Max. Pos. 800mm & Max Neg. -130mm = 930mm but with the shorter lengths you need to be getting up and back in a short distance and at reasonable speed.
Total time for the shear to operate - the delay between firing it and getting some movement is between 66mS and 87mS so I would estimate (can confirm with some test code tomorrow) approx 0.2 - 0.3 seconds.
Time until the shear engages the product will vary as the knife does not stop in the same position every time seems to vary 4-5 degrees - not sure of the impact on time (again can confirm with some test code tomorrow)

Is this the link to your thread http://www.plctalk.net/qanda/showthread.php?t=24393

Thanks have read this as well.

OMG J “The text that you have entered is too long (13794 characters). Please shorten it to 10000 characters long.”

 

[69FIREBIRD]

Page 2

The SERCOS is the only one that needs the coarse update (I just looked, the Sercos link rate is 2 ms - I would have used 0.5 ms)

OK will do.

The PLC Code has holes in it that are not helping either

Yup. I can see a few - I'd be interested in what people think is the best way to lay this out starting again - continuous task/periodic tasks/event tasks. so that I get started on the right foot.

Peter: There is a time delay between the line speed encoder reading and the coarse update. Yes there is. Rockwell try to get rid of it by using Master Delay Compensation and I think that he has made it worse by using the master position filter

OK will trail without and with & different bandwidths

Peter Nachtwey:-

I would get much higher count encoders

See comment to MichaelG. I believe I can get 68.26667 counts/mm as opposed to original 17.066666/mm by working with the hardware I have at present.

I have doubts about the acceleration feed forward value at 100%

The help on this states "This value is also not applicable for Ultra3000 drives" so I don’t think it does anything anyway.

Thanks for the valuable feedback Peter. sorry my response is shorter than that to MichaelG It’s getting late and so maybe I’ve missed something. I do rate your input highly and please don’t take offence.

kamenges:-

As mentioned by me earlier in the day and as Peter states "in the code there is a Motion Axis Move (MAM) that overrides the cam profile to return to position"

PS I think something ugly is happening with the accuracy of the encoder count. Note the compute instruction for the cut length "(Sample_Scaled_lenght+Blade_setting+Machine_Offset)*Line_Converstion" - The HMI input "Tube lenght" is scaled in a function block (??? errors / quick fix ???)and then a "blade setting" is added (can understand this as material is lost in the cut) then a "machine offset" is added (don’t understand what that could be) then multiply by "Line_Converstion" (this makes sense) this is sent to the "PositionUnwind" via SSV

I also note that the equipment making the tube consists of 2 DC drives one feeding the raw flat coil through rollers to from the tube before it is welded and a second set of rollers after the welder to "size" the tube. The operator has two control dials the first to set the line or feed/follow speed and the second to "balance" the two drives so they are running at the same rate. I note that their is room for improvement in operator acceptable tolerance as I can see the line speed hunting by around 0.5m/min. This is based on the "Axis_Master_Line_Product.ActualVelocity" which from the attached and highlighted "trend3" shows it moving up and down. Still don’t understand why it is "capped" top and bottom" thought it might be maths related. I'll be looking closer at this.

Again thanks for putting up with me.

 

[widelto]

widelto:-
The "Alpha" is an Alpha ASR-2500-53 by Alpha Industries Inc. Novi, Mich, USA. Can I ask what Event "Trigger" & "Tag" you used to trigger your motion event tasks?

As I told you, our system doen´t have an encoder on the shear, but it has two limit switches, new systems that i´will have to retrofit they do have an encoder.
On Fig. Corte, you can see that as soon as TKW_MAW_CORTE.PC is set i trigger my event task, that means that i´m watching my encoder on the line ( waiting for my pipe length plus my knife thickness), at the same time my die set is synced with my mill speed. In My corte task I energize pneumatic solenoid to make the cut, and go back .
On Figure fin_corte, I observe that my pneumatic solenoid is energized (shear) and that my limit switch that energizes the brake (shear) is set, then I trigger my fin_corte event in order to move back ( die set) as fast as possible
Sorry that everything is in spanish, but you can understand the program.

 

[kamenges]

Originally posted by 69FIREBIRD[/b]:

Still don’t understand why it is "capped" top and bottom" thought it might be maths related. I'll be looking closer at this.

Resolution. The way the controller determines velocity is by dividing the number of counts received in a given time period by the time period. You can't have a partial count, even though a partial count is what is technically required.

For example, assume I get 20 counts in a 2 msec span, which works out to 10,000 counts per second. The next scan I get 21 counts, which is 10,500 counts per second. My effective resolution is 500 counts per second and I will never get a value that is not a multiple of 500 counts per second. You will notice that the occasional spike is also the same height as the "block" height.

This is where encoder resolution helps so much. If you had an encoder resolution 4 times better than you have you will get a "block" and spikes 1/4 the height.

I know Peter and his company have done alot of work on calculating master velocities. But there is only so much you can do without sufficient resolution.

So, it looks like instead of just basiung everything off the cam you are making discrete actions based on machine condition. What do you do if the shear says it hasn't finished the cut before you need to begin slowing down?

Keith

 

[Peter Nachtwey]

Resolution is key to computing acceleration feed forwards

There are some filter tricks we can use but it is much easier to calculate accelerations when the resolution is very fine and not noisy. Acceleration feed forward may make all the difference in a shear application. I have included two pictures. One using acceleration feed forward and the other without acceleration feed forward. It is easy to see the difference. If you look at the mean squared error value you can see the error for the picture without the acceleration feed forward is many times higher. In the picture I am using the same parameters as yesterday. I shortened the cut length to 800mm to get the motion to fit in the 800 pixels.

One of my customers has a 5 in dia roll with a 2^18 count encoder for the line reference. This provides plenty of resolution. The derived velocity looks smooth compared to 69Firebird's.

 

[69FIREBIRD]

Thanks Bill (widelto). I can see what you’re doing.
I'd question the way the event task is instigated though, as the tasks are called from somewhere in continuous task so are influenced by scan time maybe up to 2-3mS? Obviously not an issue for you as you are at 90m/min with +/- 1mm.

I wondering if there is a better / continuously monitored way to initiate motion tasks. There are lots of options predominantly associated with motion control features (see attached screen dump)

Basic help states: For more detailed information on planning specific types of event tasks, see Identifying and Managing Tasks, or refer to Chapter 2 in your Logix Controllers Common Procedures Manual (publication 1756-PM001).

So more reading.

Thanks again Bill.

 

[69FIREBIRD]

For example, assume I get 20 counts in a 2 msec span, which works out to 10,000 counts per second. The next scan I get 21 counts, which is 10,500 counts per second. My effective resolution is 500 counts per second and I will never get a value that is not a multiple of 500 counts per second. You will notice that the occasional spike is also the same height as the "block" height.

Did you hear that? the penny just dropped.

This is where encoder resolution helps so much. If you had an encoder resolution 4 times better than you have you will get a "block" and spikes 1/4 the height.

OK so as mentioned we are going to look at maxing out the capable resolution of what we have currently available this should help although not to the degree of 2,000,000 PPR it's a step in the right direction.

So, it looks like instead of just basiung everything off the cam you are making discrete actions based on machine condition. What do you do if the shear says it hasn't finished the cut before you need to begin slowing down?

Yes, I see what you are saying. - Will have to follow up on this to make sure this is considered. The Shear (solenoid) is fired via a MAOC at 41mm (currently set by us to 61mm to insure we are in a stable synced motion - perhaps this was originally set at 41 to take into account the lag between clutch firing and actual movement - approx 60-70mS). This has no other sync. feedback qualifier on it - regardless of if the master/slave are accurately synced the MCCP has them synced by 60mm and the cut is started at 61mm (previously 41) ???

Thanks Keith.

 

[69FIREBIRD]

One using acceleration feed forward and the other without acceleration feed forward. It is easy to see the difference.

That one without the acceleration feed forward does have a striking resemblance to my current profile. Perhaps it shows a limitation of the Ultra 3000 not having acceleration feed forward according to the help file. “The help on this states "This value is also not applicable for Ultra3000 drives" so I don’t think it does anything anyway.”

One of my customers has a 5 in dia roll with a 2^18 count encoder for the line reference. This provides plenty of resolution. The derived velocity looks smooth compared to 69Firebird's.

Wow! I'm hoping to see an improvement by reprogramming the encoder to max at 8192 PPR so that’s a start.

Thanks Peter.

 

[MichaelG]

CAM Profile

Overshoots

• If you look at Peters CAM and My CAM charts you will see that the acceleration is a continuous line which causes the Speed to be continuous smooth line
• The minimum Aim is for no sudden changes in speed - ie NO step changes in Acceleration.
• The Motor cannot follow sudden changes in acceleration - it takes a finite time to get the current into the motor and control the inertia
• If you look at Peters CAM you will see that the Acceleration is also smooth (also the Jerk {rate of change of accel}) - a motor can follow this profile easily and it causes the least amount of stress on the mechanics.

Rethink the CAM

This depends on how you set up the Code
possible Methods

1. One MAPC to do everything including distance
   • The Last entry in the MAPC is the Cut length
   • Here you assume a time for the shear to occur and program accordingly
   • You can use as much of the travel as needed
   • Easy to change length while running using a pending MAPC
2. MAPC to velocity MAM home
   • As Kamenges said - What do you do if the shear does not cut? or run out of room to stop?
   • MAM in Version 15 does not have Jerk control so harder on mechanics
3. MAPC to speed with a different MAPC to reset
   • Bonus here - get variable cut time with the benefits of CAM forward and return
   • If you wait to long you may not get back in time for the next cut at top speed
   • In the L55 processor I needed 60 to 70 ms to enable a MAPC that started on master distance ("forward")

I am a control freak

• The Travel would be set up with a fixed time to shear
• I would monitor the shear time and stop if it got to big
• I would know from the travel CAM what the maximum speed of the product is
• If during a cut the blade got caught I would know during the cut time when to panic stop. (using the shear encoder)

Here is what Peters profile looks like in Rockwell cubic interpolation - Thanks Peter