PDA

View Full Version : ABB robot talking on deviceNet


rigicon
March 18th, 2010, 12:32 PM
Anyone had experience talking to a ABB robot with devicenet option on a PLC. Question is, could one talk to multiple robots(slaves) with PLC(master) using devicenet.

TurpoUrpo
March 18th, 2010, 12:43 PM
Why not?

Paul T
March 18th, 2010, 02:02 PM
Anyone had experience talking to a ABB robot with devicenet option on a PLC. Question is, could one talk to multiple robots(slaves) with PLC(master) using devicenet.

Check with your ABB rep, but it shouldn't be a problem. If they supply a DNet board, they should also supply an EDS file and the PLC doesn't know it's a robot, it just sends/receives data the same as any other device. There is probably some custom software that has to be installed on the robot's controller or control PC, but ABB should have that too.

We just did this with a Staubli robot last summer. They have a board in their chassis (or maybe their PC, it was easy enough that I can't even remember!) and an Applicom driver in the PC that runs the robot. The whole thing set up easily and has been running for nearly a year now with no fuss.

rigicon
March 18th, 2010, 03:16 PM
I went to ABB today and indeed they told me DeviceNet is their norm although they can do profibus canbus etc. They also showed me how to configure the robot to talk via deviceNet with the generic driver (EDS) or I could use the specific PLC EDS.
The robot is to be the slave only prob is I forgot to ask if multiple robots could be connected but I agree with TurpoUrpo (http://www.plctalk.net/qanda/member.php?u=42449) Why Not?
Is it then just a matter for the PLC to talk to the specific node number? I will have 5 robots talking to the PLC which I personally think shouln't be a problem.
I suppose I am just asking the question to reassure myself.
Thanks for your comments Paul T (http://www.plctalk.net/qanda/member.php?u=23306) much appreciated.

thiem
March 18th, 2010, 03:22 PM
I assume (you do not state the robot controller type) that you will be using an IRC5 controller? For this you will need to order option 709-XX. We usually order a two channel DNET card, so we get a 709-2 option.

We set up comms over DNet from Rockwell PLC's to IRC5 on almost all our robot projects. Setup is straight forward (after you can obtain an eds file from ABB for the DSQ dnet card that is). Use the (in our case AB 1756-DNB) Device Net scanner as the master and use the IRC5 controller as the slave device. Then just map away. Depending on number of bytes/robots and interscan delay settings may impact speed response for time critical handshaking requirements.

The robot side of setting up the unit type and then using the EIO file to set up your 'tags' from the DeviceNet scanner can be interesting if you haven't done it before.

As a side note, the robot setup is the same for both DNET and say EthernetIP. You can order a DSQC 669 card for an ethernetIP option instead of DNET if desired. The only robot difference will be the unit type you have to setup.

rigicon
March 18th, 2010, 03:43 PM
Yes definitely IRC5 new. Interesting about the EthernetIP but sounds too complicated for me/ scared I mean would the PLC & robots be on their own network.
I think I'll stick to deviceNet(to late in the game) Actually bit annoyed with ABB as they didn't mention the ethernetIP option and now the quote has to be in tomorrow morning first thing. Actual control will only be start/stop at end of cycle and how many have you made nothingtoo time critical. The robots are pick & place to injection moulding machines.
Never setup DeviceNet from robot to a PLC but did set up a DeviceNet analog module to a ABB so yes its going to be interesting.

kiwi sparky
March 19th, 2010, 09:43 PM
Yes, you can set up multiple ABB robots on devicenet. I Have done this plenty of times. Just need to set node address in Robot studio software

jcr
March 20th, 2010, 07:25 AM
Yes definitely IRC5 new. Interesting about the EthernetIP but sounds too complicated for me/ scared I mean would the PLC & robots be on their own network.
I think I'll stick to deviceNet(to late in the game) Actually bit annoyed with ABB as they didn't mention the ethernetIP option and now the quote has to be in tomorrow morning first thing. Actual control will only be start/stop at end of cycle and how many have you made nothingtoo time critical. The robots are pick & place to injection moulding machines.
Never setup DeviceNet from robot to a PLC but did set up a DeviceNet analog module to a ABB so yes its going to be interesting.

Too bad it's late in the game for you. I've used ABB Robots on Ethernet with ControlLogix and it worked great.

rigicon
March 20th, 2010, 08:35 AM
jcr (http://www.plctalk.net/qanda/member.php?u=23096) Too bad it's late in the game for you. I've used ABB Robots on Ethernet with ControlLogix and it worked great.

We have the order now so as long as the system works,we can change our minds I am thinking of MODBUS TCP/IP over ethernet as it looks like we are going to use Citect SCADA.

Paul T
March 22nd, 2010, 02:44 PM
I'd check into the Ethernet option. DNet is ok, but Ethernet can probably map directly into the controller memory without the network configuration that DNet requires. Also, DNet means that you have one more set of software to maintain, and DNet devices are firmware dependent which can be a problem in the future.

True, some of this may apply to the ENet solution too. But, overall the ENet solutions I've seen in the last few years have been easier to set up and maintain than DeviceNet. The only reason we went with DNet on our project was that Staubli did not offer an AB-compatible Ethernet at the time (for SLC and Logix500, anyway). And, we were retrofitting an existing cell that had already been done using DNet ten years ago... so adding another DNet node was not a big deal.

rigicon
April 15th, 2010, 11:00 AM
Now it has been decided 5 ABB IRC5 robots with deviceNet talking to a PLC which has Ethernet and DeviceNet on board and Remote DeviceNet IO connect to the PLC. The robots can access there Remote IO.and the HMI can access the PLC.
ABB UK could support DeviceNet better than EtherNetIP so thats the decision.

Now the big question what PLC? tending towards AB for the PLC and Wago for the IO. Any comments will be appreciated Thanks.

ABB UK could support DeviceNet better so thats the decision.

TurpoUrpo
April 15th, 2010, 11:09 AM
ABB plc?

Paul T
April 15th, 2010, 02:38 PM
Now it has been decided 5 ABB IRC5 robots with deviceNet talking to a PLC which has Ethernet and DeviceNet on board and Remote DeviceNet IO connect to the PLC. The robots can access there Remote IO.and the HMI can access the PLC.
ABB UK could support DeviceNet better than EtherNetIP so thats the decision.

Now the big question what PLC? tending towards AB for the PLC and Wago for the IO. Any comments will be appreciated Thanks.

ABB UK could support DeviceNet better so thats the decision.


Well, since DeviceNet the five robots are going to map into five separate memory areas in the PLC. Actually, ten separate memory areas since the reads and writes will be treated as OUT and IN by the PLC.

The rest of your IO will also map into memory via DeviceNet. How much IO are we talking about? DNET does have limits on what can be carried. The DeviceNet scanner for an AB SLC will only do... I want to say, 314 words or something like that. For old-style IO systems that's fine, but if you need a lot of data exchange between the controller and the robots it fills up fast. OTOH, in the cell we did, we have a six axis robot and we only used something like 15 words back and forth to command it - index it, really, from position to position around the cell.

As far as other IO modules, I've been using Turck BL20 for the last few years. BL20 need to go into an enclosure, but they're cheap (relatively) and they work well. Turck's BL67 is the same thing in a brick that can be mounted externally to a machine, but they cost a ton because of that. The only issue I have with Turck is that they've changed the firmware four times in the last four years, and every time they do those new modules won't work on the "old" machine because of it. Aside from that, they're fine.

Wago is probably just as good; I just have a relationship with the local distributor for Turck and we get decent pricing and support, so we went with it. Since we're an end user, albeit one who builds their own machines, I don't buy a lot relative to an integrator or OEM, so the vendors who will still give us an integrator discount get our business.

Big thing on the PLC is:

- How many DeviceNet nodes, and how many words?
- How complex is the system? Lots of logic, or only middling?
- What have you programmed before that will handle DeviceNet?

If you've used another controller that has DeviceNet capability, I'd look there first. Programming is the lion's share of the cost; you can get your vendor to help set up the DNet if need be. Just make sure you've thought about your network first so that you only have to do it once.


Edit - just saw the other thread, LOL!

So what's going to the the master, the PLC or the robot? My experience has all been using the PLC as a master to run the cell, and the robot being triggered by the PLC when needed. The robot's own software then executes whatever the PLC has requested.

Our robot also has grippers; the robot runs them itself (when necessary) as part of a "Dropoff" or "Pickup." The PLC simply requests Pickup, say; the robot then executes that action. The robot is also wired with a laser sensor to locate the tooling, as well as the gripper solenoids and limit switches to run the grippers. The robot acks the original request, then sets a Done flag to the PLC when done.

DeviceNet doesn't allow shared memory AFIK. The Master will poll the slaves, or, look for COS from the slaves is how I do it. So, the Master has all the info from each slave device. You can then write logic in the Master (PLC for me) to "share" things, but you're using up more DeviceNet words to do it, as it's still just IN and OUT to the network.

rigicon
April 15th, 2010, 03:26 PM
ABB plc? TurpoUrpo (http://www.plctalk.net/qanda/member.php?u=42449) I take it you mean use a ABB PLC on a ABB Robot - Ummm nice one - never programmed ABB PLC's I'll try get some more info from ABB.

Paul T (http://www.plctalk.net/qanda/member.php?u=23306)

The idea from ABB is 5 robots with single port devicenet talking to a Master PLC (?) This PLC will ineffect be the DeviceNet scanner.
The IO will be 32 in 32 out per robot 1 to 4 the 5th will have 48in 48out. There will be 5 remote IO one per robot plus an additional 3 for some conveyor control no more than 32 IO per conveyor node as below.
Robot 1 = 32I + 32O = Node 1
Robot 2 = 32I + 32O = Node 2
Robot 3 = 32I + 32O = Node 3
Robot 4 = 32I + 32O = Node 4
Robot 5 = 48I + 48O = Node 5
Conveyor 1 = 16I + 16O = Node 6
Conveyor 2 = 16I + 16O = Node 7
Conveyor 3 = 16I + 16O = Node 8

Total = 224I + 224O = 448 Physical

I think the Physical IO count is not that much there will be Virtual IO but only 2 words per robot.

The PLC must have a ethernet port be it EthernetIP, Modbus TCP/IP etc to talk to a HMI come Scada setup.
The PLC must be pretty powerful I know that but which one ?

Paul T
April 16th, 2010, 06:28 AM
I'm assuming all your IO so far is discrete? Eight nodes and 500 points is not a problem. You'll probably want some integer words to the robots, too, but you have plenty left.

What HMI are you planning to use? And as far as PLCs, which ones have you programmed before?

Like I said, I think that the logic will be a lot more expensive than the hardware. Nearly any PLC is going to support DeviceNet. So which PLC's do you have experience with?

rigicon
April 16th, 2010, 08:06 AM
By discrete - do you mean Remote digital IO separate Inputs & outputs then yes.
HMI will probably be Proface , I did like red lion but we got a sweet deal from Proface.
PLC's well most really Siemens, Allen Bradley, schnieder, omron, mitsubishi, toshiba etc.
Was tending towards Allen Bradley for this one. Just finished a controllogix job nice PLC.
Problem stems from the fact that on the one hand talking devicenet and the other hand talking over ethernet to the HMI's/Scada so the PLC will have to have both ports at least.
Thanks for the reply.

thiem
April 16th, 2010, 10:13 AM
Between your two threads on this topic, it looks like you have picked your path and are now moving forward. Your choice of network (given that you fully understand the details of implementing each) is not nearly as important as how you are going to implement it. There are at least two (and probably many more) things you cannot program your way around; breaking the laws of physics (no matter what production will tell you) and bad/incorrect hardware.

Between your posts, there is very little about the actual system requirements. Therefore it is hard for anyone to say that your concept will or will not work for you. Does your system require complete correlation between the motion planner and the tooling reactions? Are you already concerned with the speed/cycle time of the system that shaving 200-300 msec on a couple moves will be needed to make rate? Is the process intense so that a multitasking controller is needed to keep shoving points into the motion planner and leave the comm handling to another background task?

If you plan to have very simple, straight forward robot code that looks like:

MoveL
MoveJ
waittime
Set grippersON
MoveL
MoveJ
Reset grippersON

Then your system reqirements are lax, and you should have no worries about motion planner correlation and shaving time out of your cycle time (meaning you have at least 0.5 seconds to spare already in your cycle time). If you need to know that your grippers are going to close at exactly 14 mm from point x on your part, then I really question your topology choice for your I/O handling (meaning you plan to use trigg statements to run your tooling I/O).

At any rate, at best you will only break even on money (total cost of system, time included) by using the singe channel comm card. Sure, your hardware is a couple hundred dollars cheaper per IRC5, but your going to pay for that in DeviceNET mapping, and PLC programming and Commissioning time. The worst case I saw was a pretty large system going on line with 3 people setting up robots and the other guy was doing the supervisory PLC system. PLC system was having some 'issues' and the 3 guys working on the robot cells all went on a long, long break. Why? Their PLC also controlled the Robot I/O.

Paul T
April 16th, 2010, 02:00 PM
By discrete - do you mean Remote digital IO separate Inputs & outputs then yes.
HMI will probably be Proface , I did like red lion but we got a sweet deal from Proface.
PLC's well most really Siemens, Allen Bradley, schnieder, omron, mitsubishi, toshiba etc.
Was tending towards Allen Bradley for this one. Just finished a controllogix job nice PLC.
Problem stems from the fact that on the one hand talking devicenet and the other hand talking over ethernet to the HMI's/Scada so the PLC will have to have both ports at least.
Thanks for the reply.

If you're comfortable, or even just acquainted with, ControlLogix then that would be spot on for this job assuming that the Proface has a driver for it.

The DeviceNet and Ethernet is not an issue. They're totally separate and what one is doing doesn't matter in the slightest to the other. As a matter of fact, the cell that we did last summer has nine DeviceNet nodes for the IO, while the HMI, the PLC and a 4-axis Compumotor 6K motion controller are all on Ethernet. It is fine, except that the 6K's are a little archaic in their Ethernet; and, my HMI is exchanging several thousand tags with the PLC and so things are a little competitive. If I have to work on the PLC, I turn the HMI off first else it takes minutes to upload or download program changes. However, the day to day networking is perfectly uneventful... which is of course what you want.

A CompactLogix is not going to be taxed talking over Ethernet and Devicenet to the system you've described so far. Neither is anybody else's PLC that you mentioned. So, make sure your HMI has a driver for your PLC, over Ethernet, and you're all set.

Sounds like a fun project.

And, thiem, if there are requirements to couple other actuators tightly to robot control, or robot position, then I'd buy physical IO boards for the robot and wire those sensors and actuators directly to the robot controller, then let the robot use them as needed.

That in fact is what we did with ours, although there was no real need to. In some ways, it makes it more difficult. Since the PLC is in overall control of the cell, and the robot only "knows" a limited piece of the cell state, there are times when it would be convenient to be able to have the PLC control the grippers directly. Mostly, when "something bad" has happened and you're trying to clean up.

We did eventually write a little debug interface that lets the PLC (based on HMI inputs) control the grippers by requesting the robot to open or close them; that suffices. But during normal operation, the PLC isn't aware of the grippers at all and the robot runs them itself to do whatever the PLC asked it to do.

rigicon
April 16th, 2010, 02:50 PM
Thank you both thiem (http://www.plctalk.net/qanda/member.php?u=29399) Paul T (http://www.plctalk.net/qanda/member.php?u=23306) for your input. I did make a mistake the last job was a compactlogix not a controllogix used rs5000 and factory view ME - apologies - I therefore have NO experience with controllogix.

The proface can talk EthernetIP or modbus tcp/IP etc most protocols supported.

Paul T
April 20th, 2010, 07:09 AM
Thank you both thiem (http://www.plctalk.net/qanda/member.php?u=29399) Paul T (http://www.plctalk.net/qanda/member.php?u=23306) for your input. I did make a mistake the last job was a compactlogix not a controllogix used rs5000 and factory view ME - apologies - I therefore have NO experience with controllogix.

The proface can talk EthernetIP or modbus tcp/IP etc most protocols supported.


Since CompactLogix and ControlLogix both use the same software, you're all set. And, I'd confirm with Proface that they can talk to an AB CompactLogix, but sounds like you're good to go with that.