Release the communications library separately

[rszimm]

Have you considered releasing the communications library separate from the full GUI and control library? A quick search and I found a lot of python libraries that said they provided an interface to grbl, but they all seem to be poorly written, or very special purpose (e.g. open the serial port and blast out the data). I was going to just roll my own, but I saw your project and you wrote your communications part (generally in Sender.py with "controllers" for translation) exactly how I would have, with a single thread that handles all communcations and has methods that populate command queues for sending that the thread services.

Only thing is, I'm building a little stepper controlled 1-axis router lift, with a little encoder wheel and a 4 line text display for a UI. So anything beyond the communications library isn't helpful.

Just a thought!

[Harvie]

To be honest, i don't think bCNC communication code is perfect. It's bit rough, especialy since i did refactored it to support plugins for different controllers: https://github.com/vlachoudis/bCNC/tree/master/bCNC/controllers
and problem is that adding new controllers might require the API to completely change, to accomodate for different paradigms of different controlers.

That said. If you feel like you can work on better isolating individual components of bCNC to make them better defined and reusable, that sounds like something that i can be interrested in.

[rszimm]

Thanks! I think your solution is a lot closer than you might think. It's the right structure (which is 95% of the battle). I ended up rolling my own, quick and dirty solution as I didn't need a full library (just the ability to move a single axis back and forth and trigger a home command). So I'll leave it to someone else to create a nice library, hopefully based on your structure. I do think there's a real need for a general purpose python library.