Ultra 3000 following auxiliary encoder question

[loundeb2]

Need More Help..........

Hi,
I need some more help again. I installed a 5000ppr Automation Direct encoder and have a problem getting an output flag to set in the Ultra when the speed of the flying shear actuator is equal to the auxiliary encoder. I've read about using an STI to convert the HSC into RPM within the ML1500, but I don't see how to apply it to my application.
The problem I'm having is this, I setup a 36" part length at about 30FPM. When I increased the speed of the rollform to 40FPM, the parts were shearing too long, about 3". I reset to 30FPM and tried 48" part lengths, these were shearing too short, about 3" also.
Right now I have it set up so when the HSC reaches the HPR, it starts the Ultra following till the UpToSpeed flag is set which causes the shear to cycle. I know this is all wrong because it's a constant RPM and not a "speed matching" or "position matching" flag being set.
What's the trick/s here to getting this to be precise and reliable?

Thank You,
Lou

 

[MichaelG]

More Detail needed

Lou

Please Confirm
PLC ML1500
Utlra3000 - how are you communicating with it? Digital or Comms?
Connection for the Feed (master) encoder

If you can ZIP and Post the PLC Program - Especially the Control Part

A simple diagram of the layout would also help - Eg ML1500 HSC encoder Ultra3000 master encoder

Michael

 

[loundeb2]

Hi,
It is a ML1500-28BXB PLC using it's serial port to a Panelview 1000 Component HMI. I have the Ultra 2098-DSD-HV100X drive for the Reliance F-4075R-HOO-AA motor on the actuator.
The actuator has .500" screw lead per revolution. The motor encoder has 2000ppr. The rollform encoder is a Automation Direct 5000ppr with 3.78" diameter wheel which measures 12" per revolution. I've done the math and have put the correct follower gearing parameters through Ultraware and it's tuned tight and quiet. All Ultra interfacing is through I/O only because of time and cost restrictions of learning to address the Ultra.
I included a zip of the ladder program. It's alittle confusing because it includes a prenotch option throughout, but that isn't implemented yet until I can get the shearing lengths/speeds consistant and reliable.

Thank you for any advice.

 

[loundeb2]

Update

I added a 1769-HSC module to the ML1500 today to handle JUST the auxiliary 5000ppr encoder and tied it's output to the Ultra's "Start Following" input.
Lou

 

[MichaelG]

Lou
Please confirm that the block diagram is correct
The Carriage is to match speed with the product and then the Shear is to operate


Both Peter and I would not use a setup like this - we are usually after high accuracy (micro meter) and with the control equipment that you have that is not possible.
As a side note for others reading: I find in cases like this that spending more on the hardware makes the engineering easier, take less time, accuracy is improved, speed of the application is typically higher and I do not have to stress about the maths.
The aim here is to give you pointers so that you are accurate enough for your application ( Roll form I have worked on was + 5 /- 2 mm)

If so, then you have timing and acceleration issues to work out
This diagram is for Forward Motion Only - Constant Feedrate Speed

It appears that the way you are using the Ultra 3000 you set a bit at the start of the Accel Time to engage Follower mode with Slew (Acceleration Rate). At the end of the accel time you engage the Shear - once the shear has cleared the product on its reverse stroke you stop the Carriage

Problems
1) As you go faster the total distance traveled increases - you can run out of Linear length (total Screw travel)
2) The Accel distance is dependent on the Slew rate - So in your PLC you will need to use maths to work out when to start your motion so that at the completion of the acceleration you are in the correct position

(simple version only) s = (v^2 - u^2) / (2*a)
s is distance traveled during acceleration from speed u to speed v
u in your case is 0
v is final velocity
a is acceleration rate
WARNING be consistent in units​

3) If you do not use Slew rate in the 3000, then the carriage starts with full torque (eg 160%) and the stresses on the carriage can be too high (sudden Accel) for the mechanics
4) This is all for when the product feed rate is constant. If the feed rate is changing then this all gets much, much harder with your hardware (On Peters hardware it has no effect)
5) The Shear Time + Accel time + Decel time + Reset time (Return to home) affect what the shortest cut length is at maximum speed. IE the cut length determines the maximum speed of the product feed.

 

[Peter Nachtwey]

We have flying shear applications 'canned' so our customers only have to fill in the parameters for available travel length, cut length, shear time and line speed.
http://www.deltamotion.com/peter/Videos/FlyingShear/
Our motion profiles are 5th order instead of 2nd or 3rd. Acceleration and torques change smoothly.

 

[loundeb2]

The block diagram is correct.
Fortunately the roll form is old and the die's are usually incorrectly set up, so they run it slower then they're able (less then 80FPM). I would like to keep material feed within 40 to 80FPM through the shear. The actuator has a total range of 24" of travel, although, the shear die has only about 14" of travel across the press bed.
I'm by no means an engineer and this is my first interpolated project. The quotes we received for just the flying shear addition were astronomical from Rockwell, my company wants to reduce spending and all they know is we have this hardware available, I have made progress using it, and they are patient with my taking time to get it to work, so here I am.
Is this possible?
Thanks.

 

