Palletizing program

Do normall commissioning as usual:

> Configure fieldbusses and IO

> Configure safety

> Adapt soft limits as appropriate

> Measure tools and bases

> Setup loads

Decide on program architecture based on process and recovery requirements.

For example palletizer application process may require use slip sheets, palets, conveyors, custom tooling (segmented pick and place). Each station (conveyor, pallet, stack of slipsheets etc.) will need a base. Recovery may need to start/stop/resume/cancel process at any time. Details matter. For example one may consider need for completing current pallet, other may say just take the partially complete pallet out and start with new empty system. An example of this is after planned or accidental power outage. So one need to plan for correctly declared variables - it is not just scope but also life to be considered.

For each station there will be need for at least one pick or place program. There may be need to determine current situation by determining height of products (pallets etc.). depending on available sensing option this may be more or less complicated. Certain things can be measured using statically mounted cameras or distance sensor, other may need robot guided sensors and use of interrupts.

You will also need a way to configure each layer since products are usually elongated (bags, boxes etc) so placement in different orientations is used to interlock them. this makes completed pallet more stable so products are not falling off.

Normally such patterns are stored in suitable record (an array of appropriate structure).

And every pelletizing system i have worked with was always geared for high throughput. This means programmer must have very clear knowledge of advance run pointer...

The best way to learn programming is to take suitable training courses. KUKA offers Programming 1,2,3. For pelletizing application i would strongly suggest taking at least the first two courses.

the first one teaches about basic commissioning and ILF programming.

second course covers expert programming (without ILF), use of variables including structures and one of the exercises is a very simple palletizing program (only one layer, no orientation change etc.).

Is it possible to adapt soft limits before teaching all programs?

Yes. You can even assign them in your program though considered bad style. Its better to use axis specific workspaces instead.

Fubini

So how do you know what axis range you need for your programs before you teach them?

I used to teach all programs first, then active function that monitors axis positions in real-time, drive every program on the robot, and then add e.g 5 degrees tolerance.

That tolerance is for adjusting a little program's positions without a need to change limits.

Quote from Dzonzi

Is it possible to adapt soft limits before teaching all programs?

How should I have guessed from this?

So what do you have already before hand thats before teaching? Do you e.g. already know Cartesian positions?

I do not, but you?

No I do not have to. I am no longer working with robots.

lucky guy

Quote from Dzonzi

So how do you know what axis range you need for your programs before you teach them?

I used to teach all programs first, then active function that monitors axis positions in real-time, drive every program on the robot, and then add e.g 5 degrees tolerance.

That tolerance is for adjusting a little program's positions without a need to change limits.

that way axis travel is constrained to required space used by programs. this is not proper. soft limits are substitute for hard limits. both hard and soft limits are meant to prevent axes from reaching positions that would allow reaching dangerous points. that would include anything that would cause hardware damage.

adding some fixed buffer (5 deg or whatever) to travel range used by programs could exceed the safe limits and allow axis to reach hardware end of travel. that would be very bad for the robot and potentially destructive, specially at high speed.

i would say use features/functions for what they are actually meant to do ... unless there is a really good reason to deviate.

hard and soft limits are meant to present absolute limits axis can move to. for example this would be used to prevent ripping energy supply or crushing tool against robot arm. this should be set during commissioning stage, before programs are written.

workspaces (not soft limits) are meant for monitoring or controlling space in which programs operate.

Quote from Dzonzi

lucky guy (...for not working with robots)

nobody is forced to work with robots. most people are happy/eager to work with robots. if one does not like it, why not consider career change?

Quote from SkyeFire

Thread

Grid/Palletizing library and example

The question of how to write a program to handle 2D or 3D "grid" type operations (often for palletizing, but there are other operations that need the same mathematical offsets) comes up on a semi-regular basis.

Long ago (KSS 5.4 era), I was stuck doing this myself, and then ended up with a few weeks with nothing to do, thanks to supplier delays. So I amused myself by writing a general library that would handle any conceivable 1D, 2D, or 3D grid, with offsets, "every other position" patterns,…

SkyeFire

Apr 11th 2021

yup, lost of custom data types (ENUM/STRUC/arrays) and custom functions.

anyone looking through real palletizer program will realize that this is not for fainthearted. code complexity and data structures grow with number of product types supported, number of layer types etc. in comparison, creating simple motion program to move from A to B are very simple.

Of course there are some differences but they are irrelevant. 99% of material will be applicable:

basically there are obvious user interface differences:

in KRC2 each submenu is called up by white button above the screen. On KRC4 those are called up by pressing on menu button, then list of submenues appears. and while the list is vertical, and some items use slightly different name, they are still all in pretty much the same order.

