Robot vs PLC logic

In your opinion, is it easier/better to write most of the robot logic in the robot program or the PLC program? Should the PLC just pass signals from other modules along to the robot or should as much logic be done in the PLC?

I worked with several Motoman systems and one of them had all of the logic in the robot and no PLC. I will have to say that system was horrible to work with. The main reason was because the ladder editor in the robot pendant was quite difficult to work with.

I am working in front of a robot right now. Everything around it is controlled through controllogix. The robot has it's motion program to tell it where to move. It has handshaking with PLC to tell the root to do it's thing and a signal from the robot to the PLC to tell it it's done, or faulted.

Depends on your application. Mine has about 50-60 I/O points in the robot cell that are controlled by the PLC. If you have many I/O points like I do, then doing the logic in a robot would be awful to program.

Midwest Maverick said:

I am working in front of a robot right now. Everything around it is controlled through controllogix. The robot has it's motion program to tell it where to move. It has handshaking with PLC to tell the root to do it's thing and a signal from the robot to the PLC to tell it it's done, or faulted.

Depends on your application. Mine has about 50-60 I/O points in the robot cell that are controlled by the PLC. If you have many I/O points like I do, then doing the logic in a robot would be awful to program.

Click to expand...

I'm going to 2nd Midwest Maverick. logic operations in a robot program can be hard to write and awful to troubleshoot.

Count me in that same group with Midwest Maverick and milazzo. Did a project using Adept and robot I/O only - would not want to do that again.

I haven't gotten involved with the robot programming side of things, I've only ever worked on the PLCs. I can say though that almost every system i've worked on has had the PLC handle most of the logic, and then the PLC would pass signals to the Robot telling it to perform various operations, informing the robot that it was safe to move, etc. The PLC trusted the robot to take care of business, and report back when it was done, so the sequence could continue.

I could see things being more complicated, however, if there were multiple robots in a cell, or if certain IO needed to fire at very precise times in a pattern with the robots movement. Having robot logic could be much more important there.

Some of the Robot logic has improved. I just did a job on a Motoman DX200 using some basic logic on the Motoman with some Ethernet/IP devices. In works well. But it is not as clean or easy as your favorite PLC would be.

I don't really regret going the route of the Robot Logic on this one (yet at least) but I do think that the money I saved by removing a compactlogix that would communicate with the Robot via Ethernet/IP is negligible in the end compared to the cost of the robot and other equipment.

I could see it being cost effective if you already have a robot and don't have the approval to, or want to, spend anything more on an existing job.

Hi

After starting out in the plc world first and getting used to the plc scanning all the code I feel is easier than the the way robot code works
We normally setout what tasks the robot will be doing and break them into there own functions or programs in the robot. We then get the plc to call these as is required.

Just my taughts

Donnchadh

Bbarnett said:

In your opinion, is it easier/better to write most of the robot logic in the robot program or the PLC program? Should the PLC just pass signals from other modules along to the robot or should as much logic be done in the PLC?

Click to expand...

Much of the answer depends on the data exchange frequency, latency, and such.
My only such experience was over DeviceNet to a high speed ABB Robot (flexpicker), and the problem started when we assumed that both devices were operating in Real Time (+x/-0). Wrong. The robot was working in future time, calculating trajectories and such. The result was that we had to find a crafty way to get them in time-step with each other, which we did.
But, discovering it was the harder part, actually. Measuring it and proving it were even worse.
But, this was high-speed stuff, and milliseconds mattered.

For me it comes down to a few things:

1) The amount of physical I/O you are using on the overall system.
2) What additional hardware your system involves, e.g. Barcode scanners, printers/labellers, cameras, stretch wrappers or other devices.
3) What you need to communicate with in terms of fieldbus or site/machine comms.
4) How much time you're likely to spend on the pendant, whether it's commissioning or troubleshooting.

The majority of systems I've seen where everything resides in the Robot Controller have low physical I/O count, simple or no external comms, and are usually small standalone installations. A perfect example is a robot being used to pick & place, or re-orient a product/parts, or doing simple pallet/container handling jobs.

I'm working on a ABB robot project for Ford right now and just finished one for GM. They have PLC templates for the robot and PLC and the way they handle it is that the robot is just a glorified servo, all decision making is done by the PLC and the robot is just a slave for moving from one point to another. Even the EOA tooling is controlled by a arm mounted PLC remote rack; doesn't use the robot I/O.
Once the target positions and paths are taught, robot programming ends and PLC begins.

I had worked on Fanuc / SLC system the one time, where most of the control was done in the PLC. It was a huge pain. Every move was sent to the Robot from the PLC through group inputs, and then the robot would reply. For a simple pick and place system, it very much complicated things. The PLC would tell the robot to move down, and the robot would tell the PLC it was down, then the PLC would tell the robot to grip the part, and then move up. It was very difficult if things got out of sync.

My opinion after that job, was that the one who designed it; spent too much time in the office, and not enough on the floor. As other's have mentioned, each project is different, and may call for different strategies, but I think that the robot should control it's tasks and related I/O as much as possible, with the PLC supervising (calling the tasks) and supporting surrounding equipment. I'm sure many of us have run into systems where either too much is done in the PLC or the robot.

Any more, even in ladder, I try to break things up into tasks, and have a handling ladder then call those tasks.

It's all dependent on the system you are working with, what kind of job you are doing, what kind of EOAT you have, and other factors as well. I find that I've had the easiest use when the PLC initiates a movement sequence, the robot moves, and if any checks are made in between, let the PLC handle it. It can become a hassle, but in the end you keep the reliability and can make things easier to troubleshoot as seeing where it stopped in the PLC sequence.