Posts by panic mode

you should check READ FIRST. this is explained in system integrator manual, system variable manuals etc.
S = Status
T = Turn
E1..E6 = External axis positions
A1..A6 = Robot axis positions (robot arm)

that code is ok - if that is what you really have.

coin cell battery is standard CR2032

SLA batteries are 12V each, connected in series they provide 24V.

it's neen years since i did anything with RS232 so.. how is your port configured? are you sure to use #SYNC? what about handshaking? are you evaluating status after each CREAD/CWRITE?

1.a after CMOS battery is replaced, one must load default BIOS values and save them

you may want to reduce $ADVANCE to 1 and introduce intermediate point.

[size=2]those are only few of many settings. time diagrams for handshake are in the system integrator manual. [/size]
[size=2]sequence is to powerup drives, clear messages, start main program (CELL), present PGNO, then issue PGNO_VALID.[/size]
[size=2]timing is important as some of signals are edge triggered. those must be low for a while, then high for a while where "while" is 20ms or more. if either state is too short, controller may not catch it and you will see what you describe (this is one scenario, there are others when people edit wrong things).[/size]

[size=2]where is this Sensor_Offset coming from? are you aware that I/O operations trigger advance run stop[/size]

if you did not modify CELL beyond inserting program calls, that part is probably fine.

note, robot can respond differently based on configuration of IO, for example:
what is the PGNO_TYPE?
what is the APPL_RUN setting?
what is the PGNO_VALID setting?
...

some signals are edge triggered and this has to be taken into account.
some signals require specific timing and this too has to be taken into account (i recall recommendation for 20ms).

simple workaround for edge triggered signals is to produce multiple edges (use pulsing signal).

why don't you follow outlined steps?

if you need more help, post more info about your setup.

SWITCH FUNCT
;*******************
CASE #PGNO_ACKN
;*******************
IF (PGNO_REQ>0) THEN
$OUT[PGNO_REQ]=FALSE
ENDIF
IF (PGNO_REQ<0) THEN
$OUT[PGNO_REQ*(-1)]=TRUE
ENDIF
IF (APPL_RUN>0) THEN
$OUT[APPL_RUN]=TRUE
ENDIF

APPL_RUN is set by P00, through use of line:

P00 (#EXT_PGNO,#PGNO_ACKN,DMY[],0 )

in your CELL.SRC

[size=2]from what you mentioned so far i think it is safe to say that you are way of beaten path, navigating dangerous waters. just make sure to not modify IR_STOPM.SRC or P00.SRC. even in SPS.SUB an d$CONFIG.DAT there are specific folds for user to make their own changes. it is not a bad idea to avoid the rest...[/size]

[size=2]If you are trying to setup AutoExternal IO there are few things to be done:[/size]
[size=2]1. have some I/O (hardware or fieldbus) between KRC and PLC. Check this by turning on signals on one side (PLC for example) and verify that they are activated on other side (KRC). Then do it on other direction.[/size]

[size=2]2. configure AutoExternal signals[/size]

[size=2]3. if you want to use AutoExternal interface, modify CELL.SRC. But... Only add program names in places of examples. If you need to add more cases, that is ok but make sure to duplicate example case(s) exactly (including P00 line). Note, P00 handles all handshaking. it has several parameters but the only one you need to keep an eye on is the second parameter. it tells what action P00 is supposed to do (get program number, acknowledge program number etc.). I have seen people copy wrong line thinking that they are all the same... they are not.. if unsure if you changed something in CELL.SRC, just delete it and create new one then insert your program names.[/size]

check manual again....

IR_STOPM is called when there is a stop mesage ($STOP_MESS turns TRUE).
to reset $STOP_MESS you need to remove all conditions that caused stop message and then you need to acknowledge messages.
if you are using EXT mode, acknowledgment is done on rising edge of $CONF_MESS ($STOP_MESS does not depend on state of APPL_RUN...)

[size=2]Quote from manual:[/size]

[size=2]UserTech is an add-on technology package with the following functions:[/size]
[size=2] Definition of user-specific inline forms[/size]
[size=2] Definition of user-specific messages[/size]
[size=2] Definition of user-specific technology keys and buttons[/size]
[size=2] Definition of user-specific scripts for inline forms and technology keys[/size]
[size=2] Definition of user-specific folds for inline forms[/size]
[size=2] Integration of user-defined inline forms and technology keys into the KUKA smartHMI user interface[/size]

not that i know of...

and if you do anything in registry, you MUST reboot for change to take effect.

before you go to great lengths to customize every aspect of it, try to make it work...
this means there is no need to mess with registry editor as long as your KFD and any depenency are into default folder.
For UserTech3.2 that is[size=2] C:\KRC\TP\USERTECH\TEMPLATE[/size]

have not used that product but this should be straight forward, for example:

are they connected?

can you ping both of them?

is the network name correct (matching on both ends)? PROFINET name must be same on device (FQ2) and in master configuration (FQ2). if you rename one side to something else, it will not work.

did you configure IP in all places:
- on device (FQ2)
- in WoV device properties (FQ2>Network)
- in WoV network (PROFINET>Device Properties> IP address, also device name should be unchanged)

that is what timers are for....

DECL INT Duration=7 ; choose free timer, 1..64
















$TIMER[Duration]=0
$TIMER_STOP[Duration]=FALSE
; do something
$TIMER_STOP[Duration]=TRUE
MsgNotify("That SOMETHING lasted %1 ms","Duration",$TIMER[Duration])