Could anyone tell me how I should go about creating a palletizing program? I am new to this. My robot (kr150 with KR C1 controller) is jogging and working as should and I’ve created a few simple programs to move it around. I’ve read through a few manuals but I’m not understanding how to start making a palletizing program.
Palletizing program
-
Dusty -
August 9, 2022 at 5:37 PM -
Thread is Unresolved
-
-
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.
-
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
-
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,…SkyeFireApril 11, 2021 at 4:03 AM -
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.
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?
-
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,…SkyeFireApril 11, 2021 at 4:03 AM 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.
-
Ive tried looking for some palletizing training from kuka but all I can find is courses for krc4 and up. Would these even be relevant for me with my krc1?
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).
-
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.
-
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.
-
Okay it seems that I need to learn a little more about programming before I try to dive into this. Could i make a more simple program by manually adding place points for each bag? Might take a while jogging the robot that much but it seems like it would be more simple.
-
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:
Code
Display MoreDEF 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.
-
Okay so I’m going to take the easy way out for now. After I’m done with this I will probably try to get some training like kuka collage. But I have an associate who has a robot doing the exact job I would need mine to do. He told me I can use his program but his machine uses a KRC2, mine is a KRC1 should the program still work?
-
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.
-