search

vlachoudis / bCNC

GRBL CNC command sender, autoleveler and g-code editor
GNU General Public License v2.0
1.54k stars 528 forks source link

Feat/asyncio #1828

Open SamsonBox opened 1 year ago

SamsonBox commented 1 year ago

This pull request soves issues #1824. It uses asyncio to handle the serial communication. This can be done as python 3.8 is mandatory for bCNC. Now the reset command is synchonized with the respons. Also the clear message ist synchonized.

Harvie commented 1 year ago

To be honest, i am not really familiar with this async/await concept. Guess i will have to read something about it first :-) Maybe other members of bCNC community will help me with the review in the meantime...

SamsonBox commented 1 year ago

Actually this is pretty cool. Is a kind of cooperative scheduling in an eventloop within one thread. So the loop is started in the originally serialIo-Thread. within this loop tasks can be started and the can give back control to the schedular by the await key word. But take you time to review the changes.

Harvie commented 1 year ago

OK, i did some research. And while i agree that this is kinda cool. It also feels like it might significantly impact readability and debugability of the code, since execution of individual routines will now be interdependent to some extent.

While i am not completely opposed to the idea, i would like to see what are the gains when compared to "synchronous" code in our use-case and whether they acutally outweigh the increase in maintenance complexity.

Also we might consider if it would make sense to split bCNC into several separate threads. For instance i can image separating GUI, Serial RX, TX and CAM subsystems, so they do not block each other. I would not be as lightweight as asyncio, but might fix even more issues.

SamsonBox commented 1 year ago

So the problem I found is metioned in issue #1824. The basic problem is, that the controller reset is send from the serialIO thread but can not be synchronized to the execution end (which is the reading the initial test the controller sends). So my basic idea was to have two indevidual tasks (a reading and writing task) running in one thread. So one can wait in the writing task for the response from the reading task. You are right, this can be also solved by running these two tasks in seperat threads, but I think that is a overkill for the serial communication as it is relatively slow. Using two thread will not reduce the higher maintenance complexity. The GUI is allread in the mainthread and the CAM subsystem can be moved to it's one thread in both cases.