When using CAN as a diagnostic channel,other application messages are sent periodically on the bus, calling the client.change_session interface will block at the self.conn.empty_rxqueue() interface.

pylessard / python-udsoncan

Python implementation of UDS (ISO-14229) standard.

MIT License

564 stars 195 forks source link

When using CAN as a diagnostic channel,other application messages are sent periodically on the bus, calling the client.change_session interface will block at the self.conn.empty_rxqueue() interface. #206

Closed jjundot closed 5 months ago

jjundot commented 5 months ago

When using CAN as a diagnostic channel, when other application messages are sent periodically on the bus, calling the client.change_session interface will block the self.conn.empty_rxqueue() interface.

The specific location is shown in the figure

Since I also need to read some application packets for other purposes at the same time, is there any other better way without filtering out the application packets?

pylessard commented 5 months ago

What are the package versions? What Connection do you use? Can you enable debug logging and share the logs? If you use the isotp module, enable debug logging for it as well.

pylessard commented 5 months ago

I have good hypothesis for that issue.

It's possibly a mix of 2 issues, on that will be solved by this PR and also that you are providing a rxfn that blocks forever without respecting the timeout argument being passed to you. You need to fix the later, otherwise you will always end up with a dangling thread and the app won't exit.

jjundot commented 5 months ago

Thank you so much.

I use the PythonIsoTpConnection (can-isotp 2.0.3) The PR #116 above should be very effective, in my environment, it is blocked here: empty_rxqueue ---> self.isotp_layer.stop_receiving() ---> time.sleep(0.05)