注释
除了难以获得所有这些信息之外,我觉得这样的工具属于 CAM 包(或者,至少在执行 CAM 的 PC 上)而不是在控制 PC 上。 将它集成到 LinuxCNC 中如何使其比现有的进给和速度计算器更有用? |
虽然我同意这对于使用车床/铣床宏或其中一个代码生成器的人来说是一笔巨大的财富,但我也觉得这样做的工作很棒,而且做这件事的技巧也很高。有一个专门用于此的完整程序 G-Wizard。听起来像是一个巨大的研究项目。 |
@Supermagnum你能解释一下这样的计算器在 LinuxCNC 中是如何工作的吗?是拥有一个独立工具的想法,还是应该以某种方式将其纳入 LinuxCNC 机制? |
我认为将它作为独立工具使用的可能性,以及将数据发送到 LinuxCNC 的选项就足够了。 |
那不是免费的,而且看起来它不能在 Linux 上运行。 |
[超级大酒瓶]
我认为将它作为独立工具使用的可能性,以及将数据发送到 LinuxCNC 的选项就足够了。
所以它可以是一个单独的项目和工具,支持向 LinuxCNC 发送信息。也许我们应该从这样的姊妹项目开始,看看我们能走多远?我对这个主题的了解还不够,无法独自完成,但如果你带头,也许可以帮助完成其他任务。:) 如果您有兴趣,请在 IRC 上联系我,#linuxcnc 或#linuxcnc-devel (Libera.Chat)。
|
乐山姆。7 月 30 日。2022 à 19:41,petterreinholdtsen ***@***.***> 一个评论:
[Supermagnum] > 我认为将它用作独立工具的可能性——使用 > 选项将数据发送到 LinuxCNC 就足够了。所以它可以是一个单独的项目和工具,支持向 LinuxCNC 发送信息。也许我们应该从这样的姊妹项目开始,看看我们能走多远?我对这个主题的了解还不够,无法独自完成,但如果你带头,也许可以帮助完成其他任务。:) 如果您有兴趣,请在 IRC 上联系我,#linuxcnc 或#linuxcnc-devel (Libera.Chat)。
很高兴读到这些人!这实际上是我在这里与@TurBoss一起提倡的工具数据库管理应用程序的第二部分在 FreeCAD 路径项目中。该愿景是一个专用的工具和切割参数应用程序,CAM 到 CNC 生产和供应流程中的所有应用程序都可以连接到该应用程序以提取和放置他们需要的数据。除了独立的界面外,供应管理/ERP 软件(Dolibarr、ERPnext、Odoo)、CAM 包(FreeCAD Path、BlenderCAM、kuteCAM)、模拟(CAMotics)、对话式编程工具(NativeCAM、特征宏库)、工具设置器和当然我们心爱的LinuxCNC通过tooldb接口,都是潜在的客户端应用。基本模式应与(部分)GTC / ISO13399 兼容,用于工具/夹持器/附件数据,以及扩展的功能,一方面支持商店/机器/工具更换器-杂志,另一方面支持材料/操作/策略/切割参数其他。能够导入格式正确的表格或 json 数据当然是要求的一部分。正如我已经说过的,我已经在不同的频道中就此进行了交叉讨论,我也在考虑在我上周开始的 Matrix Space 中创建一个专门的频道: https://matrix.to/#/#linuxcnc-space:matrix.org 从技术上讲,这将位于 DBMS 上,但是来自 FC/Path 的@sliptonic建议使用 git 管理的结构化 json 文件存储库。可能是使用 DBMS 的 JSON 支持的结构化和非结构化数据管理的混合方式。由于这些项目中的大多数已经在使用 Python,至少后端会用它编写,并为前端、客户端和集成提供一个漂亮而灵活的 API。后者将可以使用他们选择的工具箱以他们需要的方式自由使用 API。我已经到达 GTC 并获得了一个 ID 来访问他们的数据,并从同样实施 ISO13399 的 MTConnect 收集了更多信息。这些可以在这里找到 https://drive.google.com/drive/folders/1aklkcjNatdHSgc_canfRl30Y2aw8XCk8 在接下来的几周内,我将回顾许多软件包使用的工具管理功能和工具数据,包括 G-Wizard、HSMAdvisor、CIMCO、F360、MasterCAM、TopSolid、MachiningCloud.com。然后应该研究如何摄取(输出)GTC 数据……哦,我也在寻找项目名称? 感谢阅读 TY J PS:由于缺乏更好的想法,我很可能会在项目各自的论坛中打开一个 RFC 线程来讨论这个……
|
乐伦。2022 年 1 月 20:13,petterreinholdtsen ***@***.***> 评论:
[Jérémie Tarot] > 这实际上是我提倡的工具数据库管理应用程序的第二部分 > 在这里与@TurBoss 一起在 FreeCAD Path 项目中。听起来您在考虑这个问题领域时遥遥领先于我。你认为什么是难题?收集数据还是实施数据库?
作为一名前 IT 人员,从 CNC 加工的第一天起,将我的工具数据分布到两个地方的至少三个软件中一直是一种痛苦!标准研究、其他解决方案审计、分析、数据清单和模型化可能有点乏味,但应该可以轻松完成。一个重要的问题是结构化数据与非结构化数据及其对设计和实施的影响。如果我喜欢@sliptonic提出的原则,我几乎看不出我们如何满足基于它的要求。我觉得这个项目需要结构化数据和 RDBMS 的力量。然而,将这些与 JSON(所有数据库引擎原生支持)相结合的混合模式可能有助于简化数据库设计,并为无需模式修改的适应和演进提供空间。也就是说,仍然需要在两种数据之间划清界线,以及它对未来实施的意义。然后有了一个很好的模式,我希望数据库的实现和基本的 CRUD 功能在像 SQLAlchemy 这样的一个很好的 DAL/ORM 的帮助下不会那么难,如果我们选择在现有的应用程序框架上构建,那么更是如此。我会看看https://dokos.io/,ERPNext 和 Frappé 框架的一个分支,针对生产公司、制造实验室和第三方场所,因为它可能拥有所需的一切和更多内置功能(包括 API)。除了这两个之外,还应该考虑像 Flask 等常见的嫌疑人。对于 API,首先想到的是某种带有 JSON 负载的 RESTfulish API。MTConnect 和 OPC-UA 在我们的领域不能被忽视,应该为这些在以后的日期做好准备。API设计可能是一个棘手的部分……我更关心的是对导入/导出格式的支持
哦我也在求项目名? 我可以建议将“Skjæring”作为项目名称,挪威语中的切割、交叉路口以及道路穿过地形的地方吗?
我喜欢它,只要给我们“skjering”拼写,这样即使我们不会说,至少我们可以拼写!;-)
> PS:由于没有更好的主意,我很可能会在 > 项目各自的论坛中打开一个 RFC 线程来讨论这个……我发现论坛很难使用,所以我会把那部分留给你。:)
同样在这里 !但是需要做什么… TY J
|
[杰瑞米塔罗牌]
除了这两个之外,还应该考虑像 Flask 等常见的嫌疑人。
凭借 Flash 和 Django 的经验,我会更倾向于 Django,因为它本身处理数据库架构迁移,而在 Flash 中,您必须使用外部库才能获得相同的功能。
我喜欢它,只要给我们“skjering”拼写,这样即使我们不会说,至少我们可以拼写!;-)
有了那个拼写,它真的是一个完全不同的词。’skjaering’ 会更接近一些,但我想最好还是找到一个只包含 ascii 字符的名称。
|
[彼得·赖因霍尔特森]
有了那个拼写,它真的是一个完全不同的词。’skjaering’ 会更接近一些,但我想最好还是找到一个只包含 ascii 字符的名称。
|
我仍然不清楚您的目标需求是什么,尤其是对于第一次实施。 从我的立场来看,您似乎在完全确定问题之前就跳到了解决方案。 |
乐伦。2022 年 1 月 16 日 16:18,Jérémie Tarot ***@***.***> 评论:
|
大家好,很高兴看到你们讨论这个问题。 我同意这最好作为一个独立的项目来完成,由 CAM(即 FreeCAD Path 等)和 LinuxCNC 通过机器控制计算机上的“对话式”加工来使用。 我认为这是一个以数据为中心的问题——算法相对简单,核心是一个与工件材料、工具材料和涂层、工具几何形状等相关的大型数据集。我不是自愿做这项工作的,但如果我是的话,我会提倡以适合 git 分布式管理的格式存储数据,并通过 git 和 debs 等包轻松分发。YAML 或 JSON 之类的东西对我来说似乎是显而易见的选择。我会避免使用自己有趣的非 gittable(这是一个词,我刚刚编造的)文件格式的数据库。 几年前,当我试图了解这一点时,我发现Mikell P Groover 撰写的“现代制造基础知识”提供了丰富的信息。 这是一个速度和进给程序@jethornton前段时间写的,用于练习:http ://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_LinuxCNC_G-Code_Generators#Drilling_Speeds_n_Feeds 我一直在使用“像啤酒一样免费”的 crippleware 应用程序“FS Wizard”;免费的残废版本在浏览器中运行,对爱好者来说非常实用,IMO 有一个合理的界面:https ://fswizard.com/ |
乐山姆。2022 年 6 月 18 日 18:38,塞巴斯蒂安·库兹明斯基 ***@***.***> 评论:
大家好,很高兴看到你们讨论这个问题。
很酷,我同意这最好作为一个独立的项目来完成,同时使用
通过 CAM(即 FreeCAD Path 等)和 LinuxCNC 通过机器控制计算机上的“对话式”加工。
很好,我认为这是一个以数据为中心的问题——算法相对
很简单,核心是一个与工件材料、工具材料和涂层、工具几何形状等相关的大型数据集。
我的猜测也很高兴得到证实。我不是自愿做这项工作,但如果我是我会提倡数据
以适合 git 分布式管理的格式存储,并通过 git 和 debs 等包轻松分发。YAML 或 JSON 之类的东西对我来说似乎是显而易见的选择。
只是编造的)文件格式。
我也很难理解如何构建这样的数据仓库并在没有 DBMS 的情况下提供相同的数据管理强度和质量,无论是面向表还是面向文档。在这里再次欢迎任何见解和/或学习指针。几年前,当我试图了解这一点时,我发现了“Fundamentals of
前段时间写的,用于练习: http ://wiki.linuxcnc.org/cgi-bin/wiki.pl?Simple_LinuxCNC_G-Code_Generators#Drilling_Speeds_n_Feeds
感谢这些? 我一直在使用“像啤酒一样免费”的 crippleware 应用程序“FS Wizard”;免费
残缺的版本在浏览器中运行,对爱好者来说非常实用,IMO 有一个合理的界面:https ://fswizard.com/
是的,我经常使用手机版? 这以及它的付费兄弟 HSM Advisor 是我现有解决方案审查的一部分。提前感谢 TY J 的任何进一步指示和指导
|
我们在 FreeCAD 中为工具位系统做了类似的事情。我不推荐我们的项目结构。它针对我们的需求进行了优化,但不适合您正在谈论的任务。因为你要求一个,所以我只是在这里将它指向你作为一个例子。 首先,我们使用自己的文件扩展名,但这些只是 json 文件。我们还使用了一些文件夹结构。您也不必这样做,但我们发现它有助于保持整洁。 我们从具有“Bit”、“Shape”和“Library”子目录的“Tools”目录开始。 这些文件夹包含不同种类的数据,并且它们之间存在关系。比特有一个形状。库是位组。 查看图书馆 时,您会发现它只是一个项目列表。每个项目都是指一个工具位。所以“5mm_Endmill.fctb”指的是相应的工具位 json 文件。在我们的世界中,工具头是一种独特的立铣刀或钻头或其他工具。这是物理的。它与其他类似工具共享一般形状。该形状在实际的 FreeCAD 文档中进行了描述。 json 结构提供了包含一些元数据(如“版本”)的模式。这只是前瞻性的,因此如果我们将来需要扩展模式,应用程序可以做正确的事情。 这是一个非常简单的结构。不过,它很好地封装了事物之间的关系。一个 toolshape 可以被许多 toolbit 使用。工具位可以在许多库中。一个库可以包含许多工具位。 这可以在 SQL 中完成。如果我们这样做了,对任何位、形状、库的任何更改都会导致对二进制 blob 的更改。Git 将无法区分它。使用平面文件意味着 git 可以帮助进行更改,并且文件可以轻松复制、共享、备份等。 当然需要权衡取舍。如果我们要处理数千或数百万个工具位,我们就不想这样做。那么使用合适的数据库会更有意义。如果我们到了那个地步,编写一个脚本来解析结构化的 json 并将其推送到适当的数据库中将是微不足道的。毕竟,结构已经存在。解析它很容易,并准确告诉您要创建哪些表、数据类型等。这一切都隐含在 json 中,包括关系。 |
很高兴我同意你们所有人的观点:LinuxCNC 中的同步工具与 CAM。这可能比计算更重要。看到我们的社区就此共同努力也很不错。不管结果如何。 关于数据,我们应该考虑与那些出售这些工厂的人合作。他们拥有所有数据,并且希望他们的客户能够看到这些数据。因此,我对该线程的两分钱还考虑了一个自动更新的工具目录,是的,还有一个订购链接。而且,关于数学,我们是否可以通过一些魔法来了解该目录中的哪些工具(组合)最快完成工作?什么价格? |
据我了解,最佳进给和速度主要是通过实验确定的,而不是通过分析确定的。工具制造商进行这些实验并以大表格的形式发布他们的数据,例如https://www.onsrud.com/Forms/Cutting-Data-Recommendations.asp
同意,但我认为“合作”可能意味着“我们下载他们的 PDF 并将他们的数据手动转换为我们的软件可以使用的格式,也许他们会要求我们在我们的 GUI 中投放广告”。但我很乐意在这里犯错并感到惊喜 |
我想这个主题已经从一个纯粹的 Feeds&Speeds 工具迁移到一个更广泛的工具目录系统。 作为@SebKuzminsky说,最佳不是真正可能的算法。它涉及制造商和用户的大量实验和经验。
|
勒马尔。2 aût 2022 à 01:47,sliptonic ***@***.***> a écrit :
[Jérémie Tarot] > 如果我喜欢@sliptonic < https://github.com/sliptonic > 提出的原则,我几乎看不出我们如何能够满足基于它的要求。我觉得这个项目需要结构化数据和 RDBMS 的力量。我仍然不清楚您的目标需求是什么,尤其是对于第一次实施。
中央、网络、共享数据仓库,具有可供不同客户端使用的漂亮接口 当然,数据需要结构化。这并不自动意味着
关系结构或 RDBMS。
事实上,我没有看到其他方式来满足需求,这并不意味着没有!? 如果您为数据创建了一个合适的模式,您可以将其重复数据删除为 SQL
或根据需要使用非 SQL 数据库。
RDBMS 不意味着 SQL 吗?此外,我对任何其他解决方案都对无 SQL 持开放态度,但我不确定这是否比您想避免的数据库引擎“更轻”?? 从我所站的位置来看,您之前似乎正在跳转到解决方案
你已经完全解决了这个问题。
很可能是这种情况,因为这把椅子上没有真正的开发人员,而是一个愿意学习和合作的人……欢迎所有方向和建议,永远是 TY J
|
乐伦。11月28日 2022 à 09:09,petterreinholdtsen ***@***.***> 一个评论:
我最近遇到 <URL: https://academy.titansofcnc.com/series/titan-1m/mastercam-program-the-titan-1m >,其中包含有关如何使用 Mastercam 的说明,说明中包含一个链接到“工具库”,这是一个包含各种工具信息的 SQLite 数据库。我怀疑能够将此类工具数据库导入计算器会很好。
非常有趣的是,它是一个 SQLite 数据库。Fusion 360 使用 JSON 文件,如 FreeCAD。GTC/ISO-13399 使用 XML ( https://gtc-tools.com )。当然,导入/导出功能应该是必备的!我不知道 GWizard 和 HSM Advisor 在这方面提供了什么……
|
进给和速度计算器,它应该包括:
从 CSV 文件导入和导出表格,使用制造商的推荐数据,定义刀具几何形状,以及使用铣床、铣刀(处理的特殊铣刀)和车床的刀具类型。立铣刀速度和进给:涂层(包括 PCD)和几何形状(球头、上切、下切、压缩等)。
钻头进给和速度:硬质合金、高速钢和抛物线车削和车床工具铰刀、锯、圆弧铣刀、圆角铣刀、攻丝、螺纹铣刀和镗头。
材料数据库:
各种金属、塑料、复合材料,甚至是很难找到的材料,如钨、钴铬和石墨。