Posts by jvincent

Hello Classy,

I have not used a UR Cobot in a welding application yet. But this is commonplace with Cobots and Industrial Robots.

From a UR Cobot standpoint, please look at the UR+ Website to see if there is an existing off-the-shelf solution for you (search "Welding")! There are UR+ partners that have developed easy-to-use software and hardware bundles to get your application up and running fast. I recommend UR+ solutions because they severely decrease the amount of engineering time to develop an application for your company's needs.

UR+ Website: UR+

Please feel free to ask me any more questions you can think of.

- JV

Hi Chris,

Have you tried running the "THREAD" command in your code?

THREAD allows the Cobot to continue it's operation while monitoring things like flags or I/O. You can then set Variables while the Cobot is still moving. So you can SET variables whenever the Operator provides the input from the switch, even if the Cobot is currently moving or performing an operation.

Look up THREAD in the Polyscope User manual.

Here's a snippet as well of the Polyscope manual:

As someone that uses UR a lot (I have a UR5e). The UR cobot can do what you are asking. All 5 of your points mentioned above.

--------

Just for reference:

My UR has multiple communications types supported (though I do not know if my company had to purchase them separately):

Ethernet/IP, Profinet, Modbus TCP, RTDE

I use Ethernet/IP with all my devices. They all go to my master PLC and I disperse the information from there.

For Example, I have a barcode scanner that communicates its job result to the PLC... I then parse that information from the Barcode within the PLC and can send a single integer to the Cobot telling it what product it is interacting with based on that parsed serial number. One big "IF" statement can control what movements and I/O are used based on the integer received from the PLC!

--------

UR is a great introductory Cobot and does not have a steep learning curve to get an application running.

It has a great network of support and plenty of "off the shelf" add-ons/software to choose from.

If you haven't already: I would recommend downloading the operations manual and the Polyscope manual from UR's website to get to know the Cobot controller while you wait for its arrival.

Also they offer free "UR Academy" on their website as well to get you a little introduction to the Cobot.

- JV

Hi Rob,

My input here would be using a "THREAD" to control when to turn on your digital output.

Threads are programming blocks in the cobot program that run in parallel with the main robot program. They are typically used for I/O monitoring (at least that is what I use them for a lot).

Within this thread I suggest doing the following:

• Monitor the current position of the Cobot EOAT
  • First, declare a current position pose in your "Before Start": cur_eoat_pos := p[0,0,0,0,0,0]
  • Then, set that positon to the current position in the thread.
    • I believe there is a SCRIPT function for this is: cur_eoat_pos := get_actual_tcp_pose()
    • UR Script manual reference: LINK
• Use an IF statement to control the ON/OFF of the DO based on the Cobot EOAT Position
  • You would need to know the midpoint between the two points
  • Example (P1.X = 0, P2.X = 100):

IF (cur_eoat_pos.X >= (P1.X + P2.X)/2 AND cur_eoat_pos.X <= P2.X) THEN

DO := ON

ELSE

DO := OFF

END_IF

Sometimes threads have trouble synchronizing with the robot program, so throw the UR Script, "sync()" at the start of the thread.

moelsayed

I would like to add a little of my perspective in addition to Rekd.

If you are worried about the speed of the application, I would also consider looking at a traditional industrial robot as industrial robots tend to outmatch collaborative ones (like Universal Robots) in terms of things like max speed and payload.

If the customer truly does not care what robot you select, don't rule out traditional industrial robots!

Collaborative robots shine for their ease-of-use, enhanced safety (to work with humans), and easy setup.

In order to have their enhanced level of safety, collaborative robots had to give up some of their speed/payload in return. Though some collaborative robots can operate nearly as fast as some traditional industrial robots if you lessen the safety parameters in their settings.

For example, I had a recent application using a UR5e and since the application did not work collaboratively with humans, I changed the safety settings of the cobot to allow it to be less restricted during movement. This resulted in faster robot movement and a higher throughput.

-JV

shamusoc No I haven't been experiencing the intermittent drops in connection that you are seeing. Sorry but I don't think I can help with that at this time.

