external motion control from KRC

[wes_mcgee]

So a couple of months ago I successfully implemented a WAGO devicenet stepper controller to control and external motor from the KRC. It worked OK, but we are looking to scale this up. I feel like we have hit our limit using a stepper, and am thinking a large servo is the way to go. I can get a 4000W servo and drive for around 3k$, and a big planetary for another 3k$. I assume I would just use serial communication from the WAGO bus. This has the disadvantage of probably not being able to do synchronous motion.
   At this point I decided, well, why not ask kuka about using an external positioner, like the KPF-MD1000. My first question, which is probably rhetorical, is why does this unit cost 12k$? That includes drive, brake, cables...but that is still double the price, and either way I have to integrate it. I assume the answer is because "it can". My next alternative is to get a standalone kuka motor, I am looking at MGU3100-101. This would have 3x the torque and I can integrate it directly into my external mechanical components. I don't expect this to drop the price much, as the only part missing compared to the KPF is the positioner base. I am crossing my fingers though.

The application is a robot assisted tube bending cell. IE, this is for the bender, with the robot performing positioning and bend plane control between bends. It worked with the stepper, but only with pretty small diameter material. The MGU 3100 has 20 times the output torque of our current setup.

[SkyeFire]

Unfortunately, KUKA robots and components cost a lot.  You generally get your money's worth, but the simple fact is that the market for these items is too small for economies of scale to kick in.

OTOH, buying a KUKA motor and driver gives you a system that is guaranteed to integrate directly and seamlessly into your robot, without having to fight with writing custom driver software.

There are quite a few companies that deal in second-hand and refurbished robotic hardware, some of them quite reputable.  If you can find one, you might be able to find a better deal on these parts.

[wes_mcgee]

good idea, I didn't even think about a used positioner. Also, I realize the gear/servo may be a much higher quality that I am getting from my other source. Was just looking at harmonic drives website, and realized that all gearheads are not created equal(no I didn't really think that).

[wes_mcgee]

So I am still working on this project, but the demands have changed a bit. I am considering implementing and extremely "simple" analoque servo/hydraulic control system. I see two ways to do this:

1. Use a simple external controller with 1 axis servo card, and send position commands from a WAGO RS 232 card in my KRC, or I think it might be possible with certain servo drives to do this without an external controller, KRC supplying a step + direction output(I am sure WAGO makes something to do this)

2. Use a wago analogue output and a wago incremental encoder input, and close the position loop inside the KRC. Has anyone done this? This would be 1 axis position control....should be easy. The robot wouldn't have to even be moving while this external axis was indexing, though if it was that would be nice. For the robot to be moving while a control loop was functioning may not be possible though. I have to admit I am a little inexperienced writing a program for something like that.

Backing up a bit....Can a simple position control loop be written in KRL? Could that be run in the SPS so that it could happen during robot motion? Am I way off here? Perhaps this is not enabled in software(as a way to force you to buy kuka drives and move them async)

[gianne]

hi,
i did in the past something like that, with loop position control inside sps, so the robot can move while the positioner reach the position programmed.
So the answer is, yes you can.
But considere that cycle time of sps is not so fast, so the performance of you control loop depends on how much the motor has to move fast and how much is reduced in rpm.

gianne.

[SkyeFire]

Wes:  Option 2 is definitely doable, although there are some potential pitfalls. 

If you want this external servo to be under closed-loop control at all times, regardless of what else the robot arm is doing, then using the SPS is pretty much required.  The SPS can do it, but you need to make sure that your SPS timing is consistent -- that is, no major branches, no wait states EVER, etc. 

Also, keep in mind that the SPS gets called once every 12ms, but only runs for a certain amount of time before it gets paused and processor resources get handed over to another task.  This means that a short SPS program might loop multiple times during one time slice, but a long SPS might not make one full cycle in the allotted time, leading to inconsistent behavior -- I've seen both happen.  The I/O table also updates every 12ms, so I'm sure you can see the kinds of things that could happen with a too-long SPS.

