search

vlachoudis / bCNC

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

no functional merge ? #1630

Open LittlePierre opened 2 years ago

LittlePierre commented 2 years ago

Am I wrong or there has not been any functional commit/merge since long ? What is the time Line for this project ? Is it quietly dying ?

Harvie commented 2 years ago

We are relatively busy, both me and @vlachoudis I am aware about your PR #1561 but haven't checked recently how the development is going... I can merge it as soon as i will review modifications made to common files (which fortunately are only minor part of PR).

LittlePierre commented 2 years ago

Thank you Tomas.

I know that we are all busy, and I know what you and @vlachoudis have done for the project, with some others. It appears that we miss developers. Maybe a good way to motivate them would be to open discussions as per @GitHubCaps in #1514. Maybe a good way would be also to give a clear timeline for expected functionalities.

Anyway thanks for all your works, All the best Pierre

Harvie commented 2 years ago

I think right now the biggest task is to fix this: https://github.com/vlachoudis/bCNC/issues/591

We need to overcome limitations caused by Tkinter. I don't think i can handle complete rewrite to different GUI toolkit right now. But we might try to slowly implement some OpenGL based editor. Glumpy (or Vispy) seem reasonable once we manage to integrate them to TKinter. I think this is absolutely crucial to further viability of bCNC, since the 3D view/editor is extremely slow and ugly right now. We can create great plugins and new features, but we fail to present their results in modern and clear way due to lack of usable g-code preview window.

LittlePierre commented 2 years ago

Yes I will have a look one of those days when I have some time free. Honestly I have not reopened the code since my last commit. But I was not talking of "my" own PR's specifically. But of the code in general and the contributions from ALL.

Edit : yes agree with your last comment when I was typing this one.

LittlePierre commented 2 years ago

Agree with #591, but I prefer not to interfere with your works. By the way, what do you think of the idea of rewriting low level libraries such as bmath.py and bmath.py, into C/C++ dynamic libraries, that would be called through a wrapper to improve speed of frequently called core functions. To prevent from regressions on those, we could write unit tests ? No ?

Harvie commented 2 years ago

Agree with #591, but I prefer not to interfere with your works.

There is no real work, just ideas and experiments with tiny python scripts. Didn't really figured anything.

By the way, what do you think of the idea of rewriting low level libraries such as bmath.py and bmath.py, into C/C++ dynamic libraries, that would be called through a wrapper to improve speed of frequently called core functions.

Slowest part of bCNC is the 3D canvas/editor. It is several orders of magnitude slower, i see no big trouble with speed of the rest.

Some calculations can be made faster using numpy/scipy. (that's what 2D STL slicer does)

It might as well make sense to replace bpath with some ready-made library. There are actualy some libraries which achieve similar goals to some extent. When i was writing code for SVG import, i've noticed that some SVG libraries have similar features to our bpath.py, i beleive it was svgpath, but not sure. Certainly there are libraries which would be able to handle 95% of our use cases. It would be stupid to write this from ground up. We can use wrappers around existing library or even send needed features to upstream codebase of such library. These libraries are usualy well tested for regressions and formaly verified by academic mathematicians (unlike bpath).

But i think it does not really make sense to have perfect bCNC core when we fail to wrap it's features in sensible GUI.

Also when we swap core for some optimized geometric library backend written in C and swap frontend for some OpenGL accelerated canvas, we will no longer have "bCNC", because both back and front ends will be replaced :-)

LittlePierre commented 2 years ago

;)

Harvie commented 2 years ago

BTW There is some 3D CAM functionality in FreeCAD. I think it might replace bCNC in the long run. FreeCAD is written in python (with C boilerplate), has state of the art 3D geomertic libraries in its core. Nice performant 3D viewer/editor. Possibility to add python plugins.

Their CAM workflow is currently rather weird, too complicated and i was never able to get anything useful done with it, but there are people who know how to use it. But once they will streamline their CAM ("Toolpath workbench") to be more user friendly, i think it will be the coolest kid in the block.

FreeCAD can get many things done, but is also quite big, resource hungry and takes whole night to compile on my old Thinkpad. bCNC will then remain here for people who like minimalistic solutions.