Kuka vs Staubli robots with AB CPX

Weighing up options for next years projects. Has anyone any experience interfacing either Kuka or Staubli (or both) robots with Allen Bradley controllers? Kuka has an AOP available to download from their website, Staubli has emailed me instructions for setting up a generic ethernet module.

Let's ignore other factors, for now, such as price difference and already established standardisation.

With the only difference I've researched so far being AOP vs GEM, is there much extra programming required for GEM?

Hi,
Although I cannot add any review on Kuka to allen bradley. Figured id put this out there.. in a recent project I had to use a Kuka in a machine tending application. Not sure how large your application is but mine was smaller just two CNCs and a section of conveyor automation. So what I did was added Beckoff IO in my CNC machines over etherCat as well as the Festo valve stack and IO etherCat comm module on the conveyor. Since the Kuka is naturally running Ethercat, it was easy to string it out. But yes then you are stuck programming everything in the Submit Interpreter of the Kuka. Worked out well though.

As your in the UK, Routeco have just partnered with Yashawa and you can program the robot directly from RS Logix, which whetted our appetite.

You Tube and their sales stuff suggests it makes it easy, there is a demo rig at their MK Office which I am going to see at the end of the month.

I don't know if Routeco covers NI though, but maybe worth a thought.

Thanks for the replies. Bill, we already have AB, Kuka and Staubli onsite although to date they are not existing in the same application. I want to avoid adding another brand to the mix if I can avoid it.

Janner, could you update this thread after your MK visit? These are simple pick and place applications, but for future more complex work your suggestion could be applicable.

Can anyone offer advice on the AOP vs GEM setup?

Will do.

the_msp said:

Can anyone offer advice on the AOP vs GEM setup?

Click to expand...

Not from the context of robots specifically, but being one of the forum's young whippersnappers, I love me an ethernet/IP device and have used quite a lot of them. Having an AOP is often what gets a device over the line with respect to it's competitors for me, it just makes things so much easier initially.

Once it's set up and working, it's somewhat less relevant, but if I were in your situation, I'd have to see a definite advantage to the GEM robot in some other way to consider using it over the AOP robot.

Can you expand a bit please ASF?

I have two SMC (pneumatics) devices in my current project. An LER rotary table that is GEM and an EX260 manifold that has an AOP.

In terms of clicks to success I would say they are about similar? By the time you find, download, unzip, import the AOP, versus setting the assembly data in the GEM. I ended up with the same tag wise, just a set of SINT data for both. Do some AOP's pre-name the data structure? I would see that as an advantage.

P.s. actually using an Epson robot.

the_msp said:

Can anyone offer advice on the AOP vs GEM setup?

Click to expand...

AOP is already set up in term of tags in Allen Bradley. You just download and import the AOP. Assign the IP address.

With Generic Ethernet Module you will have to set up this manually. I/O, Assembly Instance, that should be given in documentation. The tags are not defined as they are in the AOP. You will have to define them and test them yourself.

Thanks

Understood, but my last question was do some AOP's pre-name the tag structure, instead of e.g. Epson:I.data[0]

Of course for epson this doesn't matter as the fieldbus IO is not pre-populated and must be all custom set by the user

But for the SMC LER, the tags data are pre-defined/written

Anyone?

yes depends on the manufacturer. For example if you ever download a aop from cognex they have all their tags defined for trigger, set id. Another example is AB Powerflex 40 AOP has all of its tags defined for the different variables. Others do not pre name them but should provide documentation as to what the tags reference.

OK thanks, I need to feed back to SMC to up their game

the_msp said:

Can you expand a bit please ASF?

Click to expand...

It's been pretty well covered above, but yep - it's mostly just that AOP's can have meaningful data structures instead of just an array of SINT's.

Of course, a good GEM implementation will still wipe the floor with a bad AOP implementation - just having an AOP doesn't guarantee that it's inherently better than using the GEM option - only that it has the potential to be.

Best case scenario on GEM: your instance numbers, data types and data structures are all well documented and easy to find. You set up your GEM, add in all of that data manually, write some code to map the data into meaningful tags, and you're done. Relatively painless.

Best case scenario on AOP: your AOP is well constructed with meaningful tag names and is easy to find/download/install (some devices actually have the AOP available on the device itself downloadable from a web browser). It's also well documented, but that hardly matters because you just install the AOP and drop it in, and you don't even need to map anything, you just start programming.

Worst case scenario on GEM: your instance numbers, data types and data structures are poorly documented, documented incorrectly, have been changed since the manual you have was written with a firmware update, or are simply not published anywhere you can find. You spend a lot of time hassling distributors and/or tech support trying to get the information you need. Eventually you get it communicating and then have to do some playing around to work out how the different commands and statuses interact. Then you write some code to map the data into meaningful tags. Hugely painful, and yes, I've had devices like this. One device in particular had 7-8 different manuals, and none of them contained the instance data. Tech support couldn't find it anywhere, eventually they fired up one of the developer's laptops and took down his settings from a test rig. It must have taken me 40-50 emails back and forth with tech support to nail down the complete functionality of all of the data.

Worst case scenario with an AOP: the AOP just gives you an array of DINT's, vaguely named with things like "StatusWord" and "CommandWord" and very poor documentation as to which bits in each word do what. You're in a similar position to where you were in the GEM worst case scenario, except at least you don't have the added complication of having to find non-documented instance numbers.

TL;DR - a well-documented, well-supported GEM implementation will beat a poorly-developed, poorly-documented AOP. But a good AOP beats a good GEM, and a bad AOP still beats a bad GEM

TL;DR

Click to expand...

Don't worry I read the whole thing... thanks

some devices actually have the AOP available on the device itself downloadable from a web browser

Click to expand...

Hey, great tip! Whilst the SMC doesn't have the AOP on its browser page, it does have a data structure. Words are defined, individual bits aren't but there's more there than in the manual - thanks!