ABB robot EthernetIP to PLC & HMI help needed

HI All.
Hope you all had a good Easter.

Was going to order some some new ABB IRC5 robots, which normally come with DeviceNet option and some IO onboard.
Scrapped that as I am now ordering the EthernetIP option with no IO. Same price as the DeviceNet option with no IO.

ABB say easy to configure and it will address 512 IO. Did some googling to find out about EthernetIP and IO modules.

What I don't understand is if I used a compactlogix lets say, the robot wants to see 512 io as such, is this in the memory of the controllogix ..... Do I have to write a simple ladder. Is there a master slave setup. Don't need 512 IO. Is it just mapped, How easy is this to setup?

Any help or discussion is most welcome.

For specific example of IRC5 to Control/Compact Logix controller.

Use a generic ethernet module. You will need to configure the assembly instances as follows: Input-100; Output-150; Config-4. You then need to set up your desired size of data, choose sints, ints, or dints. The only key is the bytes must match in your EIO config on the IRC5 side.

The robot config is exactly the same in the EIO as for device net. The only difference will be that you have to set up the appropriate unit type for you DSQ-669 card for your Ethernet IP card.

So I guess to answer your question, the PLC will act as the master here and control the poll rate when you set up your RPI time through the generic module. Last time we checked, the robot can only be a 'slave' on EtherNET IP. It was not able to control I/O blocks on its own over that protocol.

Cheers thiem

Last time we checked, the robot can only be a 'slave' on EtherNET IP. It was not able to control I/O blocks on its own over that protocol.

Click to expand...

This is a bit worrying so if the robot sends a command eg set digital output 1 on connected to the its grippers to energise, and then waits for lets say digital input 1 to see the gripper closed - this won't work and the PLC will have to do this.
You are right about the DSQ-669 I seem to remember this.

Am I right is saying the following:-
The robot will set an output - in the PLC ladder the robot output will be seen as an input and can be used lets say to drive an output which the robot will see as an input.
A simple no contact to a coil will be needed to be programmed if the robot wants to use the PLC Physical IO. Otherwise the PLC and robot can share the data ( sints, ints, or dints)

Yes, that is what I am saying. The last time we checked, the IRC5 could only be a slave device for EtherNET IP. You should check with your ABB rep to see if this status has changed. Back when we tested this communication format (summer 2008), the response from ABB was that 'we are working to get the EtherNET IP function to be able to control I/O......"

Long story short, even the couple jobs we have put out that use EtherNET IP to talk to the PLC's, we still use deviceNET to talk to the tool I/O.

More food for thought, if you do end up using your loop around example to control your tooling I/O via the PLC, then you need to really be mindful of your plc RPI, and scan times if you intend to use functions like TriggIO and TriggEquip in your Rapid program. These are specifically linked to the motion planner and it is not intended that you have unacounted for delays in your i/o processing.

Again, talk to your rep, maybe the IRC5 can be a master and/or a slave on EtherNET IP. You can run EtherNET IP to the PLC if you really wanted to, and still use DeviceNET to the tooling I/O (for example). The potential benefit for you would be that you would not need a software package like RSNetworx for DeviceNET for that particular setup then (if you don't already have a lisence for it).

Thanks Again thiem I will get hold of the ABB representative tomorrow. getting late here now.
Will let you know what ABB say. I was also thinking of hanging a red lion HMI on EthernetIP but all this will only really work as you say if all the devices can be master and/or slave.
We normally use deviceNet on the robots and usually hard wire to PLC's etc - I can see us going back there.
The delivery time is 10 weeks on the robots so We have time to spec correctly(robots needed after tooling complete).

Spoke to ABB. Yup you are right the Ethernet IP option is a slave, so is the ProfiNET. So the only master and/or slave that the ABB is capable of is the Devicenet option.
Great i am still awaiting more info and will keep updating.
So the options are deviceNET IO modules and the PLC as a DeviceNet slave or the PLC as Ethernet IP master and the robot as slave but then the timing is an issue.
I don't know now - what to spec .......

Your timing *may* be an issue with your loop around I/O over EtherNET IP depending on your program in the IRC5 and application requirements.

Basically, you can have single channel DNET, Dual channel DNET, single channel DNET and EtherNET IP. You will have to really determine what the app will require to choose the best path.

You posted last month about ordering robots for a job where you wanted multiple robots and a single supervisory PLC system. Is this still the same job?

If it is, then I would suggest that you use a DNET channel (master) on the IRC5 to control I/O blocks for the robot itself (on all of your robots). Then you need to choose between a second channel DNET (slave) or an EtherNET IP (669) card to communicate to the PLC system. I guess you could hardwire to the PLC too, if you only need like 6 or 10 status bits going to the PLC system.

Y

ou posted last month about ordering robots for a job where you wanted multiple robots and a single supervisory PLC system. Is this still the same job?

Click to expand...

Yup it is the same job.

The cycle time is a product every 20sec so I agree with you the loop around is not going to work properly. The robot picks item up loads injection moulding machine and then demoulds the part, placing on a conveyor. The grippers vac valves etc must be operated immediately no wait time or the cycle time will be exceeded.

I think your option of DeviceNet master for the robot is the way to go.
What I was thinking as the ethernet Ip and DeviceNet option are more or less the same price, was to stick to one protocol.
Just to throw a spanner in the works It was suggested the PLC be a devicenet slave with all the IO in other words the robot is fitted with the deviceNet master option and no IO it is configured to the PLC which is a deviceNet slave option. This means the robot controls its IO with minimal timing issues and some virtual IO which the PLC can access and via a different comms method relay some data to the HMI or SCADA.

The real problem is 5 robots to start off with and finally 13 in total so the IO and comms options are very costly from ABB hence the reason to use another manufacturers IO. One deviceNet or ethernetIP is ok but not 2 options like you suggest deviceNet master and DeviceNet slave modules too costly apparently.
I really appreciate your help - thank you very much !

Found out now that ABB do indeed to a EthernetIP master and/or slave option 841-1. The ABB personal seem to be implying that this would be better.

This is merged into 1 thread here is the link
http://www.plctalk.net/qanda/showthread.php?t=53986