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.