And yes I was following the UR Ethernet IP Guide during my setup. I do not use RTDE even though I looked into that while I had trouble connecting via Ethernet IP.

The .CSV file you are looking for is not supported by this site for upload.... but here is a screenshot of the start of my manual mapping following the UR I/O Assembly document in an earlier message

Hello,

Yeah it is tough first time setup! Hopefully I can help you further with my next messages. shamusoc

Here was my setup for the assembly connections... Make sure the Target Config Size is 0!

WAIT will stop Main Robot Program Execution and Robot Movement, but it will not stop Thread execution.

Say while the robot is waiting, you want to set a variable based on an Input you are monitoring... you can do that.

Here's the test script I ran to test this:

BeforeStart:

Var_1 := 0

Robot Program:

WAIT: 30.0

Thread_1:

sync()

IF DI1 = TRUE

Var_1 := 1

ELSE

Var_1 := 0

While this program ran, I monitored the variable values in the RUN tab and toggled DI1 in the I/O tab

Picture 2 of 2

Hello!

I remember attempting TCP/IP a couple months back and I remember it working. I forget the specifics of what I was doing in the program as it has been some time, but I figured some screenshots of my program might help you nonetheless.

I ended up phasing out the TCP/IP because I am using a PLC with Ethernet/IP protocol now. EIP covers my bases, so I did not develop TCP/IP any further than this.

I have a UR5e so I am not sure if this will help you on your UR10.

- Vin

Moelsayed,

You should be able to do this by using that SubProgram function.

1. Press Subprogram function in MAIN program (this will create a subprogram generically named "SubProgram_1" initially)
2. Press the "Load File" button below the subprogram field on the right-hand side of the screen
3. Load a Program file (.urp) in the same folder directory on the UR Pendant.
4. It should load in the program, line-for-line, from the other file in the subprogram space that used to be blank in your MAIN program
5. "CALL" that subprogram within your main code.

EXTRA:

• If the subprogram is very large in terms of lines of code, place a FOLDER under the first line of code in that sub_program and make the following subprogram lines of code fall within that folder. This way you can collapse all those lines of code in the subprogram for a clean look
• I believe the pendant will ask you if you want to update the sub_program each time you open up your main program if there were any changes to the sub_program.urp file.... I can't remember

If this doesn't work let me know. I will go take a look at a pendant. I know I have done this before, but I do not have the pendant in-front of me. Only a manual.

- JV

Yes there is!

I am not sure what you have tried so far with that function, but here is a link to a UR support article on that topic in which it gives an example of getting the TCP force in the Base frame and also converting it to Tool Frame.

https://www.universal-robots.com/articles/ur/ge…rdinate-system/

Alternatively, if you setup an Ethernet/IP connection between the robot and a PLC, you could see that force information through the PLC and display it on an HMI that way. I attached a snippet of some of the information that my PLC can see from the robot which includes TCP Force.

Ethernet IP offers tons of information from the robot including, joint position, Digital I/O monitoring, Safety bits, etc. If you are interested in setting up Ethernet IP, reference Universal's other article:

https://www.universal-robots.com/articles/ur/ethernet-ip-guide/

Raheel,

I believe you can. I have been looking at pages II-56 and II-57 in the polyscope manual:

https://s3-eu-west-1.amazonaws.com/ur-support-sit…lobal-3.4.4.pdf

It seems you have two options:

1) Update the positions by giving a global offset to the feature plane pose each loop.

2) Create other feature planes and reference different planes for the movements each loop using a counter or other input

I personally have not programmed something like this in one of my own applications, but these approaches seem feasible.

Try this article if you haven't already: https://www.universal-robots.com/articles/ur/ethernet-ip-guide/

I recently setup ethernet IP using a TURCK PLC and Codesys. Be wary of the .eds file given to you in the article above. It was created for Allen Bradley PLC's and did not work on my Codesys driven PLC. I had to setup the mapping manually referencing this PDF: https://s3-eu-west-1.amazonaws.com/ur-support-sit…p-iomessage.pdf

