Spinlocks or how to make sync robots

    Hello again, and my question is - did someone use spinlocks on Kuka? My target is to synchonize work of 2 robots, to be sure that they will never collide, even in whole-day-cycles.


    Details: I have 2 identical (they have the same model) robots, and their workzones cross each other. From the PLC I'm sending pgno to them at one moment, and they start to move together. The thing is - that even they have the same models - it's 2 different machines and,for example, even physical difference in reductors makes them a little bit different. Because I have 1-hour long cycle I'm worrying about the fact,that difference ,for example, in 0.5ms between them , will make robots collide,so I decided to use syncronization.


    There are different ways of to do it - semaphore,for example, barriers or spinlocks,thanks to wikipedia (https://en.wikipedia.org/wiki/…ization_(computer_science))


    Did someone have experience in syncronization, what the best way without losing efficency?


    Thanks in advance

    Edited once, last by Acapulka ().

    That link goes nowhere.


    You aren't looking for synchronization, you're looking for collision zone logic. Which is used daily across millions of robots throughout industry. Basically, each robot asserts a signal that it is "clear" of the potential collision zone, and waits for that signal from the other robot before entering the zone. Usually includes "safety net" logic where both robots halt if at any time both "clear" signals are false. Edge timing can be a bit tricky, but this is essentially a solved problem in industry.

    Quote from SkyeFire


    That link goes nowhere.


    You aren't looking for synchronization, you're looking for collision zone logic. Which is used daily across millions of robots throughout industry. Basically, each robot asserts a signal that it is "clear" of the potential collision zone, and waits for that signal from the other robot before entering the zone. Usually includes "safety net" logic where both robots halt if at any time both "clear" signals are false. Edge timing can be a bit tricky, but this is essentially a solved problem in industry.


    Everything you said is (and almost always is) correct, but I'd just like to add for the OPs clarification that I would avoid at all cost the use of a "spinlock" in a robot's logic. You don't ever want to tie up the robot when you don't have to, and you certainly don't want to tie up the SPS. You want a robot that can't enter a zone to be free to do other things in the zones it can access if need be.


    Example: We use KUKA's safe operation A LOT. We also have cycle stop buttons. I can't have the cycle stop tie up the motion code in a loop doing nothing, because if they leave it paused during the weekend, or long break, there is a chance that the brake test will become due, and it won't be able to preform it. If this "spin lock" persists for more than the grace period, the robot will not start back up when required, as the brake test


    Just have robot A check if shared region is clear, if not signal it's intention, wait time X, and then check that zone is clear again. Make robot B do the same, but with time Y, where the difference in X and Y are greater than any latency and cycle time delays in the signal. If the zone isn't clear, move on with the logic.


    EDIT: Just want to clarify that it's much better to signal when clear than to signal when it's in the shared region, that way it fails safe. If one robot is off, it can't give the clear signal, as it MAY be occupying the shared work space.

    Edited once, last by BrianR ().

    Yes, a "fail safe" signal configuration -- aka, "block if false" -- is generally the best way to do this.


    Usually we use some sort of combinatorial logic to avoid any Catch-22s or deadlocks as you describe -- for example, the Robot 1 receives a Clear if Robot 2 is sending the Clear signal, or the Home signal (Home position, by definition, should be clear of EVERYTHING).


    I like using the Workspace signals for my final "safety net" between the robots, simply b/c that provides one last safety against someone jogging the robot into the collision zone and then forcing the Clear signal on (or achieving the same effect by jumping around between lines in the program. Sometimes there just aren't enough Workspaces, though -- I once had one project where the "geniuses" in charge of defining the line process created something that ended up requiring 21 separate interference zones to completely avoid deadlocking.


    As a general rule of thumb, interference zones should be kept as small as possible, and robot dwell times inside them should be minimized. Whenever practical, it's better to program longer, slower routes around potential interference zones and avoid collision risk entirely. If a real risk of getting "stuck" at an interference zone boundary cannot be avoided, then the decision logic at the zone entry should include an option branch to back away and return the robot safely home. But that's largely a procedural thing -- a well-designed line should include options for "emptying" the system such that no robot is left hanging/waiting, or holding onto parts.

    Strange, I added right link, but it works only if you click "did you mean syncronization: computer science?" on wiki. Anyway, What you are talking about (when robot switch flag,for example, when zone is ready) is spinlock.
    There what wiki says about spinlocks:
    "Before accessing any shared resource or piece of code, every processor checks a flag. If the flag is reset, then the processor sets the flag and continues executing the thread. But, if the flag is set (locked), the threads would keep spinning in a loop and keep checking if the flag is set or not. But, spinlocks are effective only if the flag is reset for lower cycles otherwise it can lead to performance issues as it wastes many processor cycles waiting."


    So, If I uderstood you correctly, you telling me to use spinlocks and avoid zone interference as much as I can, right?

    Exactly the opposite. Design the physical motion paths to minimize potential collisions between the robots. Use interference zone logic as minimally as possible, and only where absolutely necessary. And proper care must be taken to avoid deadlock/Catch-22 situations.

Advertising from our partners