Posts by panic mode

The issue is that connection is not established. When everything is correct, connection is established practically instantly. In your case that did not happen even after 20000ms. So check your wiring and settings.

maybe motions are passing through or near singularity. also you are using spline motion instruction in a bad way - all points are on a straight line. spline motion planer does not like that - such path segments should be replaced by a single linear motion. if you want to have several collinear segments, consider using legacy motion planner (use LIN instead of SLIN). spline motions bring number of advantages but also some disadvantages. it is all about knowing what to use, when and why. documentation lists what to watch for and avoid when using splines. this is one of those things, other is having same start and end point etc.

Quote from alphatango

As on backup floppy was all data, I don't understand, what is the cause of problem.

i do not know for sure but i would say that old media is not reliable... any old media... and floppies were not that reliable even while they were common. now we are talking about something that was obsoleted decades ago. which is why one should have multiple forms of backup and store files in a safe place. keeping files on a floppy is not safe. recently i was called to transfer some files to/from KRC2 because i happened to be in the area. i was not prepared. had four floppy discs that looked in mint condition, each was freshly formatted by the KRC. two had errors formatting, other two passed. even so there were errors while trying to transfer just 300k. so it took couple of attempts to transfer them piecemeal. and if there is a next time, i will be sure to bring alternatives... like an ethernet cable, or RS232 null modem cable, or ATA/SATA to USB adapter...(or better all of them)

that is correct...

StartPos is initial position...
geometric operation applied before (left side of) that point is in base frame.
geometric operation applied after (right side of) that point is in tool frame.

so line 26 goes to same point that robot is at in line 21.

line 22 moves robot "up" in base frame
line 23 moves "back" in tool frame
and operations can be compounded so adding offset more than once can be used to increase the overall travel.
for example line 24 does just that. endpoint is lifted once in base frame (above) and also moved back 4x the Retract distance in tool direction (tool offset is -600mm in tool X direction).

btw. the motion is still single motion:

LIN Above:StartPos:Retract:Retract:Retract:Retract

is same as

DECL PTP temp
temp=Above:StartPos:Retract:Retract:Retract:Retract
LIN temp

the nice thing of using this way to compute approach/departure points is particularly nice when you want to constrain what user can touchup. the idea is to only use inline form motions on points that permit touchup and have other points calculated. and placing calculation into line with motion instruction is very nice. because you can immediately use any calculated point and see result. this is not how things work when point is calculated in a manner shown in post #1. there result is stored in a variable and to see result of modified reference point, one would need to return to begin of calculation. that requires more attention and understanding how code works (read the code, identify begin of calculation, go to that line, step through several lines...). with geometric operator used the way i have shown, all of this gores away. you just block select the motion you are interested in and do a BCO - that's it... robot will calculate and move to that point in one go....

for example, if vertical approach (palletizing/depalletizing):

LIN Above:xP1; Approach, always calculated
LIN P1 Vel 0.5 m/s .... (this is an inline form)
; gripper action (open/close)
LIN Above:xP1 ; departure, always calculated

or approach/departure in tool direction

LIN xP1:Before; Approach, always calculated
LIN P1 Vel 0.5 m/s .... (this is an inline form)
; gripper action (open/close)
LIN xP1:Before ; departure, always calculated

so after touchup, just select previous line and run to see all changes.

directory loader allows adding/removing/replacing programs on KRC. basically it allows you to remove programs to make some space and then add new ones.

to get more info:

1. check your KSS version,
2. determine correct DirLoader for your KSS,
3. download manual for it and go through it. there are restrictions that you want to be aware of.

last two steps require access to Xpert portal.

basically there are several limits, such as:

max length of the line in the file

max number of lines

max number of modules

memory limits that are KSS specific etc.

also note that program structure plays a role.
typical program module has two files (SRC and DAT). persistant variables are declared in DAT file. those variables are given memory locations when program is selected - even if one does not run program. that memory allocation is retained and used next time program is selected.

guess what happens when there are many program modules and one keeps selecting/deselecting different ones. more and more memory is alocated and it is not released until cold start. so when memory as premium and programs are large, everything that could be in SRC should be in SRC. largest programs are exports from various Cad-To-Path software as they have many points. but all points are in the SRC file. too large program can be broken down into chunks that are called from main program.

Quote

Translation

Good evening, I need to know the variable that controls the time to activate the motor brakes and de-energise them.

what robot brand, controller type, software version?

some common terms are in the READ FIRST topic. and of anything our members from Germany/Austria/Swiss should be able to help with:

that does not tell you much... just which interpreter is waiting but not what is it waiting for.
if you need PLC to know what robot is waiting for, add own handshake or status.