[Peter Nachtwey]

If the PLC is issuing commands to the drive then it will be too slow

You really need to have the drive do all of the motion calculations. The PLC should only be supervising and handling simple on and off type of functions that aren't motion dependent.

In a previous thread you said the cuts were off by 3 inches for one speed and 3 inches there other way for another speed. This sounds like a calculation problem as it would be a very big scaling error or difference due to slippage,
It hasn't been clear to me if the encoders are scaled properly yet. If so can you get a trend of the motion?

MichaelG is right about working out the velocities and times. I do want to point out that MichaelG's acceleration calculation is for the average acceleration. If you use s-curves the peak acceleration us usually 50% higher than the average and the motor and drive need to be able to handle that.

What kind of commands are you giving the drives.
What have you computed for ramp times and distances? If the drive can store a cam table that is the way to go. Use the line encoder to index through the cam table.

How accruate must these cuts be? At 30 fpm or 5 ips every millisecond is 0.005 inches of error.

 

[loundeb2]

Thanks Pete,
There isn't slippage and the encoder is tracking properly with a new wheel. The accuracy I need is 1/16" variance max.
I don't have the equipment available to me today, but I'm sure the slew limit is out of range if I remember correctly. I believe it's set at 800 Rev/s'2 in Ultraware. There is an oscilloscope in Ultraware I can use to trend, but I don't know if I can download and save plots. The only commands are "start following" when the length is reached, "up to speed" output to cycle shear when following, "start homing" after the shear is made, and fault output and reset input.
I really need advice on how to set up the most precise speed/position match possible with this hardware and which flag to use to fire the shear. Would precise position tracking be the same as precise speed tracking? If so, wouldn't I be able to set up the drive like a stepper and adjust the slew to fall within the necessary time at the highest speed?

Lou

 

[OkiePC]

Isn't there a flying shear example for Rockwell's Ultra3000? It seems Electrocraft had one.

I would think you could replace the master axis with an external one, wire the aux. encoder directly to the drive, and trigger the different moves internally on the drive.

Back in the day... , we could make this happen with hardwired option interrupts to still allow PLC hardwired control for jog, home, etc, but when we enabled the gearing program, it was all in the drive. You can program a sequence in the Ultras where one program triggers the next to do what Peter's Video beautifully illustrates.

Peter, I think I can shave that mpg down under the Youtube 10minute limit if you are interested in making it more email/web friendly.


The position error tolerance can be monitored to trigger the cutter action with a digital output to a relay if necessary, and the PLC can monitor that relay to ensure that the error is acceptable during the digital cam output for cutter engaged (another digital output from the drive).

So yeah, it can be done, but it would be faster and easier to trade up to a sweet motion controller.

Did you watch Peter's video? Wow. So simple, so powerful, so slickly brought to the display.

His link takes you to a folder in his FTP site and its the big zip at the bottom.

 

[loundeb2]

Yes, I have the Rockwell flying shear program saved for reference, but it's based on the ControlLogix controller with motion and RSLogix 5000, which I also have. I tried to get my company to consider these options, but because I'm new to alot of this motion profiling, we're not confident about guaranteeing an easy/quick solution and I don't want to tread into new hardware until all options are exhausted.
I will try to save copy/s of the plots in Ultraware while running on Monday, no holiday's here. I'll photograph the pc screen otherwise and post it here.
Another quick question. Could I also output the motor encoder pulses to the HSC module, then use the plc to fire the shear output when a speed match is made? I imagine I would have to add rungs of logic to make this work, but is it worth trying?
Lou

 

[OkiePC]

Yes, I have the Rockwell flying shear program saved for reference, but it's based on the ControlLogix controller with motion and RSLogix 5000, which I also have. I tried to get my company to consider these options, but because I'm new to alot of this motion profiling, we're not confident about guaranteeing an easy/quick solution and I don't want to tread into new hardware until all options are exhausted.

This is a mistake IMHO. You should learn to do motion the easy way and the right way before you go kicking out 'el cheapo imitations of it. No offense intended, just my opinion.

Another quick question. Could I also output the motor encoder pulses to the HSC module, then use the plc to fire the shear output when a speed match is made? I imagine I would have to add rungs of logic to make this work, but is it worth trying?
Lou

Again, that is the wrong direction. The PLC should only tell the motion controller when it's okay to continue, and what mode to be in. This can be a comms interface or digital I/O. Your PLC running the rest of the machine needs control over when the cutter is homed, jogged, and place in auto.

When in auto, the servo-amp/controller are in charge and it runs the program.

