Posts by panic mode

yea, lots of weird things...

like clients opening controller and unplugging 27V PSU...

asking for help and not stating detailed software version even though there is more than 50 "KSS8.3". making own vague description of what is observed instead of posting screenshot, etc.

if you are to troubleshooting smartPad issues, one very obvious thing to try is to start system and disconnect smartPad (use the white button). if no smartPad is connected, there can be no connection problems. if system works well with smartPad disconnected, then try different smartPad.

another obvious step is to collect KRCDiag immediately after issue happens and sending it to KUKA.

The solution is to use common sense:

If you are going to make changes, better plan ahead and get informed about correct steps.

Create backup(s) so you can at least revert to previous state.

If you do find yourself in a hole, stop digging. Do not make things worse.

And when asking for help, start new topic, state all relevant details because they matter... See pinned topic READ FIRST.

and when itcomes to WoV, do not create new project from scratch. creating good project from scratch requires a lot of insider info that you do not have... so always get working project from the robot, rename it, modify it and then try to deploy it.

technically you are correct, adapting values in correct places in MADA will do the trick.

robot MADA is only two DAT files in KRC:\R1\MADA and those can be replaced without cold boot, just deselect robot program and submit, make change, then start submit again.

problem is that many values are not documented, specially if you look in $ROBCOR.DAT

and as you have found out KSS performs check so if changes are incomplete, KSS is likely to complain as something will not add up.

the normal way is to make robot better match the model is not to edit model but create suitable PID file. alternatively one can try to adapt or deactivate some things such as dynamic model which is something to contact KUKA about.

this is supposed to be a cycloidal gearbox which has more parts than simple planetary gearbox.

have not come across info on this. gearbox is considered a component to last for a lifetime of the robot. as such it is meant to be replaced as a unit (not user serviceable). that is unfortunate since they are very expensive but this is not unexpected - a lot rides on it.

maybe someone does have some more info. short of that online videos can help with some insights:

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.

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?

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.).

Dzonzi continues to leave a mess... He asks questions and then deletes them. Worse, he continues to delete posts after others have contributed. That is very inconsiderate and disrespectful...

Quote from Nikolay Noskov

Yes it need to be a popup. I want to block any activity from User-s during my function is executed.

attempting to block "any activity" is going to be difficult. you may have to define what the "any activity" really is. popup does not prevent user from using (or letting go) of enabling switch, turning mode switch or pressing anything that is not on screen. creating and removing custom popup is not really a big deal, it is just that it would need a bit more than just KRL if it need to look certain way (without button). the bigger question what is it that you are trying to prevent.

in your examples, if RETURN is reached, code after ENDIF is no longer processed since routine is ended.

BTW you can check that by using single step debugging option.

RETURN instruction immediately ends current routine (as if END was reached).

that routine could be either a subprogram or (usually) a function.

functions require use of RETURN because this is how they return result value. if there is branching, every path must encounter one or more RETURN instructions. each RETURN in function must have parameter that matches return type of the function.

in subprograms use of RETURN is optional and therefore not used very frequently. and since subprograms do not return value, no parameter is used here.

does it need to be a popup? status message would be perfect for this

not exactly, but you could get similar thing using dialog. note that dialog must have at least one button or it will not show up, and if button is clicked, dialog will go away. so you need to display it again as long as "busy" is in progress and remove it when not busy.

welder is set to correct node matching config files.

IO size is plausible and probably correct if used before.

the thing you did is exactly part you did not show - the wiring...

and that is where 99% of problems are.

make sure bus is powered (YOU need to bring 24V to devicenet bus), and terminated. i do not see terminator on the fronius side and cabinet side is not shown.

DC power in KRC is 27.1V and will be just fine even though DeviceNet specs calls for 24V. normally this is protected by 2A fuse. also make sure that DN bus shield is grounded in one place - at the KRC.

can you not just jog robot and monitor the bits change?

most HMIs have built in security feature. to see what the capabilities are refer to product documentation. but even if that was not the case you can do anything you like, just roll up the sleeves...

built in security can be tricky or challenging if one works with many brands and still want to maintain uniform appearance/functionality. but one can also make own... all HMIs have options to tell what screen is displayed or to navigate to screen requested by PLC. so create screen with few buttons and couple of lines of code is all that is needed and you got something that is very portable (easy to implement on any platform). the best part is that this works even on most basic HMIs that did not come with own security.

in other words, nothing stops you from making button that navigates to screen with more buttons (numeric keypad...). if entered password is correct allow changes. when change is made or after short timeout disable parameter changes again.

there is more to this. for robot to be controlled from external device, EXT mode is used.

to use EXT mode signals in Auto External interface need to be configured. they use inputs. EthernetKRL cannot write to inputs. only IO drivers can do that.

that does not mean it is impossible... one just need to be aware of it and work around it.

Quote from DS186

You simply need to connect your gripper IOs to the X41 interface ....

Hmmm no... gripper inputs are low voltage (max 5V) and polarity is NPN. X41 outputs are 24V (actually 27V) and PNP. Connecting them directly would damage expensive gripper.

As mentioned in previous post OnRobot needs external interface/adapter to work with industrial IO. They call it compute box or whatever.

well... you skipped all the important details. how is gripper connected to robot right now? it looks like you have it working but want to hide the wiring. but that means knowing exactly what the wires are (electrical specs).

everything about the robot is in the robot manual. check section 6.4 of document "BA_KR_AGILUS-2_en.pdf".

internal connections running through robot arm are called "energy supply".

different options exist for energy supply exist such as "CTR AIR" and "AIR CTR GIG",

where:

AIR means air connections

CTR means controls IO

GIG means Gigabit Ethernet connection (8 conductor in form of four twisted pairs).

CTR is connected to internal IO so it is not suitable for hijacking for other purposes.

GIG connection is really an extension cable running from X76 at robot foot to X96 at robot wrist.

This is a candidate to replace external cables. But... one really need to read the manual. these connections are meant for signals and wire size is small (0.25mm^2) so they are ok for signals but probably not for powering gripper. so one would need to get power from X41 and signals from X96.

since OnRobot gripper combines power and signals into same cable, one could place a small box on top of the arm to bring all cables in.

btw OnRobot grippers like RG2/RG6 use IO levels and polarity is not the common in industrial environment, To interface such device with industrial product, OnRobot offers an interface adapter.

The exact solution would depend on ones preference.

If the interface is placed at the wrist, then all wiring could be contained at the end of the arm.

If the interface is placed externally, then the only way to avoid external cables is to use energy supply.