KAREL Processing and IO desynchronization

    Hello,

    This is my first post here but this forum has already been very helpful to me over the past few months. Thank you !

    There is my problem :

    We have a R-30iB mate plus who commuicate with PLC through Ethercat (Rack 106,Slot 1).

    Datas are processed with a KAREL program that is running with a RUN_TASK instruction and a "While true" with a Delay of 10 ms.

    Overall everything works fine except sometimes, where it seems that there is a gap between KAREL variables and GI. So i wrote a test code to confirm it:

    Code
    TestIO = GIN[10]
IF TestIO <> GIN[10] THEN
    DOUT[145] = TRUE
    GOUT[11] = TestIO
    GOUT[12] = GIN[10]
ENDIF

    GIN[10] is a variable from the PLC that increment from 0 to 255.

    I expected that TestIO <> GIN[10] would never be true and that DOUT[145] to be always FALSE, but it turns out that, totally randomly, DOUT[145] goes TRUE.

    The program can Run 10 minutes without setting DOUT[145] to TRUE, but can also sometimes goes TRUE 3 times in less than 1 minute. In the end, it always ends up going true at some point. I Can't hunderstand why.

    Does this sound normal to you and if so how do you explain it ? maybe there is a link with ethercat communication ?

    Thank You.

    Edited once, last by Kelidor (March 1, 2023 at 12:11 PM).

  • 95devils March 1, 2023 at 12:56 PM

    Approved the thread.
    Quote from Kelidor

    Ok I understood, thanks for your reply.

    I don't know why, but in my mind, the value of an IO would remain the same from the start of a task scan until the end of that same scan.

    PLCs operate in that way. The relationship between program line execution and I/O refresh is fixed. Robots generally cannot work that way, because the dominant factor in most robot program execution is motion. The robot controller must update its servo controllers, I/O driver, and other system resources on a fixed refresh cycle, every x milliseconds. But when the robot is moving from Point A to Point B, the time it takes to make that move might be one refresh cycle, or hundreds of them, depending on how far apart A and B are, and how fast the robot is moving.

    As such, in robots, the "background" refresh cycle is completely decoupled from the execution of program lines. A command to read Inputs or set Outputs might be instantaneous, but motion commands can be infinitely variable in execution time. And robot programs mix these "fixed-time" commands with "variable-time" commands. Line-by-line execution of a robot program follows the same set of rules, regardless of whether the program contains variable-time commands or not.

    The way this usually works is this: every refresh cycle, each subsystem in the robot gets a fixed "slice" of that time. The I/O update gets a fixed amount of time, the motion subsystem update gets a fixed amount of time, and the execution of the robot program gets a fixed amount of time. Ditto for multiple threads, background logic, etc. The total time is always a fixed value. While one subsystem is being "refreshed", all the other subsystems are "paused", in effect.

    So, even while running a very "tight" loop robot program, it is entirely possible --in fact, inevitable-- that eventually, an I/O refresh cycle will be called when the robot program is in beween two lines.

    Quote

    I don't know why, but in my mind, the value of an IO would remain the same from the start of a task scan until the end of that same scan.

    All programs share the CPU time.

    The programs can and are interrupted in between. At which point this happens in the program cannot be predicted.

    Quote

    Overall everything works fine except sometimes, where it seems that there is a gap between KAREL variables and GI.

    ((Why is this a problem?))

    At the time you read the input, it had a certain value. And this value is correct at this time.

    If you have to keep the value "synchronous" with the PLC, you have to program a handshake.

    Thank you for this very detailed explanation.

    I now hunderstand better how Robots work.

    Quote

    ((Why is this a problem?))

    At the time you read the input, it had a certain value. And this value is correct at this time.

    If you have to keep the value "synchronous" with the PLC, you have to program a handshake.

    PLC send a bit stream to the robot with a start command and data for motions instructions simultaneously.

    There is the way it works now.

    PLC : Cmd bit + Motion data stream -> to Robot

    ROBOT: Processing data Ok -> to PLC

    PLC : New Cmd bit + New Motion data stream -> to Robot

    ROBOT: New Processing data Ok -> to PLC

    etc...

    We use this exact same data stream and operation on other robot brand and that works well.

    The problem is, sometimes with Fanuc Robot , the start command signal is processed before some datas that have values of the bit stream n-1, resulting in wrong motion intruction.

    As you explained to me, probably because of some IO refresh cycle interruption.

    So For this Fanuc robot, I now have to find a way to ensure that all data stream is refreshed before sending the start cmd:

    @PnsStarter As you mentionned, the easiest way would be to add an handshake :

    PLC : Motion data stream -> to Robot

    ROBOT: Processing data Ok -> to PLC

    PLC: Cmd bit -> to Robot

    ROBOT: Cmd bit Ok -> to PLC

    PLC : New Cmd data stream -> to Robot

    ROBOT: New Processing data Ok -> to PLC

    PLC: New Cmd bit -> to Robot

    ROBOT: New Cmd bit Ok -> to PLC

    etc...

Advertising from our partners