There's also the time constant of your servo and feedback mechanism to consider.  If your servo gain is too high, or the unit is just a bit too jittery, a 12ms cycle might not be fast enough to keep it from "hunting".  This is why servo motors usually have dedicated closed-loop controllers with insanely fast reaction times, so that the smarter-but-slower higher-level control doesn't have to keep up.

The other thing to keep in mind if you set up your own servo control loop in the SPS is gain, PID control factors, etc.  Again, doable, but not guaranteed.  It could be easy or very very hard, depending on the dynamics of your external servo and just how tight your requirements are.

The safer bet is to use the external servo controller and command it via RS232.  OTOH, if you've already got the parts and have some time to experiment, Option 2 is worth taking a shot at.  If nothing else, it'll be educational.   

[wes_mcgee]

Thanks for the replies!

I agree, the 12 ms is a concern, but I think my bandwidth here is super low. I want to position a 90 degree move in 2-3 seconds....I assume I can set my gain pretty low. Maybe that is an oversimplification....for reference, I am using this to drive a rotary draw tubing bender, where the robot is handling the distance between bends and rotation plane between bends.

I think I will give it a shot, if it doesn't work, I can add the ext control in the middle and just send position commands. Any idea if upgrading to the RSI interface(I currently have the XML interface, which allows access with a run stop) will help? Supposedly this gives real-time capability for updating variables....so I was thinking I could pass position info back from the external encoder to make the robot coordinate its motion better. My feeling is this "might" work since this is just one axis of motion. I am sure anything more complicated requires synchronous motion(math coupled). I guess this will be math coupled as well, just not as high of a math!

[SkyeFire]

I don't think RSI is going to help you in these circumstances.  RSI is still limited to 12ms (although the latest prototype is supposed to go to 4ms!), but it is a hard 12ms -- always guaranteed, whereas the SPS can vary.

The bigger issue, though, is that RSI is designed to let you directly connect the robot's motion to a realtime control sensor.  If you were doing your bending with robot motion rather than an external servo, and using a force/torque sensor, RSI would be the way to go.  I've done it, and some of the stuff you can do with RSI seems downright miraculous when you're new to it.

Plus, RSI won't work with RS232.  It will do regular digital and analog I/O, though.

As to your time constant, yeah, 30deg/sec sounds doable.  Certain mechanical issues like inertia or vibration could still hurt you, but you can probably come up with ways to deal with them.  Especially if you can have a generous tolerance window for your positioning -- trying hold the encoder within +/- 5, or even 10, is a lot easier than trying to hold exactly at a given value.

[wes_mcgee]

Thanks,
  Yeah the reason I wanted to coordinate the motion with the robot is that we are pursuing the type of rotary draw bending where the tube is pulled into the dies....the robot replacing what would be a rotary axis on a linear slide. Of course we can actually let go of the tube if we need to, and grab it again after it stops moving. Another goal though, would be to use roll bending on the same actuator, such that the rotary encoder/servo hydraulic simply positions the roll dies, and the robot has to "push" the tube through this die. Not sure if we can apply the necessary forces to do this though, so it may not matter. Of course even then, the motions don't need to be coordinated unless you want to vary the radius of the rolled bend continually.

We are also "looking" for a reason to use RSI, because as you describe it it does sound pretty amazing...perhaps a 1D external force sensor could be a good place to start, like a grinding cell. We would like to incorporate some notching or endforming into this cell, though that can probably be done without force feedback.

[SkyeFire]

Yeah, RSI is Really Cool.  It's also Very Different from regular robot programming, so be prepared to have your brain bent.  And because it's essentially letting you get right at the low-level path planner, you're operating below most of the software safety layers -- for example, if your RSI program tells the robot to move at 2m/s, it will... even in T1.  Being careless with RSI is a good way to get killed, even with a teach pendant in hand.  Extra caution, above and beyond the normal levels robot-guys usually think in, is required.

