-
Notifications
You must be signed in to change notification settings - Fork 45
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
FSoE devices handling #153
Comments
Hi aatb-ch, There is a special ethercat driver to use called EthercatSafetyDriver. The branch is safety-humble-proto00 and is a tested version. How does it work?The new driver has the ability to copy part of the communication frames from one position in the frame to another position in the frame, enabling the communication between from one hand safety master to safety slaves and from the other hand safety slaves to safety master. # Configuration file (estop_ethercat_safety.yaml) for the EtherCAT safety network of the estop test system
nets:
- name: safety_net
safety_master: el1918
transfers:
- size: 6
in: { ec_module: ek1914, index: 0x6000, subindex: 0x01 }
out: { ec_module: el1918, index: 0x7080, subindex: 0x01 }
- size: 6
in: { ec_module: el1918, index: 0x6080, subindex: 0x01 }
out: { ec_module: ek1914, index: 0x7000, subindex: 0x01 } The ROS2 control file looks like that: <?xml version="1.0"?>
<robot xmlns:xacro="http://www.ros.org/wiki/xacro">
<ros2_control name="ec_safety_estop_test_config" type="system">
<hardware>
<plugin>ethercat_driver/EthercatSafetyDriver</plugin>
<param name="master_id">0</param>
<param name="control_frequency">100</param>
<param name="fsoe_config">$(find estop_description)/config/estop_ethercat_safety.yaml</param>
</hardware>
<gpio name="el1918">
<command_interface name="safety_states"/>
<!-- bit 0 is safety_error_ack and bit 1 is safety_run -->
<state_interface name="safety_states"/>
<state_interface name="safety_states_display"/>
<ec_module name="el1918" type="safety_master">
<plugin>ethercat_generic_plugins/GenericEcSlave</plugin>
<param name="alias">0</param>
<param name="position">1</param>
<param name="slave_config">$(find estop_description)/config/beckhoff_el1918.yaml</param>
</ec_module>
</gpio>
<gpio name="ek1914">
<state_interface name="input_1" />
<state_interface name="input_2" />
<state_interface name="input_3" />
<state_interface name="input_4" />
<state_interface name="output_1" />
<command_interface name="output_1" />
<command_interface name="output_2" />
<command_interface name="output_3" />
<command_interface name="output_4" />
<ec_module name="ek1914">
<plugin>ethercat_generic_plugins/GenericEcSlave</plugin>
<param name="alias">0</param>
<param name="position">0</param>
<param name="slave_config">$(find estop_description)/config/beckhoff_ek1914.yaml</param>
</ec_module>
</gpio>
</ros2_control>
</robot> |
oh wow, amazing! I will test this out as soon as I receive the modules :) I got an EL1904, EL2904 and EL6910 incoming, once tested out I'll go ahead with a Safe Motion beckhoff drive. |
Not really an issue but rather to start a discussion on how best to handle FSoE devices on the bus. I would ideally like to have a servo drive supporting functional safety functions like Safely Limited Speed or Safe Operating Stop, triggered via safe inputs on an EL1904 and handled by an EL6910 safety controller. The safety project would be configured beforehand in Twincat and downloaded to the EL6910, but the question is about how to handle FSoE frames so that they get properly relayed between devices.
From my understanding and reading until now, as FSoE data maps to standard PDOs, it should be possible to have a plugin handling copying of the data between master and slave, but I need to be a member of the ETG to get access to exact implementation documents (I asked for membership, let's see).
From this old thread it sounds like only relaying FSoE frames between devices should not be terribly hard since with the black channel approach, it should be just copying TxPDOs of the master to the RxPDOs of the slaves and vice-versa, since the bus only forwards the safety data and does not manipulate it.
I wondered if anyone had dug into this already, or already implemented it?
The text was updated successfully, but these errors were encountered: