-
-
Notifications
You must be signed in to change notification settings - Fork 65
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
DISCONNECT master command does never timeout but retries indefinitely #108
Comments
version 0.18.48 |
Probably fixed here: #120 |
This is fixed by #120 |
Still not perfect -- I've tested the TIMEOUT case with my own cxcp project, there's no infinite loop anymore, but only a single SYNCH/DISCONNECT sequence.
Not sure what potentially in this context should mean -- Or to put it another way: If there was a CONNECT before, the XCP slave must respond to DISCONNECT... |
Thank you for the reply.
True. At the same time, though, the action of disconnecting from a slave may be a preventive measure when you are probing system where its state is unknown i.e. I have my test-system / diagnostics tool and I issue a preventive "DISCONNECT" before attempting a new connection. In this situation, the slave is not going to answeron DISCONNECT.
Yes, actually you are right, I was just ok the software to not indefinitely block :-). NOTE: my slave runs the Vector XCP Basic implementation. |
OK, I see. To support such scenarios, I've added a new config-option (Commit d0bc55d , Release 0.18.59)
TOML DISCONNECT_RESPONSE_OPTIONAL = true JSON "DISCONNECT_RESPONSE_OPTIONAL": true |
DISCONNECT master command does never timeout but retries indefinitely.
The standard says that DISCONNECT shall be retried max 2 times before giving up; SYNCH shall also be issued before as a pre-action.
So, I'd expect:
DISCONNECT -> disconnect timeout -> SYNC -> SYNC timeout -> SYNC timeout -> raise Timeout Exception.
Or, alternatively:
DISCONNECT -> disconnect timeout (retry=1) -> SYNC -> SYNC timeout (rety=1) -> SYNC timeout(retry=0) -> DISCONNECT -> disconnect timeout (retry=0) -> SYNC -> SYNC timeout (retry=1) -> SYNC timeout (retry=0) -> finally, raise Timeout Exception for DISCONNECT.
Please be aware that I am still not aware of many little details of the XCP protocol, so please correct me if I'm wrong.
Use-case: disconnect a slave which is potentially connected, just as a matter of fact to reset communication from a known state.
EDIT: as a hint, I believe there is some strange behavior in the Executor().call class and method. In particular, self.repeater is never ever invoked due to self.error_code never being set to None or so.
EDIT2: what I'm seeing on the canbus is the following sequence of master -> slave frames:
FE -> 2seconds -> FC -> 2 seconds -> FC -> 2 seconds -> FC -> 2 seconds -> FC .... forever. The slave doesn't answer because it is already disconnected.
The text was updated successfully, but these errors were encountered: