EthernetKRL (run on EXT1 interpreter) disconnecting when running programs (including motion commands) in main robot interpreter

    Robot - KR 240 R2900-2

    KRC4 - 8.6.10

    EthernetKRL - 3.1.3

    I have currently written a code where I run a program with PTP commands in my robot interpreter. Simultaneously, I have an EKI script running on the EXT1 submit interpreter which runs in a loop to look for particular flags and send messages over EKI if a particular flag is set.

    After each point is reached, I set a flag to TRUE. Which is read by the EKI script, which then sends a message over EKI to the external server and then sets this flag to FALSE again. This cycle continues till the motion program ends.

    The EKI program also has a component which continuously sends messages without the need for flipping any flags (robot_states). The EKI program runs great and there are no disconnections when I am not running any program on the robot interpreter.

    However, when I run the motion program on the robot interpreter, the EKI disconnects from the server (with error PING REPORTS NO CONTACT - EKI00768) after a random time interval, it works fine until that point. I can assure that this is not an issue with the ethernet connection or the external server. This does not happen when I only run the EKI program.

    I am attaching the XML and bits of the KRL code (cannot put the whole code because of IP issues). If anyone could guide me on what the potential issues might be, I would be eternally grateful!

    XML Config File:


    EKI KRL file:


    EXT1 Submit interpreter script:


    Robot Interpreter program (an example):

    Code
    PTP {X 1561, Y -234, Z 0, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0, S 'B110'} C_PTP
$VEL.CP=0.02
LIN {X 1561, Y -234, Z 0, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0} C_DIS
$FLAG[2] = TRUE
LIN {X 1561, Y -194, Z 0, A 0, B 90, C 0, E1 0, E2 0, E3 0, E4 0} C_DIS
$FLAG[2] = TRUE
  • Go to Best Answer

  • SkyeFire September 23, 2024 at 10:48 PM

    Approved the thread.

    i don't see anything odd sticking out... this should work... one thing that is definitely missing is checking if connection exists and reconnect when needed. because it will happen... and you want to handle that.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Thats what, I have been racking my brain over what could possibly be wrong, but I dont see anything that might cause it.

    Is there a cleaner way to handle reconnection without disabling the error display? Because that is the only way I found that reconnection works, otherwise it just throws and error at EKI_Open when the server is offline and exits the code.

    • Best Answer

    btw i do not see way around writing own error handling code. this is the only way to get good behaviour from this product. option, functionality, documentation and examples should be more polished. after all it is a commercial product. if i buy TV i just want to change channels, i don't want to learn how TV works or how to modify its working. same is here, i do not want to be forced to know about OSI Models or have to develop my own recovery strategy just to work around some shortcoming - because reconnecting is a very common thing and absolutely essential. Then you will try to compare your code against supplied examples without understanding why reconnecting does not work all the time.

    if so consider this...

    Documentation and EKI examples use ALIVE flag mechanism to detect connection failures. The examples look so simple, just one interrupt checking Alive flag, then when connection is lost calls ISR subroutine called ON_ERR() which is then supposed to automatically reconnect... This is great except that it does not work - not reliably.

    thing is that Alive mechanism uses Ping. Ping only detects certain failures like when network cable is unplugged... but has no awareness of anything above hardware layer in remote node. like when remote side application is not responding (closed or crashed or disconnected or operating systems crashed/froze etc). this is because Ping only reaches lower OSI layer at the remote side (hardware NIC of the remote PC). it does NOT go beyond that to check if some APPLICATION is running on that remote hardware, or if that application is actually working with that NIC to exchange messages (higher OSI layers). so this only deals with little bit more than half of all layers.

    in other words, if application running on the remote end is closed or frozen or simply disconnects current connection for some reason, you will not be able to exchange data. But Alive mechanism will not know that. And therefore it will not tell you that there is a problem (and all was probably working just a minute ago). As a result your EKI program will not try to reconnect. And continuing with execution of the program (based on supplied examples) will just assume that connection is good since Alive flag is still on. This will only lead to more error messages logged. And even if someone/something did restart the remote end application (perhaps after test, or pushing an update, or restarting for whatever reason like windows update etc.) the EKI program based on EKI examples will be oblivious and keep on tripping instead of trying to reconnect. But reconnecting network cable fixes it so now you may be thinking of ways to let robot reconnect that cable from time to time? Lets hope not...


    so to see EKI really work properly (and robust), one has to get down and dirty, and write a lot of OWN code like evaluation of EKI_STATUS of practically each and every operation. do i hear groans...? wait... did you know that EKI_STATUS is a structure and it has element called Connected? that sounds promising. but did you catch that not all elements of that structure are updated by each EKI function? what do you think assigned value of Connected should be after calling EKI_OPEN? What about EKI_CLOSE? are you sure you are looking at that table or just answering from top of your head? because table says that EKI_CLOSE does not assign data to element Connected of returned status.

    i hope this helps and that NOW you may be ready to start writing your own EKI program code... which does not look like anything shown in the EKI examples. those are very crude skeletons without any error checking or recovery.

    messages and logs help track issues. and when that is no enough, use WireShark... then you should clearly see which side is dropping connection. you may also want to change ENVIRONMENT in your XML configuration to System or ExtSubmit1 (if that is a correct submit in this case). This way reseting/restarting of main submit or robot program will not close connection. Chances are what you posted and what is right now on the robot does not match - Sounds like on the robot you have it set to Program or maybe robot program is resetting or restarting main Submit interpreter. Search in your WoV project for any use of CWRITE that manipulates interpreters.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

Advertising from our partners