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

0 Members and 1 Guest are viewing this topic.

Offline SkyeFire

  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 32
  • -Receive: 937
  • Posts: 6362
Motion-synchronous outputs
« on: September 21, 2018, 06:14:55 PM »
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.
« Last Edit: September 21, 2018, 06:28:43 PM by SkyeFire »

Offline BillPbody

  • Newbie
  • *
  • Thank You
  • -Given: 0
  • -Receive: 0
  • Posts: 5
Re: Motion-synchronous outputs
« Reply #1 on: September 28, 2018, 02:55:16 PM »
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

Offline gtrobot

  • Moderator
  • Jr. Member
  • *****
  • Thank You
  • -Given: 2
  • -Receive: 6
  • Posts: 57
Re: Motion-synchronous outputs
« Reply #2 on: October 11, 2018, 09:30:10 PM »
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?

Offline SkyeFire

  • Global Moderator
  • Hero Member
  • *****
  • Thank You
  • -Given: 32
  • -Receive: 937
  • Posts: 6362
Re: Motion-synchronous outputs
« Reply #3 on: October 13, 2018, 11:55:37 PM »
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.