EthernetKRL Sometimes message is not received correctly

    KSS 8.3

    In the main program:


    1. EthernetKRL communication is opened in XML form:

    Code
    RET=EKI_Init(serviceName[])
RET=EKI_Open(serviceName[])

    2. an interrupt is also declared

    Code
    INTERRUPT DECL 89 WHEN $FLAG[1]==TRUE DO GET_FROM_PC()
INTERRUPT ON 89

    which is called when entire message arrives (FLAG 1 becomes true in that case, which, as you already know, is set in the config file :


    <RECEIVE>

    <XML>

    ...

    <ELEMENT Tag="Robot01" Set_Flag="1" />

    </XML>

    </RECEIVE>


    3. In this interrupt function, values are actually written from memory into some variables


    This all works as it should for a while, but then it happens that the message that was sent arrives incorrectly, in the sense that I see that the variable True was sent from the PC, but the program read it as False


    I thought that EKI_ClearBuffer before the message arrived would help, but that didn't help,


    Another thing I tried is to set the new flag (FLAG[5] in Program Logic ) to False at the beginning of the function GET_FROM_PC().

    When the end of the function is reached -> that is, everything has been read from memory, to set the FLAG[5] to True to ensure that the new message is written in variable -> While waiting for that FLAG[5] to become True in the main program (WAIT FOR $FLAG[5]==TRUE), but that only stopped the program:


    Program Logic:

    Main Program:

    and in GET_FROM_PC:


    Do you have any advice on how to solve this problem?

    Thanks in advance

  • HawkME March 8, 2023 at 11:12 AM

    Approved the thread.

    Nothing obvious springs to mind. My first thoughts:

    1. Add a "heartbeat" integer to the EKX messages being sent to the robot, and increment the integer with each transmission. This should help determine if the robot is reading "stale" data from the buffer somehow, or if there is actual data corruption occurring.

    2. Use Wireshark on the network interface and check the raw packets being sent. Ideally, use a Shark Tap or something similar to read what the robot is receiving, but at minimum you can run Wireshark on the computer sending the EKX messages.

    3. Have the robot "echo" the data (or at least a key item, like the heartbeat integer) back to the PC, and force a re-transmit if it's not correct.

    Quote from EmilijaS

    This all works as it should for a while, but then it happens that the message that was sent arrives incorrectly, in the sense that I see that the variable True was sent from the PC, but the program read it as False

    which variable exactly? the way i understand this you do read the variable ok, just the value is not what you expected. this raises question - are you SURE nothing else is modifying that variable? did you try to store copy of the variable into another (test only) variable at the moment it is received? how and where the variable is declared? are you sure there is no issue of scope or double declaration?

    Quote from EmilijaS

    I thought that EKI_ClearBuffer before the message arrived would help, but that didn't help,

    are you sure that rate of messages is not the issue? how are received messages processed (FIFO or LIFO?). maybe you are simply reading message that is out of order. you may want to setup own variable to track things like this, create message counter and increment it every time message is sent. then when received you can see exactly what took place.

    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

    Depending on exact version of kss an update of kss and maybe ethernetkrl might be in order. I know i've read somewhere about bugs regarding ethernetkrl communication. Last time i updated a 8.3 the latest version was 8.3.43.

    also workvisual complained about an update being available for ethernetkrl but i looked the other way whistled and slowly backed away.

    Im sure the minor version software updates kuka provides are not just for fun but actually fix something more or less critical each time they are released. Have not seen any release notes but maybe combing thru xpert and see if you find anything slightly relatable to your symptoms. Would not hurt atleast.

    that is displayed when local versions of KOPs (integrated into WoV) do not match exactly versions that are used in project or installed on the robot.

    sadly detailed version is not always shown. KRCDiag always shows full version which is correct but the 4th number is often omitted - including archive (in AM.INI) or on the smartPad (help, info, options...).

    and WorkVisual really complains hard about this even if the difference is minute. for example one can have option like "GripperTech 3.4.5.200" on the robot and in project. but version of KOP integrated into WoV is "GripperTech 3.4.5.201". Since the fourth number is omitted WoV may display something that appears nonsensical like "Upgrade from 3.4.5 to version 3.4.5 is available". So to avoid silly things like that, it appears that more recent WoV versions does show full version - at least in the project analysis window... but if i recall correctly it still only shows the first three numbers in both project structure and in catalogs. :unamused_face:

    Accepting upgrade means it will be attempted to replace option on robot with this newer version that was found locally on the PC running WoV. That may sound like a good idea but reality is sometimes different and without proper preparation and backups, things can go sideways. And that is why there are options to "Ignore this message while the current project is open".

    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