December 18, 2018, 11:51:07 PM
Robotforum | Industrial Robots Community

 Motion-synchronous outputs


Author Topic:  Motion-synchronous outputs  (Read 543 times)

0 Members and 1 Guest are viewing this topic.

September 21, 2018, 06:14:55 PM
Read 543 times
Offline

SkyeFire

Global Moderator
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.

Linkback: https://www.robot-forum.com/robotforum/index.php?topic=28532.0
« Last Edit: September 21, 2018, 06:28:43 PM by SkyeFire »

Today at 11:51:07 PM
Reply #1

Advertisement

Guest

September 28, 2018, 02:55:16 PM
Reply #1
Offline

BillPbody


Have you looked at RTDE guide ? i don't know if that might have any good information regarding your on the fly changes.
Real-Time Data Exchange (RTDE) Guide - 22229

Bill

October 11, 2018, 09:30:10 PM
Reply #2
Offline

gtrobot

Moderator
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?

October 13, 2018, 11:55:37 PM
Reply #3
Offline

SkyeFire

Global Moderator
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.

November 17, 2018, 07:24:39 PM
Reply #4
Offline

py_programmer


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

Code: [Select]

restart = ask_operator_if_continue_or_restart()

if restart:
    point_nr = 0
end

proxy = rpc_factory( "xmlrpc" , "http://127.0.0.1:8080/RPC2" )
thread bg_thread():
   while True:
       if pose_dist(get_actual_tcp_pose(), act_pos) < firing_dist:
           if action == 1:
               open_gun
           elif action == 2:
               close_gun
           end
       end
       sync()
   end
end
bg = run bg_thread()

while not program_stop:
    next_pos, action, firing_dist, program_stop = get_next_information(point_nr)
    movej(act_pos)
    act_post = next_pos
stopj()
kill bg

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:
« Last Edit: November 17, 2018, 07:29:37 PM by py_programmer »

December 07, 2018, 08:45:27 AM
Reply #5
Offline

ClaudiuA



Nothing truer has ever been written down about UR.


Share via facebook Share via linkedin Share via pinterest Share via reddit Share via twitter

question
In synchronous mode error

Started by anuprathi1984 on ABB Robot Forum

0 Replies
931 Views
Last post February 12, 2016, 03:03:01 PM
by anuprathi1984
question
Change asynchronous axis to synchronous axis

Started by Kara on KUKA Robot Forum

14 Replies
7610 Views
Last post September 18, 2013, 08:39:22 AM
by Kara
xx
continuous motion - avoid exact positioning between two motion commands

Started by robotneuling on KUKA LBR IIWA

1 Replies
348 Views
Last post May 30, 2018, 03:57:49 PM
by razzo
xx
"Motion in singularity" even when program asks to move in joint motion

Started by Haseeb on Fanuc Robot Forum

2 Replies
477 Views
Last post March 02, 2018, 07:24:31 PM
by Haseeb