Motion-synchronous outputs

    As someone with extensive experience in "regular" industrial robots, but none with URs, I've just been tasked with a RFP for using a UR-10 in a complex spray-paint type application. Using UR-Sim and reading the Software and Script manuals, the UR seems able to handle the motion requirements so far, but one critical feature appears to be missing: setting signals on the fly, from inside the main program, based on the robot position. So far, I can't seem to set an output during a blended motion.


    If I want this application to work, I need to run a complex MoveP path (thousands of waypoints), cycling my sprayer on/off dozens (potentially hundreds) of times during this path without the robot ever physically stopping. But so far, any attempt to do this in UR-Sim generates a "sanity check" error. So far, I haven't found anything covering this issue in the documents or forum threads I've been searching through.


    The reason I need this is due to the application requirements -- I have to be able to have the TCP up to the optimum speed before I turn on the sprayer, and I have to be able to turn the sprayer on at exactly the right point (with the ability to "shift" the timing by a few hundred milliseconds before or after). Allowing the sprayer to be open while the robot is stopped, or even below optimum speed, will leave unacceptable "globs" on the work surface.


    In the "big iron" robots, my usual approach would be something like this:


    P1----P2----------------------------P3---P4


    Where P1 and P4 would be MoveJ or MoveL equivalents, and P2&P3 would be MoveL or MoveP. The motion from P1 to P2 would be to get the TCP up to optimum speed, and the signal to open the spray valve would be fired as the TCP passed P2, without stopping or slowing down. And I would have the means to "tweak" the signal timing (without changing the physical position of P2) to account for "lag time" in the signal propagation, valve opening, etc.
    P3 and P4 would share a similar relationship -- P3 would be the position where the valve would be closed (plus or minus some tweaking time delay), and P4 would be on the same vector of the TCP passing through P3, to ensure that the correct path was maintained until after the valve was shut.


    Is there any way to perform an equivalent operation in the UR CB-3 or E-Series? One option I've toyed with is using a parallel thread and a script something like pose_dist(get_actual_tcp_pose(), WaypointX), but I'm not sure that would work. And even if it does, for the hundreds of waypoints where I need to perform on/off actions, that method would get completely unwieldy very quickly.

    Edited once, last by SkyeFire ().

    SkyeFire, were you able to get this application solved? My initial thought would be similar to yours, operating the sprayer in a separate thread and using something like the pose_dist function to determine when to trigger the sprayer (or timing the triggers). Either way, the only way I am aware of to perform actions during robot motion would be in a separate thread.


    You should also be able to run this in the URSim, what kind of error are you getting?

    Still looking for an answer. Experiments I've done so far indicate that a Waypoint followed immediately by a logic command will fire that command close to that Waypoint... but how close seems to depend on the Blend radius of the Waypoint. And I still can't tell if the "fire" occurs at the entry, exit, or midpoint of the TCP's arc through the Blend radius.


    It does appear to be consistent regardless of the TCP speed, however.

    Hey SkyFire,
    I worked a little with UR, so I can share some experience.


    First thing is to keep the program short. If you create long scripts, it can take a minute(s) between pressing start and actually starting the program. This is because .urp file is compiled to java (I think, at least some sort of binary) and then it is run. URP is just an XML in disguise. This binary program is then run by controller. Every time you start the program, its execution context (variables etc) is destroyed. The only values that remain between runs are installation variables and registers. When you use step mode, NOTHING else exists. Nor functions, nor local, nor global variables. This is a really big gotcha for someone who used to work with industrial robots. Also "feature" != "base". Features are evil.


    If you want to have hundreds of points, then find out how to use XMLRPC. You can write a simple program, in Python for example, which given a number will return a position. Your URP program will call this function and request the coordinates in some sort of loop.


    URP program should be just a main loop with these variables:
    act_pos
    next_pos
    action = 0 - nothing, 1 - open, 2 - close
    firing_dist (integer in mm)
    program_stop



    It is just an idea. I didn't work with UR for couple of months now, so maybe not everything is exactly right. Also I never tried executing move commands in a loop. I don't know when this function "exits", so maybe extra logic is needed there.


    Good luck and let me know how it worked out! :icon_smile:

Advertising from our partners