The parameters for its motion can come from the HMI via the PLC, and commands can be programmed and triggered by digital I/O if required to handshake the sequence...the PLC will likely need to know the direction of the cutter and when it is geared, basic status (fault relay)...The PLC doesn't need to have anything at all to do with position encoders unless it's a motion based PAC.

Any servo amp with even the most modest "brains" is capable of camming a digital output to an axes position, and that is what should trigger any external mechanisms required to engage the shear.

You can't reasonably externally expect ... with a separate slow PLC ... to be able to tell the servo amp when to engage gearing without introducing big error (bigger than you1/16" and larger with velocity) ...

It is always done in the motion controller* where that error can be corrected 200 times per second.

*The ultra is a simplified multi-function semi-motion controller, but will never be capable of full-blown high performance coordinated motion until coupled with something like the RMC or Logix motion.

Ultraware o-scope is actually pretty good. I wanna say I had good results in the one system I had to set up from scratch.

 

[Peter Nachtwey]

Ditto what OkiePC said above. You have the wrong tools for the job. You should be programming in position units and not revolutions. It is because you are new you should have bought something with a canned program where all you need to do is change a few parameters. You need a system with better diagnostics. If you can't see what is happening then you cant see what is wrong and be able to fix it. This is not only important now when you are getting the machine to run but also when maintaining the machine over its life span.

OkiePC is also right about doing it all in the motion controller as communications take too long. From the time the master encoder is read to the time the slave control output is updated should be on the order of a few micro seconds and we do it 2000 times a second. Even communications across a back plane can cause considerable delay when the gearing must go from one card on the back plane to the PLC and then back to another card.

In our case only a generic dumb drive is required as the smarts inside the drive are not used. The PLC is not required either unless there is a lot of I/O.

Finally, there are the math algorithms that are used to implement the motion profile and all of that must be done as a function of the master encoder position, velocity and acceleration. Do you know what the chain rule is? Without it you can't gear and use feed forwards. Then there is the issue of how do you compute the velocity and acceleration of the master encoder. Yes, you must filter the encoder but most on this forum have a hard time calculating a smooth velocity let alone a smooth acceleration.

Peter, I think I can shave that mpg down under the Youtube 10minute limit if you are interested in making it more email/web friendly.

Thanks, There are actually two videos there. I have a Mac with video editing software and do the editing myself. I am not that good at it because I find it tedious. Let me give it a try first.

Did you see the rough first cut videos for MTS sensors? It is an example of extreme synchronizing. The first cuts are in my Videos directory.
This is the official MTS version on their site.
http://www.mtssensors.com/news/index.html
A person moves the dart. The motion of the dart is therefore random and not consistent. The motion controller updates a trajectory for the ballon so that the dart will just touch the balloon before moving synchronously. It should be obvious that any phase lag would cause the balloon to pop. The ONE MICRON resolution allows us to calculate an accurate position, velocity and acceleration for the dart and balloon which is necessary for computing the trajectory of the ballon. Since the human isn't consistent the trajectory is updated each scan. Nothing is canned here. All the calculations are done on the fly. Cam tables would not work. This is possible because of the fine resolution and high update rates and advanced algorithms that go far beyond simple position gearing. One must have good feedback. One must have good algorithms, one must have good diagnostics and finally a lot of processing power to implement it all.

This was programmed by one of our engineers over the internet using the software in the flying shear video. He has never seen the physical demo in person, just the videos. The error between the dart and the balloon had to be consistent within a few thousands of an inch or the dart would pop the balloon. The graphs were able to verify the algorithms and tuning so not too many balloons were sacrificed.

Lou, this could be easy but you are using the wrong equipment, reinventing the wheel and there are things you should know that you haven't even thought of yet.

 

[loundeb2]

Okay and thanks for the replies.
I will probably play around with what I have till our production season starts to kick into full swing. What I would like is a recommendation for a canned system that would interface to what we have now, minus the shear servo/drive portion. A bundled system(drive, motor, etc.) would be great.
Thank You,
Lou

 

[Maverick05]

Good Evening.

Sorry to bump this thread up but I have a Question about the Ultra 3000 using the Follower auxiliary encoder mode.

At my company they are asking me to upgrade a dose machine with a Servomotor. They gave me access to a MPL-B540K-MJ22AA servomotor and a 2098-DSD-HV150-SE Ultra3000 drive.

We use an S7-200 cpu224xp to control another Ultra3000 (DSD-HV220) using PTO in Follower:Step Direction in the same machine, but I don`t think that mode is available in the HV-150-SE due to the Serco`s configuration.
I want to use it in an Open-Loop control, and I don`t need it to be accurate.

So I was wondering if it`s possible to use the Auxiliary Encoder/Master Code mode to control the servomotor using the S7-200`s PTO? And do you know any manual or diagram I may use as reference.

Thank you.