Open Supermagnum opened 3 years ago
andypugh
commented
3 years ago Apart from the difficulty in obtaining all this information, I feel that such a tool belongs in the CAM package (or, at least on the PC that does the CAM) rather than on the control PC.
How does integrating it into LinuxCNC make it more useful than the existing feeds and speeds calculators?
c-morley
commented
3 years ago While I agree this would be a great asset to one using lathe/mill macros or one of the code generator, I also feel the work to do this is great, and the skill to do it right high. There is a whole program G-Wizard that specializes in this. Sounds like a huge research project. I don't think we have man power to do this justice unless someone is really interested. Andy I think we should close this as it's very unlikely to move forward.
petterreinholdtsen
commented
2 years ago @Supermagnum Can you explain a bit more how such calculator would work within LinuxCNC? Is the idea to have a standalone tool, or should it feed into LinuxCNC mechanics somehow?
Supermagnum
commented
2 years ago @Supermagnum Can you explain a bit more how such calculator would work within LinuxCNC? Is the idea to have a standalone tool, or should it feed into LinuxCNC mechanics somehow?
I think that the possibility to use it as a standalone tool,- with the option to send data to LinuxCNC is sufficient.
Supermagnum
commented
2 years ago While I agree this would be a great asset to one using lathe/mill macros or one of the code generator, I also feel the work to do this is great, and the skill to do it right high. There is a whole program G-Wizard that specializes in this. Sounds like a huge research project. I don't think we have man power to do this justice unless someone is really interested. Andy I think we should close this as it's very unlikely to move forward.
That's not free,- and it looks like it doesn't run on Linux.
petterreinholdtsen
commented
2 years ago [Supermagnum]
I think that the possibility to use it as a standalone tool,- with the option to send data to LinuxCNC is sufficient.
So it could be a separate project and tool, with support for sending information to LinuxCNC. Perhaps we should start on such sister project, and see how far we can get? I do not know enough about this topic to do it on my own, but could perhaps help with other tasks if you take the lead. :)
If you are interested, please ping me on IRC, #linuxcnc or
-- Happy hacking Petter Reinholdtsen
petterreinholdtsen
commented
2 years ago http://www.custompartnet.com/calculator/milling-speed-and-feed give some ideas how to do this.
silopolis
commented
2 years ago Le sam. 30 juil. 2022 à 19:41, petterreinholdtsen @.***> a écrit :
[Supermagnum]
I think that the possibility to use it as a standalone tool,- with the option to send data to LinuxCNC is sufficient.
So it could be a separate project and tool, with support for sending information to LinuxCNC. Perhaps we should start on such sister project, and see how far we can get? I do not know enough about this topic to do it on my own, but could perhaps help with other tasks if you take the lead. :)
If you are interested, please ping me on IRC, #linuxcnc or
linuxcnc-devel (Libera.Chat).
Very glad to read this guys!
This actually the second part of the tool db management app I'm advocating here with @TurBoss and in FreeCAD Path project.
The vision is a dedicated tool and cutting parameters app to which all apps in the CAM to CNC production and supply flows can connect to pull and put the data they need.
Aside of a standalone interfaces, supply management/ERP software (Dolibarr, ERPnext, Odoo), CAM packages (FreeCAD Path, BlenderCAM, kuteCAM) , Simulation (CAMotics), Conversational programming tools (NativeCAM, feature macro libraries), Tool setters, and of course our belove LinuxCNC through the tooldb interface, are all potential client applications.
Base schema should be compatible with (part of) GTC / ISO13399 for tools/holders/attachments data, and features expanded with support for shops/machines/tool changers-magazins on one side, and materials/operations/strategies/cutting parameters on the other.
Being able to import adequately formated tabular or json data will of course be part of the requirements.
As I've stated having crossed talks in separate channels about this, I'm also pondering creating a dedicated one in the Matrix Space I've started last week:
https://matrix.to/#/#linuxcnc-space:matrix.org
Technically, this would be sat on a DBMS, but @sliptonic from FC/Path suggested a git managed structured json file repository. May be a mix of structured and unstructured data management using DBMS' JSON support could be the way.
As most of these projects are already using Python, at least backend would be written with it and provide a nice and slick API to frontends, clients and for integration. Those latter would then be free to consume the API the way they need using their toolbox of choice.
I have already reached GTC and got an ID to access their data as well as collected more from MTConnect which also implements ISO13399. These can be found here
https://drive.google.com/drive/folders/1aklkcjNatdHSgc_canfRl30Y2aw8XCk8
In the next weeks I'll do a review of tool management features and tool data used by many packages including G-Wizard, HSMAdvisor, CIMCO, F360, MasterCAM, TopSolid, MachiningCloud.com.
Then research should be done about how to ingest (output) GTC data...
Oh I'm also in for a project name 😉
Thanks for reading
TY J
PS: in lack of better idea, I'll most probably open an RFC thread in projects respective forum to discuss this...
petterreinholdtsen
commented
2 years ago [Jérémie Tarot]
This actually the second part of the tool db management app I'm advocating here with @TurBoss and in FreeCAD Path project.
It sound like you are way ahead of me in thinking of this problem domain. What do you believe is the hard problem? Collecting data or implementing the database?
Oh I'm also in for a project name 😉
Can I propose 'Skjæring' as the project name, the Norwegian word for cutting, intersection and where roads cut through the terrain? <URL: https://en.wiktionary.org/wiki/skj%C3%A6ring >
PS: in lack of better idea, I'll most probably open an RFC thread in projects respective forum to discuss this...
I find forums a strain to use, so I'll leave that part to you. :)
-- Happy hacking Petter Reinholdtsen
silopolis
commented
2 years ago Le lun. 1 août 2022 à 20:13, petterreinholdtsen @.***> a écrit :
[Jérémie Tarot]
This actually the second part of the tool db management app I'm advocating here with @TurBoss and in FreeCAD Path project.
It sound like you are way ahead of me in thinking of this problem domain. What do you believe is the hard problem? Collecting data or implementing the database?
As a former IT guy, having my tool data spread into at least three softwares in two places has been a pain from day 1 in CNC machining !
Standards study, other solutions audit, analysis, data inventory and modelisation may be a little tedious but should be doable hopefully without much difficulties.
An important question is structured vs unstructured data one and its implications in design and implementation. If I like the principle proposed by @sliptonic, I hardly see how we could satisfy the reqs based on it. I feel the need for structured data and RDBMS strength for this project. Nevertheless, a hybrid schema combining these with JSON (natively supported by all DB engines) may help to ease database design,as well as offering room for adaptation and evolution without schema modification. That said, remains to draw the line between the two kinds of data and what it means for implementation down the road.
Then with a nice schema, I hope DB implementation and basic CRUD features won't be that hard either with the help of a nice DAL/ORM like SQLAlchemy, and more so if we choose to build upon an existing app framework. I'll have a look at https://dokos.io/, a fork of ERPNext and Frappé framework, targeting production companies, fab labs and third places as it may have everything needed and more built in (including API). Aside from these two, usual suspects like Flask etc should be considered.
For the API, first thing coming to mind is some kind of RESTfulish API with JSON payload. MTConnect and OPC-UA can't be ignored in our field, provision should be made for these to come at a later date. API design may be a tricky part...
What concerns me more is support for import/export formats
Oh I'm also in for a project name 😉
Can I propose 'Skjæring' as the project name, the Norwegian word for cutting, intersection and where roads cut through the terrain?
I like it, just grant us the 'skjering' spelling so that if we can't say it, at least we can spell it ! ;-)
PS: in lack of better idea, I'll most probably open an RFC thread in projects respective forum to discuss this...
I find forums a strain to use, so I'll leave that part to you. :)
Same here ! But what needs to be done...
TY J
petterreinholdtsen
commented
2 years ago [Jérémie Tarot]
Aside from these two, usual suspects like Flask etc should be considered.
With experience with Flash and Django, I would lean more towards Django as it handle database schema migrations natively, while in Flash you have to use an external library to get the same feature.
I like it, just grant us the 'skjering' spelling so that if we can't say it, at least we can spell it ! ;-)
With that spelling it is really a completely different word. 'skjaering' would be somewhat closer, but I guess it is better to find a name with only ascii characters instad.
-- Happy hacking Petter Reinholdtsen
petterreinholdtsen
commented
2 years ago [Petter Reinholdtsen]
With that spelling it is really a completely different word. 'skjaering' would be somewhat closer, but I guess it is better to find a name with only ascii characters instad.
What about Sculpo, latin for to carve, chisel in stone, metal or wood, according to <URL: https://www.wordsense.eu/sculpo/ >? Sadly quite a lot of hits on the web already.
-- Happy hacking Petter Reinholdtsen
sliptonic
commented
2 years ago [Jérémie Tarot] > If I like the principle proposed by @sliptonic, I hardly see how we could satisfy the reqs based on it. I feel the need for structured data and RDBMS strength for this project.
I'm still pretty unclear on exactly what requirements you're targeting, especially for a first implementation.
Of course the data needs to be structured. That doesn't automatically imply a relational structure or an RDBMS.
If you create a proper schema for the data, you can de-dupe it into a SQL or no-SQL database as needed. Or you can use it in flat files from the disk. Start with the easiest implementation that meets the needs. But define the needs first. Some user-stories or a sketch of the app would help.
From where I'm standing, it looks like you're jumping to solutions before you've fully qualified the problem.
silopolis
commented
2 years ago Le lun. 1 août 2022 à 16:18, Jérémie Tarot @.***> a écrit :
I have already reached GTC and got an ID to access their data as well as collected more from MTConnect which also implements ISO13399. These can be found here
https://drive.google.com/drive/folders/1aklkcjNatdHSgc_canfRl30Y2aw8XCk8
And for your browsing and reading pleasure, the freshly baked MTConnect v2 :)
https://model.mtconnect.org/#Package__1e2ca153-69cf-4636-a5d2-571e323348f5 https://docs.mtconnect.org/
SebKuzminsky
commented
2 years ago Hi folks, I'm excited to see you talking about this problem.
I agree this would be best done as a stand-alone project, to be used both by CAM (i.e. FreeCAD Path etc) and by LinuxCNC via "conversational" machining at the machine control computer.
I think this is a data-centric problem - the algorithms are relatively simple, and at the core is a large dataset relating work-piece materials, tool materials & coatings, tool geometries, etc. I'm not volunteering to do this work, but if I were I'd advocate for data storage in formats that lend themselves well to distributed management by git, and easy distribution via git & via packages like debs. Something like YAML or JSON seem like obvious choices to me. I'd avoid databases with their own funny non-gittable (that's a word, I just made it up) file formats.
When I tried to learn about this some years ago i found "Fundamentals of Modern Manufacturing", by Mikell P Groover, to be informative.
Here's a speeds & feeds program @jethornton wrote some time ago, for drills: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_LinuxCNC_G-Code_Generators#Drilling_Speeds_n_Feeds
I've been using the "free as in beer" crippleware app "FS Wizard"; the free crippled version runs in a browser, is quite functional for hobbyists, and IMO has a sensible interface: https://fswizard.com/
silopolis
commented
2 years ago Le sam. 6 août 2022 à 18:38, Sebastian Kuzminsky @.***> a écrit :
Hi folks, I'm excited to see you talking about this problem.
Cool
I agree this would be best done as a stand-alone project, to be used both
by CAM (i.e. FreeCAD Path etc) and by LinuxCNC via "conversational" machining at the machine control computer.
Good
I think this is a data-centric problem - the algorithms are relatively
simple, and at the core is a large dataset relating work-piece materials, tool materials & coatings, tool geometries, etc.
My guess too so very happy to have it comfirmed.
I'm not volunteering to do this work, but if I were I'd advocate for data
storage in formats that lend themselves well to distributed management by git, and easy distribution via git & via packages like debs. Something like YAML or JSON seem like obvious choices to me.
So you're at least the second one with @sliptonic. Do you have guys any ref or resource to study the hows of designing and building such a data storage?
I'd avoid databases with their own funny non-gittable (that's a word, I
just made it up) file formats.
I'm also having a little hard time seing and understanding how to build such a data warehouse and provide same data management strength and quality without a DBMS, be it table or document orientated.
Here again any insights and or learning pointer would be welcome.
When I tried to learn about this some years ago i found "Fundamentals of
Modern Manufacturing", by Mikell P Groover https://archive.org/details/fundamentalsofmo0000groo, to be informative.
Here's a speeds & feeds program @jethornton https://github.com/jethornton wrote some time ago, for drills: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_LinuxCNC_G-Code_Generators#Drilling_Speeds_n_Feeds
Thanks for these 👍
I've been using the "free as in beer" crippleware app "FS Wizard"; the free
crippled version runs in a browser, is quite functional for hobbyists, and IMO has a sensible interface: https://fswizard.com/
Yep, I regularly use the mobile version 👍 This as well as its paid brother HSM Advisor are part of my existing solutions review.
Thanks in advance for any further indication and direction
TY J
sliptonic
commented
2 years ago We've done something similar in FreeCAD for the toolbit system. I'm NOT recommending our structure for this project. It's optimized for our needs and inappropriate for the task you're talking about. I'm only pointing it to you here as an example since you asked for one.
First, we use our own file extensions but these are just json files. We also make some use of folder structures. You don't have to do that either but we found that it helps keep things tidy.
We start with a 'Tools' Directory that has 'Bit', 'Shape', and 'Library' sub-directories.
These folders contain different kinds of data and there's a relationships between them. Bits have a shape. Libraries are groups of Bits.
Looking at a library you see that it's just a list of items. Each item refers to a toolbit. So the "5mm_Endmill.fctb" refers to the corrsponding toolbit json file . In our world, a toolbit is a unique endmill or drillbit or other tool. It's physical. It shares a general shape with other similar tools. The shape is described in an actual FreeCAD document.
The json structure provides the schema including some meta data like 'version'. That's just forward looking so the application can do the right thing if we need to extend the schema in the future.
This is a pretty simple structure. It encapsulates the relationship between things very nicely though. A toolshape can be used by many toolbits. A toolbit can be in many libraries. A library can contain many toolbits.
This could be done in SQL. Had we done that, Any change to any bit, shape, library would result in a change to a binary blob. Git would be unable to diff it. Using flat files means git can help with changes and files are easily copied, shared, backed up, etc.
Of course there's a trade-off. We wouldn't want to do this if we were dealing with thousands or millions of toolbits. Then it would make much more sense to use a proper database. If we ever get to that point, it will be trivial to write a script that parses the structured json and pushes it into a proper database. After all, the structure is already there. Parsing it is easy and tells you exactly what tables to create, data types, etc. It's all implied in the json including the relationships.
smoe
commented
2 years ago Happy to feel like I agree with you all: sync tools in LinuxCNC with CAM. This may be more important than the calculations. It would also be nice to just see our communities to work together on this. Whatever the outcome may be.
Concerning data, we should think about teaming up with those who sell those mills. They have all the data and they want their customers to see it. So, my two cents for this thread is to also consider an auto-updated tool catalog, and yes, also with a link to order something. And, concerning maths, can we by some magic also learn about what (combination of) tools from that catalog would be the fastest to complete the job? At what price?
SebKuzminsky
commented
2 years ago It's my understanding that optimal feeds & speeds are determined largely experimentally, rather than analytically. The tool manufacturers perform these experiments and publish their data in the form of big tables, e.g. https://www.onsrud.com/Forms/Cutting-Data-Recommendations.asp
we should think about teaming up with those who sell those mills. They have all the data
Agreed, though I expect "teaming up" probably means "we download their PDFs and hand-convert their data to a format that our software can use, and maybe they ask us to put advertisements in our GUI". But I'd love to be wrong and be pleasantly surprised here :-)
sliptonic
commented
2 years ago I guess this topic has migrated from a pure Feeds&Speeds tool into a broader tool catalog system.
That said, I would still LOVE to see a serious FOSS alternative to Gwizard.
Gwizard is pretty cool but has serious limitations:
-windows only
-close source
As @SebKuzminsky said, optimal isn't really possible algorithmically. It's involves a lot of experimentation and experience both by the manufacturer and the user.
Some aspects of a better solution:
petterreinholdtsen
commented
2 years ago I came across https://forum.freecadweb.org/viewtopic.php?f=15&t=41026 which talk about tool libraries too.
silopolis
commented
2 years ago Le mar. 2 août 2022 à 01:47, sliptonic @.***> a écrit :
[Jérémie Tarot] > If I like the principle proposed by @sliptonic https://github.com/sliptonic, I hardly see how we could satisfy the reqs based on it. I feel the need for structured data and RDBMS strength for this project.
I'm still pretty unclear on exactly what requirements you're targeting, especially for a first implementation.
Central, networked, shared data warehouse with nice interface(s) to be consumed by different clients
Of course the data needs to be structured. That doesn't automatically imply
a relational structure or an RDBMS.
The fact that I don't see other way to satisfy reqs surely doesn't lean there aren't! 😅
If you create a proper schema for the data, you can de-dupe it into a SQL
or no-SQL database as needed.
Doesn't RDBMS implies SQL? Also I'm as open to no-SQL as to any other solution, but I'm not sure that'd be "lighter" than the db engine you wanted to avoid? 🤔
From where I'm standing, it looks like you're jumping to solutions before
you've fully qualified the problem.
Most probably the case sadly as there's no real developer in this chair, but a wannabe willing to learn and collaborate...
All directions and advices welcome, always
TY J
petterreinholdtsen
commented
1 year ago I recently came across <URL: https://academy.titansofcnc.com/series/titan-1m/mastercam-program-the-titan-1m >, which contain instructions on how to use Mastercam, and included in the instructions is a link to a "Tool Library", which is a SQLite database with information about various tools. I suspect it would be nice to be able to import such tool databases into the calculator.
-- Happy hacking Petter Reinholdtsen
silopolis
commented
1 year ago Le lun. 28 nov. 2022 à 09:09, petterreinholdtsen @.***> a écrit :
I recently came across <URL: https://academy.titansofcnc.com/series/titan-1m/mastercam-program-the-titan-1m
, which contain instructions on how to use Mastercam, and included in the instructions is a link to a "Tool Library", which is a SQLite database with information about various tools. I suspect it would be nice to be able to import such tool databases into the calculator.
Very interesting that it is a SQLite DB. Fusion 360 uses JSON files, like FreeCAD. GTC/ISO-13399 uses XML (https://gtc-tools.com).
Of course, import/export features should be a must-have ! I don't know what GWizard and HSM Advisor offer on this front...
petterreinholdtsen
commented
1 year ago https://yewtu.be/watch?v=X33LBbEKU8A give an introduction to https://confluencerd.com/apps/ , which seem like a interesting starting point.
petterreinholdtsen
commented
1 year ago I had a look at the sculpo name, but find that it have way too many hits on the Internet. Tested a few more ideas, and concluded that 'metallspon', Norwegian for metal shavings, have few hits and propose to use this as the project name. I have created a mostly empty git repo over at https://codeberg.org/pere/metallspon to see if I can get something working. As I stated earlier, I do not really know enough about this problem domain to do this on my own, but decided it was time to get something moving.
petterreinholdtsen
commented
1 year ago I was recently pointed to <URL: https://crinq.github.io/js_stuff/feed_calc/ >, whos source is available from <URL: https://github.com/crinq/js_stuff/tree/gh-pages/feed_calc >, as a JavaScript implementation of a simple feeds and speed calculator. Perhaps something to learn from?
-- Happy hacking Petter Reinholdtsen
hansu
commented
1 year ago I was recently pointed to <URL: https://crinq.github.io/js_stuff/feed_calc/ >, whos source is available from <URL: https://github.com/crinq/js_stuff/tree/gh-pages/feed_calc >, as a JavaScript implementation of a simple feeds and speed calculator. Perhaps something to learn from? … -- Happy hacking Petter Reinholdtsen
Yeah could be a good starting point. But as it is now it's a bit difficult to use. At least a picture would be nice showing the parameters like d, ae, ap and so on. And it's unclear to me in what unit the hardnes (h) should be (here from 0 to 1).
And it would be good if the tool could suggest a more useful ae and ap like Fraisa did in their calculator ToolExpert, e.g.:
Feeds and Speeds Calculator , it should include: Import and Export tables from CSV files, use Manufacturer’s Recommended Data, define tool geometry, and use tool types for Mills, Routers (special router cutters handled) and Lathes. End Mill Speed and Feed: Coatings (including PCD) & Geometry (Ballnose, Upcut, Downcut, Compression, and more). Drill Feeds and Speeds: Carbide, HSS, and Parabolic Turning and Lathe Tools Reamers, Saws, Woodruff Cutters, Corner Rounders, Tapping, Thread Mills, and Boring Heads.
Material Database: Metals of all kinds, plastics, composites, even hard to find materials like Tungsten, Cobalt Chrome, and Graphite.