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

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

Open
jrgnicho opened this issue Feb 13, 2013 · 1 comment
Open

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

jrgnicho opened this issue Feb 13, 2013 · 1 comment
Assignees
Labels

Comments

@jrgnicho
Copy link
Collaborator

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

@ghost ghost assigned swiedmann Feb 13, 2013
@swiedmann
Copy link
Collaborator

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.

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

No branches or pull requests

2 participants