I was looking through manuals and could not really find evidence of TCP setup limitations. But I have a feeling that Universal Robots put that limitation in there for a reason. It wouldn't hurt to send an email or give a call to the UR tech support team of your region to get more insight.

One thing that comes to mind to add on to your list of negatives would be stress on the robot flange. With such a large Z offset of the TCP, you are creating a larger moment force at the flange. Depending on the weight of the object you are picking and the weight/Center of Gravity of the gripper itself, this could damage the robot.

Now add movement to the robot. Momentum / inertia can intensify the stress at the robot flange.

I recommend looking at a different tooling design if possible. Going against Universal Robots limits is risky.

Update to my Post...

I have figured out how to get the Universal Robot and my other devices to talk via Ethernet IP.

The .eds file from the UR support website is not useful for the Codesys 3.5.16 platform. The .eds is meant for Rockwell.

Even though I knew that the .eds was originally made for Rockwell, the confusing part is how the eds easily loads into Codesys and it can detect devices in the device tree with no issues. The I/O mapping seemed to have no issues as well. That is until I ran the PLC and I was stuck with the Yellow warning triangle as seen in the image above. I tried to salvage using the .eds file by manually editing it in a text editor to better fit Codesys (based on troubleshooting steps I found elsewhere).

Overall, do not use the .eds file from UR for Codesys systems.

You will need to make a "Generic Ethernet IP Device" for the robot's adapter in the Ethernet IP scanner device tree.

You will need to do everything manually from here out. Setup the IP address, add a generic connection, and then do all the mapping manually.

Here is the mapping link: https://s3-eu-west-1.amazonaws.com/ur-support-sit…p-iomessage.pdf

After you are all done and the connection works like expected, export the mapping to a .CSV file for later use.

If anyone else has found an Ethernet/IP .eds file that works well with Codesys for UR let me know. Or other troubleshooting steps for the existing .eds file from UR's website.

Here are a couple of ideas:

1) Set up safety planes where those objects are (look in UR robot safety tab in Installation) The installation that you use applies to all programs that you might run on the robot.

Reference: https://www.universal-robots.com/articles/ur/se…ety-boundaries/

2) Try physically locating the object with the TCP of the robot. Using the Cartesian data, you know the space in which the object is in reference to whatever frame you use for your movements. Add a little padding to the boundaries of the object. Periodically monitor the robot's joints or TCP position in the program to ensure that those boundaries are not crossed. Account for object dimensions the robot might be holding as well.

3) collision detection. If your robot has collision detection, enable it while it moves through areas the objects might be at. Increase sensitivity to mitigate potential damage.

I believe you could use the FOLDER command to group lines of code together. Then copy and paste that folder elsewhere in the same program.

Or create subprograms and call those in your MAIN program.

Though these two commands only work with sequential lines of code.

As for something similar to a PC like holding CTRL and selecting scattered lines you want to copy or delete, I do not believe there is a way to do that in UR.

You have to do that one by one. At least that has been my experience so far.

I am struggling with setting up Ethernet IP between my UR5e cobot and a Tx715 PLC/HMI from TURCK.

I already looked at the Ethernet IP guide on the support website for UR.

I downloaded the .eds file from that article and installed that in Codesys v 3.5.16.

After scanning for devices on my Ethernet Scanner, Codesys found both my robot and the Discrete I/O gateway on my network.

The universal robot is select-able as an Ethernet device.

I placed the robot and BL20 modules in my scanner’s device tree and the eds came with pre-configured I/O mapping for the Cobot.

Once I download to the device and put the PLC in RUN mode, the BL20's I/O works as intended, but the Cobot doesn't communicate at all.

It states that the bus is not running and has a small yellow triangle next to its name in the device tree. On the Cobot pendant, the EthernetIP running state is still Yellow.

I even tried to map the I/O myself on a generic ethernet module for the Cobot rather than rely on that eds file.

There is definitely IP connection between all of the devices because I can ping all of them and receive a response.

There must be something wrong I am doing in Codesys, I/O mapping, or maybe the UR Cobot (but there are not too many options there on the pendant).

Any one else have these issues with TURCK items/Codesys and UR? Any troubleshooting ideas?