search

mtconnect / ros_bridge

ROS Python Adapter and Ruby Robot Simulator
http://www.ros.org/wiki/mtconnect
8 stars 5 forks source link

bridge_server.py node hangs after recieving cnc action call #8

Open jrgnicho opened 11 years ago

jrgnicho commented 11 years ago

Description: bridge_server.py hangs inside its 'execute_cb' callback method after receiving a cnc action client call. As a result the call produces a timeout error on the client side (state machine node).

Observed behaviour: -the last messaged printed by the bridge_server.py node is the following:

In OpenDoor Callback -- determining action request result.

-Simultaneously, The cnc simulator produces the following output:

Cnc::OpenDoor Active - Cnc::CloseDoor READY D, [2013-02-13T16:44:07.682044 #7826] DEBUG -- send_to_client: Sending 2013-02-13T22:44:07.681916Z|open_door|ACTIVE to #<TCPSocket:fd 5> (Cnc::OpenDoor) Event: complete (Cnc::OpenDoor) exiting 'active' state (Cnc::OpenDoor) entering 'complete' state Completed D, [2013-02-13T16:44:07.682667 #7826] DEBUG -- send_to_client: Sending 2013-02-13T22:44:07.682587Z|open_door|COMPLETE to #<TCPSocket:fd 5> CNC Received MaterialLoad FAILED Received MaterialLoad FAILED
Trying method: robot_material_load= FAILED Trying action: robot_material_load_failed (CNC) Event: robot_material_load_failed

swiedmann commented 11 years ago

The bridge server is waiting for the READY signal from the CNC before it breaks out of the while loop. It appears that you updated the state of MaterialLoad to FAILED before the READY handshake was completed by the bridge_server. This is why the bridge_server is hanging up. You should be in the MaterialUnload sequence if you are making an open door request. Perhaps the MaterialLoad sequence never completed its READY handshake? Nevertheless, the bridge_server needs to be augmented to either time out or cancel a request for a FAILED state. I'll look at this when I return.