For your purposes, I would strongly suggest buying the KUKA Force-Torque Control package, rather than RSI.  The reason is that FTC is a special app built on top of RSI, which means that when you install FTC, you get a full RSI install as a side effect (one caveat: the RSI version bundled with FTC may not be the very latest version of RSI, so you might miss out on some features, like Ethernet communication.  So choose your packages wisely for your needs).  The advantage here is twofold:  you get all the pre-built FTC tools which can save you a lot of low-level coding (and lets you peek at functional RSI code), and nothing stops you from adding custom RSI code that can run in parallel, and interact with, the FTC code.  For example, you can have two completely separate RSI modules driving the robot's motion -- you can run them separately, but if you run them simultaneously, the robot moves as the vector sum of the control outputs of both RSI modules.  So you could set up, say, a seam-tracking module and an anti-collision module to "fight" each other in such a way that the anti-collision module would "null out" motion commands from the seam-tracking module that would cause a collision, but leave other motions untouched... and neither module would need to be aware of the other!  The possibilities are staggering.

For a load cell, if you can swing it budget-wise, go for a full 6-DOF load cell -- you'll love it.  Even if you only use 1D of it, you can still do massive data collection on the other 5, and you might be surprised how handy that can be.  RSI was made for people who love to collect lots and lots of data for after-action analysis.  And a full 6DOF gives you openings to try things you never could with a 1D.

On the subject of load cells:  FTC is designed to take into account the difference between where the load cell is mounted, and where you want to be measuring the forces and torques -- the load cell might be mounted right at Axis 6, but you want to know what the loads are out where the end effector is bending the pipe.  FTC can do that, although obviously the further apart those two locations are, the less accurate your measurements become.  Plus, you need a Really Good 6DOF measurement of their geometric relationship to make this work.
Also, FTC is designed to accept load data from regular analog-input modules (although it uses digital mapping rather than ANIN) over Profibus, DeviceNet, etc.  But you'll need to make sure that your analog module measures at 84Hz (every 12ms) or faster -- most industrial analog input modules update every 50-100ms, and that would hurt your RSI application badly.

[gastonbuab]

Is not really possible to make a direct external axis control with an analog output regardless of the closed loop?? Or out for a pulse and direction without using closed loop serv? Can I do that with KUKA?

I'm trying to do something very similar, I have all the mechanics of a KUKA KR150 rail with a KRC2-2 with a Yaskawa servo motor and driver but I can not interconnect it with the robot so that interpolate axes, right now I do is use with standard 6-position of the robot outputs to a PLC which controls the driver of servo. For example:
outsrobot - position rail
000 - 1 pos
001 - 2 pos
010 - 3 pos

The question is: Can not do any kind of output to an external driver of a servo from another brand and that the robot recognizes it as an external axis and it moves when I move the coordinate of X for instance?
Like an analog output or pulses and dirección output or serial conecction direct driver with a module Beckoff or Wago I don't know, I work a lot with KUKA robots with KRC2 but nothing with external axis.


Much thanks for any help.

[SkyeFire]

I could hardly understand any of that.

If I understand correctly, you want to control a non-KUKA servo with a KRC2, and get axis interpolation? 

Well, to start with, you would have to have good realtime control and feedback from the external servo to a high degree of precision.
You will need some way of sufficient realtime communication between the KRC2 and the external servo.
You will need some means of connecting the robot's realtime motion to the realtime action of the external servo.

RSI or FTC are probably the best way to go about this, but it will not be easy.  For robot/servo intections that are not very complex, the Function generator might be sufficient.

Achieving high-resolution realtime control and feedback of the external servo will be dependant on that servo and what it can do.

In the final analysis, it might be cheaper and easier to replace the Yaskawa servo with a KUKA servo and use "normal" kinematic integration.

[gastonbuab]

I need that, can you help us in a normal kinematic integration with a manual or some?

[SkyeFire]

Normal kinematic integration will only work if you are using KUKA (or compatible) servo motors for your external axes.