and there are different resources - newer controller obviously has much more memory etc.. Instruction set on KRC4 is larger and includes entire instruction set that was used on earlier controllers, but in addition to those, also also includes new motion planner with spline type of motions.

So one gets to choose between PTP,LIN, CIRC and the newer SPTP, SLIN, SCIRC.

for palletizer one would make almost all motions with PTP (or SPTP) since one needs speed and usually long motions.

things that matter are all the same:

program structure, naming conventions,

scope and life of variables,

declaration and initialization of all including complex data types (enum, struc and array)

system variables (timers, counters, cyclical flags, IO)

interrupts

measuring and use of tool and bases

advance run pointer

trigger commands

etc.

things that are different (but nearly identical) are:

motion instruction set (on older KRC you would not be able to to use splines) so use old motions.

approximation is exactly the same if using same instruction set - it is a bit different with splines.

99% of system variables are exactly the same.

the most notable difference is with message programming since message structure has changed after KSS5.4. but you don't need the to make the robot move. but message programming is mainly application or exercise of using structures and even though new and old message are not exactly the same, knowledge of structures is what matters - a topic that training covers.

Quote from Dusty

I’ve looked at skyefires Grid/palletizing library and example. Could this handle my application? It will be layers of 5 tight bags more similar to boxes, each layer will be inverted. Also there will be two pick positions and it will need to build pallets in two positions (for continuous work).

Maybe. Depends what you mean by "inverted layer." As written, the grid library only handles simple XYZ shifts, using the Base frame assigned to the pallet. No rotations of boxes or layers is supported. It would probably be possible to add such features, but would take some work.

Multiple pallets is simple -- just call the grid library with different origin Bases.

For a KRC1? That code was written for KRC2s running KSS 5.6, but (IIRC) doesn't use anything that relied on anything specific to KSS 5. Only way to know for sure would be to try loading it into a KRC1 and see what compilation errors occur.

Maybe a compromise. Teach a set of points for each layer type -- say, your "inverted" and "non-inverted" layers. Since you didn't explain what you mean by "inverted", I'm going to assume that you meant the two layer types are rotated 180deg around World Z relative to each other.

So, something like:

DEF Pallet1()
    DECL INT nLayer
    BASE_DATA[10]=BASE_DATA[1] ; 1 is permanent, 10 is a "scratchpad"
    nLayer=0; initialize -- first layer is 0, not 1
    REPEAT ; loop start
        BASE_DATA[10].Z = BASE_DATA[10] + (nLayer * nLayerHeight) ; shift programs up by X layers
        LayerTypeA()
        nLayer = nLayer+1 ; increment layer
        BASE_DATA[10] = BASE_DATA[10] + (nLayer * nLayerHeight) ; shift programs up by X layers
        LayerTypeB()
        nLayer=nLayer+1;  increment again
   UNTIL nLayer>nLayerMax ; set the nLayerMax variable 
END

DEF LayerTypeA()
    ; these are all hand-programmed points using Base 10
    PTP AboveBag1Drop TOOL 1 BASE 10 ; use Base 10 or this won't work
    LIN Bag1Drop TOOL 1 BASE 10 ;
    LIN AboveBag1Drop TOOL 1 BASE 10 ;
    ; ... add points for each drop in the layer
END

DEF LayerTypeB()
   ; again, hand-taught points using Base 10, but for the B-type layer
END

With something like this, you can hand-teach each layer type, but don't have to hand-teach every single drop for the entire pallet.

many decisions will depend on type of product used and how flexible (universal) solution is supposed to be.

palletizing is more challenging if product is soft and changes shape (bags of something - ice, beans, soil, ..). stiff items (boxes) tend to be simpler and more forgiving but may have other considerations. for example approach motion just before placing need to be such to not catch corners of other boxes. sort of slide down slightly diagonally. that way products can be placed tightly without risk of caching corners.

and of course one one need to consider tool shape, max number of products carried at the same time, number of product picked/released before or after transfer etc.

then the thing is who defines layer patterns and who implements them. if client is telling the pattern types and making changes, your solution need to be sufficiently flexible but also easy to use. nobody will be happy teaching 30 locations per layer for 3 or 4 different layers. most of the time it is just 2 or 3 different ones but ... there is an exception to any rule. in most cases there will be at least two different layers (to interlock) and maybe the top layer would be different (smaller) number of items if needed.

for ease of use normally graphical layer editor should be used. that way learning curve is short for user and all math is hidden. or you may have couple of fixed hardcoded) layer patterns to choose from and compute approach and placement of each item from items dimensions.

one could define layers manually if product type will rarely change or if user is sophisticated enough to make the needed changes.

depends on the program itself and the KSS versions, not the KRC. You may have to replace any ILF motion with one created on your KSS if you want to be able to touchup.