DECL INT WaitExpression

WaitExpression=1
WAIT FOR $IN[11] OR $IN[33]

WaitExpression=2
WAIT FOR $IN_HOME

WaitExpression=3
WAIT FOR $AUT

etc.
then your PLC only needs to know value of WaitExpression. if you are displaying this on HMI, you can make a list or multistate indicator to show message whatever is robot waiting for.

the other option is to look at the messages themselves. monitor if messages are displayed, read through all of them, find message you are interested in, extract info from it... there should be KUKA option for this, called KUKA.KRMSGNET.

in case of KRL some variable declarations can be seen in various files, others are not (compiled into KSS).
this is so called basis package...

also, more variables can be introduced by installing additional tech packages (software options).
but as with any program, declared variables need initialization.

in SRC file there is an INI fold where robot program related variables get initialized.
when options are installed, they insert their own initialization into INI fold.

the same goes for Submit interpreter...
so things that need initialization are processed by call to BasisTech_PLC_INIT() which of course is only done once.

but... Submit is background process that runs all the time. and things that need continuous processing is placed in BasisTech_PLC_LOOP()

anything named BasisTech is internal to KSS and best left alone. never needed to look into it.

KSS 8.7 system integrator manual... check

"11.16.5 INVERSE: converting a Cartesian position to axis angles"

note the square brackets in Form2... This is common convention that indicates optional parameters. so you can specify CAL value or not...Everything else is required in this format.

Curly brackets are used to indicate individual elements of the syntax.

; Form 2: 
; {token}{num}={address},{byte},{res},{type}[,CAL{factor}]

Current college course material is focusing on manipulatin of structures... such as programming messages and creating offets by modifying points... and for many people that is enough (or too much). And while Kuka training is great, I wish that basic course (programming1) has $PAL_MODE mentioned and that advanced course (programming2) has geometric operator covered (at least mentioned/demonstrated). Reason is that those topics are common, important and deserve mention so that people graduating the course do not get stumped when facing 5-axis palletiser (trying to do mastering for example) or when deciding how to apply offsets in programs. both of them can be easily covered/demonstrated in short time, without sacrificing moch or impacting existing topics.

geometric operator adds offsets to chosen frame or point.
this can be added before and after point (or both) and it can be extended by cascading more operations.

One thing mentioned in the advanced course is that one can use relative motion to retract in tool direction such as

LIN_REL {X -100} #TOOL

this assumes that tool direction is X+

note that parameter #TOOL is important. if omitted, robot will default to move in base coordinates:

LIN_REL {X -100} #BASE
LIN_REL {X -100}

both above lines are the same.

but...

also consider this:

DECL FRAME Above, Retract
DECL POS StartPos

Above   = {X 0, Y 0, Z 150, A 0, B 0, C 0}
Retract = {X -150, Y 0, Z 0, A 0, B 0, C 0}

$base=base_data[6] ; whatever base
$tool=tool_data[6] ; whatever tool

PTP xHOME      ; this can be inline form too
PTP Above:xP1
LIN xP1        ; this can be inline form too
WAIT SEC 1
LIN Above:xP1
PTP xHOME      ; this can be inline form too

HALT

PTP xHOME      ; this can be inline form too
PTP {A5 45}    
StartPos = $POS_ACT
LIN Above:StartPos
LIN Above:StartPos:Retract
LIN Above:StartPos:Retract:Retract:Retract:Retract
LIN Above:StartPos
LIN StartPos
PTP xHOME      ; this can be inline form too

KL4004 is just the IO module (slice) without fieldbus interface. mapping and fieldbus side configuration depends on bus coupler, type, number and order of IO modules (slices). that is part of the puzzle you did not provide. not sure what you mean by "analog quantity"... how many KL4004 are present? each KL4004 has 4 analog outputs so if bus coupler has macId 11, and single KL4004 is used, the four analog outputs could be mapped something like:

anout1=11,0,16,3 ; use output bytes 0,1 for analog output1
anout2=11,2,16,3; use output bytes 2,3 for analog output2
anout3=11,4,16,3; use output bytes 4,5 for analog output3
anout4=11,6,16,3; use output bytes 6,7 for analog output4

outb0=11,8,x3 ; use output bytes 8,9,10 for $OUT[1..24]
inb0=11,0,x3 ; use input bytes 0,1,2 for $IN[1..24]

not aware of any slave that has only single I/O point. it is possible to create one but cost of making slave with single point would be hardly different from one that has 8 or 16 I/o points.

for me process is determining type of device based on available fieldbus, speed, IO type, signal polarity, IP rating etc.

