yorik wrote: ↑Wed Feb 16, 2022 11:03 am
You know, I think mounting a well-structured, doable plan with well thought and well described features, is maybe 60% of the work. Once that is done, coding is easy and I would even dare to say it won't require finding a developer, one person will start, another will go further, etc...
We could try to start a plan here. I have a very limited idea of what an ideal furniture workbench should be, but let's start with something.
- modelling workflow:
- work with boxes
- be able to assemble those boxes
- be able to drive the boxes dimensions from a spreadsheet
- be able to subdivide boxes
- generate panels from those boxes
- generate specific attachment points from these panels
- those attachment points can become holes, or be use to hook other objects (screws, hinges, buttons, whatever)
- production workflow:
- be able o generate CNC cut sheets
- be able to generate BOM
- be able o generate conventional drawings (plan, front view...)
- be able to generate exploded drawings
Once this plan is good, the next step would be to identify which new features/objects are needed, and which existing ones can be used or need to be adapted
Good outline, @yorik
I have done something similar, but the key points are not easily feasible, as something in the infrastrucutre is lacking.
I've some doubt that the whole thing could be driven from a spreadhseet, as in such things, some level of abstraction is needed, in a similar work (and in other ones) I've resolved to use as a "storage container" a simple .ini file, that could solve some problems.
- Drive module creation as some lenghts could hardcoded and reused a lot.
- Data storage for reusability of projects, a single text file could hold an entire set of cabinet, if correctly taylored.
- Serve as easy way to input things, instead of fiddling with a GUI interface you simply could edit with a text editor the file.
- With some techniques "accurately taylored" it could even drive the creation of the GUI to visualize and eventualy modify "generation data".
What I've not been able to do is some "technical drawings" and some "GCode generation", but mainly because the "customer" was satisfied with the "test product", and decide to make the subsequents phases, by hand.
Speaking of GCode production, I have another personal project that is able to generate Gcode, but sadly I have my CNC "on repair" so I con't do some further testing.
What is lacking is "the glue" but "the glue" is not very difficult to make, it is not a simple Macro, as it is more than 10.000 lines of code, GUI and drawing generation to be passed as DXF to an external CAM program to feed the CNC with proper GCode.
Actually there are no "blocking points" a part for some TechDrawing Scriptability" and some improvements that has to be made to "PathScript Scriptability" to obtain a more smooth GCode generation.
Math is not so difficult to do as at the very end you are speaking of boxes and the most complicated part is to plan all the "plays between parts", and have some "sane conventions" when building "components".
A cabinet, is composed by five parts, two "shoulders" 1 top, 1 bottom, and a Rear, you have to decide how to joint the top and bottom with the two shoulders and how to model the rear.
A demo of a cabinet with some drawers
- cabinet.png (8.43 KiB) Viewed 1823 times
One "component" outline ready to be exported as DXF.
- drafts.png (5.89 KiB) Viewed 1823 times
Some Path generated using Scripting for another project
An automatically generated GUI, without use of Qt designer or other complex things.
- GUI-new.png (50.88 KiB) Viewed 1823 times
Sadlly most of the code is copyrighted and not reusable.
Regards
Carlo D.
- paths.png (35.89 KiB) Viewed 1823 times