Posts by panic mode

    that requires seeing the code and understanding what it does. i see no code posted. btw, getting to know someone else's code is likely to be time consuming, specially since they put effort to make it universal package. in other words good luck finding someone willing to sink some time to go through it for free.

    not sure about your software version but in case of TC_ServoGun version 4.1 for exmple, background tip dressing was handled by eg_bg_td()

    since it has to be called by SPS loop (called continuously), it uses state machine and only two subroutines. i just checked it out and it is documented, everything is in English and quite readable.

    if you don't like the built in version, make your own.

    background tip dressing is used to:

    1. move stationary servo gun to a closed position,

    2. run tip dresser

    3. open servo gun

    servo gun is an external axis and you can run the code to do this in main submit interpreter.

    to accomplish this axis need to be asynchronous. when welding (not tip dressing), it should be synchronous again.

    that is correct


    the way the code is written:

    1. interrupt is active and robot is moving towards P3

    2. interrupt is triggered

    3. interrupt subprogram is called.

    4. interrupt is turned off

    5. robot is told to come to a stop

    6. Z1 is initialized... using $POS_ACT !?

    note that in point 6 (Z1 is initialized), robot position is different from position when interrupt was triggered (point 2).

    why use $POS_ACT instead of $POS_INT inside to get value into Z1?

    this is exactly why $POS_INT exists. in fact that is the only place one can use $POS_INT or $AXIS_INT - inside the interrupt subroutine. which in your case is TOOLM()

    i would suggest to simply check if ESC board is powered or not - using multimeter (and doing so properly). it is quick and cheap way to confirm some things before diving in.

    well 'quick' may be relative, depending on familiarity with using multimeter. for many techs and maintenance guys out there that is the only tool to troubleshoot electrical problems and many don't seem to have a good hang of it.

    background story:

    i recall case where couple of techs spent hours troubleshooting something that looked very similar (bunch of safety related messages including QE etc.), they were swapping boards etc. but with no result... so i was called to investigate. i asked them if they checked voltages, they said promptly they did and that is not the problem since the ESC (CI3T) is supplied correctly... so i went with them to what they did.

    the very first thing i noticed is that they were probing for voltages with the multimeter positive probe (red) while holding negative one (black) on the cabinet. all voltage checks they did that way. but that is not how circuit receives power and this approach can only helps identify at most 50% of the problems (those related to issue with positive side of the circuit). they neglected to consider possibility that issue could be also on the negative side of the supply...

    negative supply wires (0VDC) also arrive to that connector (X1). Contacts 1 and 3 are positive, while 3 and 4 are negative. techs obviously interpreted observed reading of zero volts at 2 and 4 as "correct value"... except, that is not a correct way to measure...

    to see if negative terminals are connected, one could keep positive probe on something already confirmed as 24V line, then probe the with black probe.... or simply measure by placing both probes on the relevant terminals of board supply connector.

    so i got the hands on meter and sure enough, both negative supply contacts on X1 were floating. traced the problem back to missing center jumper on a terminal strip.

    your picture shows power is connected but there is no view of the dip switches and it sounds like you only entered desired IP address of the bus coupler in the work visual but.... did not yet do any commissioning or configuration of the bus coupler itself (so it actually uses desired IP address).

    i am not familiar with this specific coupler but this should be similar to AB AENT setup. so, did you:

    a) try to ping it to confirm address?

    b) use BOOTP utility to disable DHCP and set specific IP? (BOOTP is free utility from AB)

    c) try to connect to it using web browser to confirm network settings and make any other checks/adjustments? for example if local IO modules are correctly detected and functional?

    btw. your picture show only few IO modules which is not matched by configured 8 byte in, 8 byte out

    according to message description none of those three messages are a reason to stop (no breaking reaction, no interlock of motion or command). are you sure there are no other messages?

    add line before loop


    this will cause program to stop when approximation is not possible, giving you chance to explore and see what the values of variables are.

    btw you did not post your DAT file that accompanies the SRC file.

    for example what is the value of LCPDAT12. that will override your line 13

    $APO.CDIS = 5

    also since you are setting advance to 1, you need to handle the last motion in that loop. it should be without approximation since you break from loop and next point value is not known.

    Well, first you need to be sure that network address really match. you also need to confirm that you are connecting to correct port. X66 is not always working on every KRC4. it may depend on Ethernet switch that need to be powered. or maybe cable is disconnected internally. To be sure, just bypass X66 and go directly to KLI port on KPC.

    There are several options to verify KLI settings. Some of the most convenient would be:

    1. take teach pendant, use menu Diagnosis>Diagnostic monitor, then lookup KLI IP address

    2. take teach pendant, login as expert, use menu Startup>Notwork configuration and lookup KLI IP address

    3. Collect KRCDiag, evaluate IP address in file \Files\KRC\Roboter\Config\User\Common\KLIConfig.xml

    you can send data from PLC to KRC any time you like. that is just data transfer and it does not matter what the operating mode is or if robot is in EStop for example.

    btw, position values are real but value you transmit is an integer. this means you will loose anything after decimal point. a workaround it to use floating point or fixed point. floating point requires conversion to floating type (REAL). fixed point is using integers but location of decimal point is assumed. for example one can multiply value by 1000 before sending, then divide received value by the same factor (1000 in this example). this does not need to be 1000, you can pick any suitable value (say 666) but it need to be same on both sending and receiving end.