for example in this case available fieldbus is DeviceNet. KRC is master so your I/O modules would need to be slaves. speed is not important unless there are other devices to be considered and one or more of them are a bottleneck. IO type need to match your needs i if you need digital inputs, it is not helping if you are adding analog output for example. digital I/O are typically 24V but could be PNP or NPN. PNP style is far more common in America and Europe. NPN is common in Asia. but... you may be interfacing to a CNC made in Asia so pick the matching polarity. IF the I/O module is to be mounted inside enclosure, then I/O modules rated for IP20 etc. will be fine. but if this is something not inside the panel and may be exposed to contaminants, you may want to pick something that is properly rated/sealed such as IP65 or IP 67.

even if you think you only need one input or output, it is a good idea to add something that has more IO and both inputs and outputs. for example:

option 1 - modular (and expandable) I/O

Wago 750-306 as bus coupler (actual slave) with some related I/O modules.

option 2 - fixed IO module, possibly high IP rating.

etc.

I would add at least 4xDI and 4xDO because one always needs both inputs and outputs and some spares.

next you need to wire it all correctly... DeviceNet is unique in a sense that its bus is 4 wires + shield. Other fieldbusses use 2-wire + shield. the two extra wires need 24VDC that you supply. like any bus, it will need to be terminated. this means adding suitable terminator at the ends of the bus (far ends of the bus cable).

you also need to power the module itself. normally 2A fuse is used.

then you need to do hardware configuration - setting speed and node address. this is usually done with some mechanical switches (rotary or dip switches).

then you need to do software configuration. there are two parts to this DEVNET.INI and IOSYS.INI.

first one is a scan list and simply contains bus settings (Speed and list of nodes).

the second one is IO mapping. in the IOSYS.INI you would make sure that relevant driver is enabled and then in the mapping section link I/O signals of your slave to robot I/Os. this will allow programs to read/write physical I/O points.

next you need to test the I/O.

i am not going deeper into details as all that is mentioned was discussed many times on the forum already.

also note that to activate an output by program running in robot interpreter drives need to be on. submit interpreter does not care if drives are on. to manually toggle outputs, robot need to be in manual Mode (T1), drives need to be on and no program running in robot interpreter.

you need one what? one article or one IO point or one fieldbus?

setup for one can be more involved than for others.

the default option is DeviceNet since it is already present on each KRC1/KRC2. and no special software is needed to configure it. DeviceNet connection port is on MFC.

while that is a possibility - how do you know it was shot? how was it tested?

if the 5V is present on StandBy pin (purple wire) and rest is powerless, this is not yet sign of a problem. to power up one need to get PS_ON pulled low (connect green wire to common). Then voltages should appear on other pins. And if this down not work then yes, it is shot...

parsing text file is not for everyone. which is why i suggested using LogViewer. go to robot D:\, under KSS installer there are some tools including LogViewer. install it on your computer add message files. then drag and drop archive or KrcDiag onto LogViewer window.

you can also get it from newer KSS as they are more polished. for example the newer ones allow you to have single LogViewer work with messages from different KSS versions.

then you have something much more user friendly than text editor

what seem to be the problem? everything needed to troubleshoot is already stated...

open file in favourite text editor like Notepad++
verify time stamp order and note that in this case the newest messages appear at the top.
then search for your problem message, in this case 3154

once you find one or more of them, see what messages are just before them.

for example i see this:

#104: M_3154
16:50:02.165 26.08.2024
M_3154

Parameters: P_0
Module: CrossMeld
MsgNr: 3154

#105: M_26170
16:50:02.149 26.08.2024
M_26170

Parameters: KPP, 1, 0x00000200
Module: CrossMeld
MsgNr: 26170

message #105 appeared 16ms before message #104.
that happen to be message number 26170

then you lookup that message and see if that could be actual reason that you are seeing message 3154.

and that it is mains failure.

do you think that mains failure occurring 16ms before some axis is locked could be an issue? do you think that mains failure could affect any axis?

then you try to see how often that happens... and the log says message 26170 is mentioned hundreds of times. did you reboot controller so many times? or do those message appear also when you try to run robot?

that is obviously not a way to run production so you need find the problem, whatever is causing too large voltage drop... like too small transformer... or too small wire cross section or too long mains cable... or loose connection... but this could alco be due too large load... or too large acceleration. so for test lower the OV_PRO from 100 to 10 or 30% and trry again. do you still see the same issue?

one you find and fix this then you try it again and follow the process over and over until you weed out every issue...

KRC simulator is called OfficeLite.

that is what previous versions of KukaSim used. and OfficeLite behaves like real KRC so integration of C3B or KVP is the same as on real KRC.

Newer versions of KukaSim includes OL functionality. Not sure how you would use C3B or KVP there