X-Y-Z Orthogonal Robot PLC Development

Hi All,

I have an interesting project that may be coming up in the near future and I wanted to get some opinions on how to approach the PLC development.

So the project is to develop the code for an X-Y-Z Orthogonal Robot. The robot will basically pick up a box and lay it down on a pallet (essentially a palletiser)

My thoughts so far is to develop a state machine that steps through an array of co-ordinates, once all of the positions have been stepped through the pallet is complete and the robot waits for a signal to start the process again. I was thinking to creating it using statement list and CASE function

So my question is has any one attempted something similar and can offer any advice?

Or to anyone who is more familiar with PLCs in general, how would you approach this.

Any help is much appreciated

Cheers

Hi!

I think you are underestimating this project.

Lets assume you have the xyz coordinates of your box and its destination. You are thinking just move from xyz1 to xyz2?

A robot consists of multiple joints and arms, each of these joints has an coordinate. In addition you have inertia (on each joint), gravity and Coriolis effects.

Assuming you have a robot that accounts for that all, and you just input start and stop coordinates. What about objects in the way (previous stacked boxes or misplaced boxes) etc.

You will need more specific information before you can start and it is pretty daunting. I did a robotics course last semester, expecting to get to play with robots. Nope, basically just transformations and rotation of matrices.

It isn't that complicated but....

I wouldn't want to do this in a PLC.
As boneless said, you usually can't move directly from point 1 to point 2 without hitting something so you need to got to at least one more intermediate point to clear obstacles. The easy way to do this is to use a cam table or what a mathematician would call a spline.

Dozen years ago I used to program sort of palletisers. It is rather tricky indeed as boneless wrote.
Later I developed a sequential(?) free-to-program method (compared previous very strictly fixed one we had) that enabled you define via HMI various steps (pick, place, array/matrix pos. calc + inc. etc.) in various order. But what if something goes wrong and you lose your component on the way? Alignment of matrix, ability to teach (at least 3) points correctly and then move accordingly is pain (or fun) in itself if you start from scratch.
More info is almost always better to have.

you usually can't move directly from point 1 to point 2 without hitting something

Click to expand...

It obviously depends how critical cycle times are.
If not, you can have some safe position(s) to fly through

I have done similar things years ago to control Cartesian pick and place robots for removing parts out of moulding machines. This was when motion controllers were prohibitively expensive. I created a simple language for the user to use to control each axis. And all axis were independently controlled (no interpolation). With each axis having a few simple commands. For example...

"X Axis Absolute (value)"
"X Axis Relative (Value)"
"Wait X Axis Finished"
"Y Axis Absolute etc"

You could however start an axis moving before another had finished by using a different command
"Wait Until X axis = (Value). This way you could hold an axis from starting before another one got to a particular position. For example when picking from out of a moulding machine you would first start the vertical motion down and at a certain point start the horizontal axis to take the robot head towards the tool face. Sure it was not interpolating but worked reasonably well (and to the untrained eye looked like it did!).

Each axis had encoder feedback (at a whopping 6KHz max). Two of the axis were mechanically balanced and just used simple "fast/Slow" inverter control. The other one was a DC servo (for the vertical motion). We used physical cams to prevent the user programming the robot into the machine (for example there was a small cam where the robot could enter the press and a much larger one where it was OK to drop the part). The parts we were picking and placing we light compared to the mechanical arms of the robot so we really didn't have any problem with differences in inertia. We got pretty good accuracy - couple of mm with the inverters and probably a quarter that with the DC drive. Max speeds were around 1m/sec. Extremely slow by today's standards.

The user programmed the system in "steps" which when run was fed into a state machine that parsed each step and if required passed the axis target values to a background function that did the motion. Another task just looked at the cams and stopped the machine if it was ever outside of them. The hardest thing I found was making the UI for creating the program. We had lots of other commands like "Delay Time", "Vacuum ON" etc. For palletising we used sprung loaded sensors on the head to detect when the new part was on top of an old one (this was very common and often used on pneumatic arms).

Long time since I've done anything with motion but I'm sure as others have said there are a lot easier ways to do it. We did it this way simply because of cost and the fact that we were selling many of them justified the long development time.

