Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RTDE initialization error when EtherNet/IP is enabled #204

Open
fmauch opened this issue Jun 21, 2020 · 12 comments
Open

RTDE initialization error when EtherNet/IP is enabled #204

fmauch opened this issue Jun 21, 2020 · 12 comments
Labels
enhancement New feature or request

Comments

@fmauch
Copy link
Collaborator

fmauch commented Jun 21, 2020

Problem

Following up on #191 and #195 there seems to exist a conflict between using this driver and having an EtherNet/IP fieldbus enabled.

In the driver's output this will like like this:

[ INFO] [1592729101.758609279]: Negotiated RTDE protocol version to 2.
[ INFO] [1592729101.758972147]: Setting up RTDE communication with frequency 500.000000
[FATAL] [1592729102.784572693]: Variable 'speed_slider_mask' is currently controlled by another RTDE client. The input recipe can't be used as configured
[ERROR] [1592729102.784635271]: Could not correctly initialize robot. Exiting
================================================================================REQUIRED process [ur_hardware_interface-2] has died!
process has died [pid 2239832, exit code 1, cmd /home/mauch/robot_folders/checkout/ur_rtde_driver/catkin_ws/devel/lib/ur_robot_driver/ur_robot_driver_node __name:=ur_hardware_interface __log:=/home/mauch/.ros/log/7c7af2d0-b39b-11ea-8175-54ee755e8d52/ur_hardware_interface-2.log].
log file: /home/mauch/.ros/log/7c7af2d0-b39b-11ea-8175-54ee755e8d52/ur_hardware_interface-2*.log
Initiating shutdown!
================================================================================

As enabling EtherNet/IP claims all input fields as listed in the RTDE Guide, the ROS driver cannot use any of those fields.

This driver is designed in a way, that controlling those input fields is mandatory, as certain driver functionalities are relying on these fields. As a consequence this driver cannot be used together with an enabled EtherNet/IP fieldbus.

Workaround

As a workaround you'll have to disable EtherNet/IP fieldbus on the robot. Depending on your robot version, this has to be done slightly different:

CB3 robots

Installation > EtherNet/IP > Disable

cb3_annotated

e-Series robots

Installation > Fieldbus > EtherNet/IP > Disable

eseries_annotated

Proper solution

Currently there don't exist any plans to change that. If you't like to change that, please let us know. Basically, you'd have to make setting up RTDE inputs in the RTDEClient optional (or at least allow an empty recipe. AFAIK the robot doesn't send a confirmation, then) and also change all ROS functionality relying on these recipe fields to check for those and react accordingly. This should currently be affecting setting the speed slider and setting IOs.

While for IOs we could fall back to sending URScript commands to the robot, setting the speed slider value would probably have to be disabled in that case.

@ipa-lth
Copy link

ipa-lth commented Nov 5, 2020

We are experiencing the same issue but with a Profinet connection.

However, we were not able to reproduce it on ursim, yet.
I am suggesting, that the issue only arises if a Profinet controller is actually connected.

Has anyone ran into this problem with (connected) Profinet?

@gavanderhoorn
Copy link
Contributor

Last time I looked at this, the EtherNet/IP daemon was essentially an RTDE client. It's possible the Profinet one uses the same approach.

@fmauch
Copy link
Collaborator Author

fmauch commented Nov 6, 2020

That could be the case. As we've added this check only a while ago behavior might have been different in the past as in #56, but it actually fits the picture. Before adding this check we didn't notice that the RTDE connection was not established correctly. Therefore, it failed when expecting the actual data package as no successful data exchange was established.

@ipa-lth
Copy link

ipa-lth commented Nov 6, 2020

Do you have an idea on how to work around this? We need the Profinet connection, but not all features of the ur_robot_driver.

How much effort is it to disable e.g. the slider info or the tool IOs in the RTDE recipe/driver?

Do you have an idea what else might pops up then?

@fmauch
Copy link
Collaborator Author

fmauch commented Nov 6, 2020

Currently there don't exist any plans to change that. If you't like to change that, please let us know. Basically, you'd have to make setting up RTDE inputs in the RTDEClient optional (or at least allow an empty recipe. AFAIK the robot doesn't send a confirmation, then) and also change all ROS functionality relying on these recipe fields to check for those and react accordingly. This should currently be affecting setting the speed slider and setting IOs.

While for IOs we could fall back to sending URScript commands to the robot, setting the speed slider value would probably have to be disabled in that case.

Commenting out the getRTDEWriter(...) inside this code and setting res.success to true manually could be a proof of concept hack. Obviously, you would fool the user in that case when she/he tries to set the speed slider / set IOs. Then, deleting all lines in input_recipe.txt could work. I think, trying this out shouldn't be too much of a hazzle, then you would have a hacky workaround. However, as stated above, a proper solution that could be merged into master might take a bit more work. I hope, this helps to try things out, please let me know if you have any results from testing this @ipa-lth

@ipa-lth
Copy link

ipa-lth commented Nov 6, 2020

I commented out the above parts of the c++ code and the recipe file.

Unfortunately, the problem stays.

The driver is not crashing but the ur control still does a protective Stop after starting the ur program (including the urcap)
(The behaviour is idential to enabling EthernetIP/Profinet after having already launched the driver.)

Does the output_recipe.txt may also effect the ressource allocation? Is there any chance of resolving this (clean or hacky)?

grafik

@fmauch
Copy link
Collaborator Author

fmauch commented Nov 9, 2020

Does the output_recipe.txt may also effect the ressource allocation? Is there any chance of resolving this (clean or hacky)?

I think not. From my understanding multiple clients can subscribe to the same data being sent via RTDE. Also, connection setup (including recipe verification) seems to succeed, which it wouldn't if there were resource conflicts (given that the fieldbus was activated when the driver is starting).

Edit: The popup states that fieldbus input has disconnected. As I am not really familiar with fieldbusses: Could it be necessary that this is an issue with the fieldbus itself? Does the setup work with a program NOT containing the "External Control" node (and NOT having the driver running)?

@stefanscherzinger
Copy link
Contributor

@ipa-lth

Edit: The popup states that fieldbus input has disconnected. As I am not really familiar with fieldbusses: Could it be necessary that this is an issue with the fieldbus itself? Does the setup work with a program NOT containing the "External Control" node (and NOT having the driver running)?

Any update on Felix assumptions?

@golftra
Copy link

golftra commented Aug 19, 2021

Sending an empty input recipe doesn't work. We want to use the driver in an industrial setting where a plc is connected via Profinet. We don't need the full functionality of the driver. TF & script topic etc. is enough at the moment.

How could we achieve:

Basically, you'd have to make setting up RTDE inputs in the RTDEClient optional (or at least allow an empty recipe. AFAIK the robot doesn't send a confirmation, then)

Many thanks

@fmauch
Copy link
Collaborator Author

fmauch commented Aug 20, 2021

That would require some major changes inside the code base. First of all, you would have to make sure that the RTDEClient would accept an empty recipe probably in this function.

Out of my head I would not be sure what would be happening then. I would expect things to crash at latest when you try to use one of the functionalities mentioned above.

@urrsk
Copy link
Member

urrsk commented Aug 23, 2021

@fmauch This might be something that we should discuss how to fix. It is also blocking the possibility to have multi ROS/External Control hosts contribution into the same robot program.

@fmauch fmauch added enhancement New feature or request and removed wontfix This will not be worked on close if no update labels Aug 24, 2021
@fmauch
Copy link
Collaborator Author

fmauch commented Aug 24, 2021

I've updated the labels accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants