Posts by gtrobot

If you haven't already, it is worth taking a look at the UR log file (download from controller, use the log file reader UR provides on their website) to see if there are any indications of problems. Typical issues will have some indication in the log file. If you done any work in the controller itself, I would also open the hood and make sure all connections are seated properly.

There are a couple of ways you could do this, two come to mind immediately (I'm sure there are many more)

1 - write a magic file to take care of this. you can use the existing UR magic files as templates

2 - write a script that will take care of this for you remotely. plug an ethernet cable between the UR controller and a computer, and write a script that will pull the relevant files off of the UR controller for you daily

You should be able to use the tools in the TCP section of the Installation settings to help walk you through this.

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?

There are a couple of plug-and-play grippers listed on the URCaps website that you can check out: http://www.universal-robots.com/urcaps

If you're worried about the start-up motion damaging your EOAT one option is to put the robot in 'backdrive' mode. This will allow you to move the robot into a safe position before it goes through the startup motion (which incidentally is part of startup to make sure the brake pins don't get jammed up and can be released.) Hope this helps

Hi Lerak,

I haven't tried this in some time, but what you should be able to do is define a feature plane in the Installation settings, and set that plane feature to a variable (checkbox at the bottom of the feature screen.) Set your waypoints with respect to that variable plane feature, and when you update the feature plane variable based on your external feedback, your path should update as well.

Hi zerosignalz,

Unfortunately there is no GOTO command in UR. You can use if statements, or if you are running the latest software (3.2) you can use a switch statement. Hope this helps.

Has anyone tried out the new XMLRPC functionality with the new UR software release? I've been playing around with it a little bit, and it looks like a pretty cool feature. One issue I'm running into is passing any data that isn't pose data.

"An error occurred in the running program.
XMLRPC: Failed with error code -500: Unexpected error executing code for particular method, detected by Xmlrpc-c method registry code. Method did not fail; rather, it did not complete at all. map::at"

I've found that I can pack the data into a pose variable and then unpack it as needed, but it is a bit cumbersome. Anyone else run into this issue, or have a potential fix?

Hi Kade,

You're right, Operator Variables is a nice easy way to do this. For protecting your programs, another way you can do this is through the Dashboard Server. If you change the user role to Operator, selecting the Program tab will simply not be possible as it will be grayed out (this can be helpful if you worry about password sharing on the line - it happens.)

Not sure if you're still facing questions here, but interfacing a UR with an IMM is fairly straightforward. For Europe UR offers a euromap67 add-on (HW unit and SW plugin) that allows for easy integration. The HW component mounts directly onto the UR box and conforms to the euromap67 standard. For North America you either have to know euromap, or just know that the euromap67 standard is identical to the SPI 50-pin standard. If you happen to be using euromap12 or SPI 32-pin connectors (which are also identical), you can get a unit that will convert between the two. Long story short, integration is pretty easy if you use the add-on.

The resolution/repeatability of the joints is 0.1mrad.

The resolution of the joint encoders isn't a number that UR publishes.

In the past UR has made the simulator available for free for just that reason.

All of the software (including the offline simulator) is available on their support wiki (support.universal-robots.com).

However, by far the easiest method is to use the site ur-update.dk which holds all of the software as well as the manuals found on the support wiki (most of the items on the wiki link here.) You don't get any of the helpful information found on the wiki (installation instructions, etc.), but it is open access.

Yeah, you have to have a login created for you by UR. It's a little bit of a hassle, but if you talk to your official UR distributor (the person you bought your robot from) they should be able to help you figure it out.

The easiest way to do this is with a little bit of scripting commands. You can use script to control the speed slider, which will change the speed of the robot, which should get you the kind of behavior you want.

For example:

socket_open("127.0.0.1",30002)
socket_send_line("set speed 0.5")
socket_close()

would change the speed slider to 50% and drop the speed of the robot by half. Just put each line in its own script command, and put this into a Thread that is monitoring the state of your input. There is an example on how to do this on the UR support wiki. Also, don't forget the socket_close() each time you are done changing the speed slider, or your program might act a little weird.

It is also possible that you could use the safety features on the CB3 to get similar behavior (just safety rated). If you set your reduced mode to be 15% of your normal mode operation, wire your light curtain into the configurable inputs, and then set the inputs to 'Trigger Reduced Mode', you should see the same performance (I haven't tried this out, so your mileage may vary.)

Good luck.

Unfortunately it is currently not possible to concatenate strings and variables in a popup. It's an unfortunate limitation of the interface, hopefully UR is able to make the language more expressive in future releases.

The easiest way to tell what generation robot you have is from the serial number. The fifth number in the serial number will tell you if it's a 2nd generation '2' or a 3rd generation '3'.

So, say for a CB3 '2014350001', '2014' is the year of manufacture, '3' tells you it's a CB3, '5' tells you it's a UR5 ('0' for UR10), and the last numbers are the actual series number. For CB2 '2014200014', '2014' is the year of manufacture, '2' tells you it's a CB2, next is the 4-digit manufacture number of the robot, then the HW type ('3' for UR5 controller, '4' for UR5, '5' for UR10 controller, '6' for UR10).

You can find the software version running by pushing the 'About' button in PolyScope. You can find 'About' on the main Home screen, or under 'File' in Program/Run mode.

It is not possible to immediately start from a previous stack position using the Stack/Destack wizard. You can see why this is the case if you look at the way they are implemented in the script file.

One option is to use a Pallet instead. If you configure the Pallet to be a line pattern, then set the StartPos to be the bottom of the stack and the EndPos to be the top of the stack, you can set the Pallet to remember traversal position between program runs and it should work fine. The biggest difference here though is that instead of setting an item thickness, you have to specify the total number of parts in the line (thickness will be determined automatically based on number of items in the stack, and the distance between the two stack endpoints.)

The other option would be to write your own stack function from scratch.

Hmm, that sounds strange. Is this a CB2 (2nd generation) or CB3 (3rd generation) robot? What version of the software are you running (both robot and simulator)?

Here is some sample code for PolyScope for how you might do this:

Program
   Init Variables
     list = [0,0,0,0]
     var_1 = False
   BeforeStart
     cp≔Tool
     MoveJ
       cp
   Robot Program
     MoveJ
       Home
     Loop var_1≟ False 
       var_1≔socket_open("192.168.1.200",30000)
     list≔socket_read_ascii_float(3)
     If list[0]≟3
       socket_send_string("Received")
       new_pose≔p[list[1],list[2],0.0,d2r(0),d2r(0),list[3]]
       MoveL
         new_pose
       Halt
     sync()

Good luck!!