What are you palletising?
How are you going to pick it up?
What sort of speeds and accuracy are you looking for?

Easy/best way IMO, use a robot with vision that is set up to palletize. I know FANUC offers this package as I am sure other robot manufacturers do. The demo's I have seen the robot is able to handle boxes of different sizes and attempts to maximize the usage of the space available, also these programs are "supposed" to be self learning and will "get used" to standard size boxes if most your boxes are the same size.

The robots can take of boxes that are just "thrown" in a pile and palletize

For your consideration: http://www.toolingandproduction.com/features/2008_January/0108_coverstory.aspx

As mentioned in previous posts, doing this in-house in a PLC could be daunting. Robots have built into them algorithms to optimize speed, movement, coordination of axes, etc. that facilitate development. Lots come with a built-in palletizer function. Is there a wrist axis involved?

In my extremely humble opinion I would use the PLC only to stage work for the robot and remove completed work at the end of the cycle.

state machine is good thinking,
make an array with palletpositions, move from beltposition to a topposition and then to palletpos.
moving is all motors together, and next actioniswhen all xyz are at required pos.

Thanks everyone for the responses.

I am aware of how complicated a system like this can become but we are trying to keep it as simple as possible. Because of this the cycle time is low, in the area of 10 boxes per minute. The box mass is also low, approximately 5kgs. Given this I don't think inertia and jerk will be a huge factor.

I am planning to move through a few positions before reaching the drop position. If you can imagine as shooter has mentioned I will start from the pick position and go directly up to the highest Z co-ordinate, then traverse in the X-Y plane to a co-ordinate above the drop position and travel down in the Z-direction.

To answer some of your questions:
- we aiming to palletise small cartons
- pick up will be via a small gripper, most likely using vacuum generators
- speeds = 10 cartons/min, accuracy = 2mm either way
- if i loose a carton on the way the system will fault and an alarm will be raised. The operator will need to remove the carton from the unit and reset the system indicating the correct sequence step from the HMI

Is there any preferred method of creating a STATE machine that is easy to produce and easy to follow during de-bugging?

Cheers

My preference for a STATE machine is using a case statement in Structured text.

You say 10 cartons / min - over what sort of distance are we traveling?

What PLC are you planning to do this on?

I typically just use an integer and increment it as I go through the steps. I prefer small steps some of my states sometimes even look like they shouldn't be their own state but i have found in debuging the more its broken down the easier it is to find (the int gets stuck on a number, makes it nice and easy). When going through the machine on a AB plc I use MOV and EQU.

Ready state EQU 0 [stays in state till ready] MOV 1 >int
initial move EQU 1 [stays in state until robot gets to box] MOV 2 > int

and so on, structured text would work just fine to, I actually learned state machines on FPGA's so text is easier for me than ladder, but I have to make these programs so other people at the plant can work with them

I actually just finished a program that uses a state machine, it was a re-write of a timer infested confusing mess we got when they bought the machine

You might get some ideas from this Siemens example

https://support.industry.siemens.com/cs/ww/en/view/21062269

About ten years ago I created PLC software that would interpret CNC G code and used it to instruct a Fanuc Robot. The customer's operators and maintenance people were well trained in CNC code but didn't want to bother with learning the robot's programming language.

The PLC was a AB Compactlogix, the HMI was a PVplus, the robot was a Fanuc 710 Foundry Duty, and Ethernet/IP was the fieldbus. The setup person could write his program via the HMI (example below) and when the cell was put in auto cycle, the PLC would translate the CNC code and instruct the robot to make the appropriate moves.

N10 G90
N20 G00 X12.345 Y-6.54 Z6.9
N30 G91
N40 G01 Z-9.45 F10.0
N50 G02 R1.23
N60 G03 R2.34
N70 G90
N80 G00 X0 Y0 Z0
N90 M02

Worked very well, sold about 10 of these robot cells with this programming and last I heard was that the customer wanted to try it with a Siemen's solution but I had left the company by then and my employer didn't want to bother with it. Though I recently received a RFQ to add some features to the existing cells at the end of this year.