评论
.jpg "COREXY 与 HBOT #463"){kind=avatar}
|
CoreXY 和 H-bot 配置在逻辑上是相同的。唯一的区别是 CoreXY 穿过传送带，因此空闲侧（在 H-bot 中与滑架平行运行的传送带部分在相反的方向）被反转，因此它与传送带的运行方向相同托架，可以切割并连接到托架上。如果您查看本页的最后一个插图并想象顶部腰带的内环被折叠以便腰带不再交叉，您会看到它变成了一个 H-bot。 将 H-bot/CoreXY 几何体视为旋转 45 度的常规笛卡尔坐标系的更好方式。我不知道现在是如何实现的，但听起来好像不是这样实现的。在内部对坐标系进行 45 度旋转应该会产生更准确且更不容易出错的结果。唯一的困难是计算限制（归位功能可能应该保留在当前的实现中）。 |
.png "COREXY 与 HBOT #463"){kind=avatar}
|
是的，我的问题是实施中的“双步”。我 我想知道是否更明智地选择 (AH,BH) 和 (AH,BL) 而不是 其中 我一直在想办法解决这个问题。我正在使用 2013 年 5 月 3 日星期五中午 12:19，whosawhatsis notifications@github.com写道：
|
|
出于这个原因，它确实应该根据坐标转换而不是双步执行来实现。此外，双步方案将分辨率降低了 sqrt(2) 的一个因子，并使所有运动变得不那么平滑（虽然我不确定，但可能也会破坏电机加速度）。如果它只是先转换坐标系，它可以将 H-bot 视为规划器中的标准笛卡尔机器人。 |
|
这就说得通了。我只是在想双步对 我已将我的问题缩小到仅当我 感谢您的意见。最后，我将重新提交 2013 年 5 月 3 日星期五下午 4:16，whosawhatsis notifications@github.com写道：
|
.png "COREXY 与 HBOT #463"){kind=avatar}
|
是的，应该按照坐标变换来处理。我们可能已经在https://github.com/ErikZalm/Marlin/pull/388或相关主题中讨论过这个问题。我知道我们在编写补丁时反复讨论过这个问题。我们提出了这个话题是否只影响 H-Bot 的问题——基本上 delta 机器人运动是否可以用 theta 和 z 高度更好地描述？径向 3d 打印机怎么样？ 我们考虑了在 Marlin 中提出这样一个补丁需要什么。 这促使我们讨论如何在当前的 Marlin 代码库中处理所需的转换。如果我们假设 MCU 可以以某种方式处理数学运算，也许是在不同的 MCU 的上下文中，那么会怎样呢？我们检查了代码库，每个处理 X/Y/Z 运动的文件都需要重构并包含在内。错误 – 这是描述我想的任务的一种通用方式。该任务将影响整个代码库。完成这将是一项艰巨的任务，但它只会影响一部分观众——同时让整个观众接受回归。 可以做到——在当前的代码库中——但我认为方法应该有所不同。我建议应该由 CPU (PC) 来完成这项工作。问题是 GCODE 提供了另一个障碍。在固件中添加广义坐标系转换支持是否有意义，而 H-bot 接受来自为经典笛卡尔机器人制作的切片工具的 gcode 命令？ 我们也一直在考虑开始一个具有广义坐标系的新代码库，作为一个被视为里程碑的项目。我预测尝试引入一个新协议不会进入列表 – 有点冒险的任务 – 但也许我们可以在 GCODE 处理中引入一个抽象层？ |
|
我得问你们是在谈论主分支中的（损坏的）CoreXY 实现，还是使用问题#388的补丁？ |
|
我现在不在我的开发机器旁，但我正在使用 ErikZalm/Marlin 和 Daid/Marlin 回购协议。当对角线移动时，这两个在 stepper.cpp 中都有一个双步，我认为这是一个坏主意。 考虑更多，我将在没有 COREXY 的情况下进行构建。如果需要，我将在我的设计或 slic3r 中进行 45 度旋转。 |
我有一个关于将 COREXY 实现与 HBOT 一起使用的基本问题。COREXY 机器人可以转动单个电机实现 45 度运动。但 HBOT 不允许这样做（两个电机都应始终移动）。目前的 Marlin COREXY 做的是单电机双步，实现 45 度移动。HBOT 需要 ax 移动和 ay 移动。