评论
.png "M556 实施 ? #902"){kind=avatar}
|
探测只能为您提供与其他两个坐标相对应的一个维度上的偏移量，因此无法使用探测来区分非电车平台和非正交轴之间的区别。如果你问我，一个让轴很容易非正交的设计不应该被称为“智能”。 |
.png "M556 实施 ? #902"){kind=avatar}
|
X 到 Y 校正不需要探测。探测只会自动进行 Z 到 Y 和 Z 到 Z 正交轴补偿。要进行 X 到 Y 正交轴补偿，您需要打印一个应该成直角的零件，然后他们会测量它在 cretin X 或 Y 距离处超出多少毫米。也就是说，当打印通常只需要 Y 移动的东西时，X 现在也会移动以进行校正。 |
但这不是探测 X/Y 的重点，而是打印、测量和输入差异（如 mark 所说）。|
虽然我坚持我的立场，即以这样一种方式设计机器，即这些错误更容易在软件中补偿而不是机械修复是一种可怕的做法，但这提出了我一段时间以来一直想提出的观点，即Marlin 确实需要在逻辑坐标（始终是笛卡尔坐标，在 gcode 中以毫米为单位）和轴的物理位置（按步长测量）之间的通用抽象层。对于像我们大多数人使用的没有平台补偿的离散笛卡尔（一个轴直接对应一个步进驱动器）机器人，只需要一个比例因子（步数/毫米），但其他几何形状如 deltabots、h-bot/coreXY 差动驱动等. 有丑陋的黑客，代码被插入到几十个不同的地方，以应对这些几何形状所需的变化。 有没有人认为这是像我认为的一样重要的补充？ |
.png "M556 实施 ? #902"){kind=avatar}
|
我只能同意你关于通过软件机械错误补偿的不良做法。这通常是一种糟糕的工作方式 |
.jpg "M556 实施 ? #902"){kind=avatar}
|
你好， 是的，我认为你在这里提出了一个很好的观点。 太多的 hack 很快就会变得低效并破坏灵活性。 之后一如既往地在性能方面，灵活性似乎 因此，也许如果人们开始使用 marlin V2 寻求 Arm 支持，那么此时可以 我认为这会使您的抽象层更加灵活。 De : whosawhatsis [ mailto:notifications@github.com ] 虽然我坚持我的立场，即以这样一种方式设计机器，即 驱动器等有丑陋的技巧，其中代码被插入到几十个不同的 有没有人认为这是像我认为的一样重要的补充？ 直接回复此电子邮件或在 GitHub 上查看它 |
|
我只是觉得很有趣看到每个人（无一例外）在自动调平（实际实施）后运行，这是修复不良机械平台对齐的软件技巧，但对于那两个轴（XY），不，这不好，软件不应该不要修理坏机械。 |
|
因为这不是 marlin 的问题，而是构建问题，并且没有任何评论，因为我可以关闭这个， |
对于 smartrap 项目。该设计意味着正交误差可能很难通过机械调整来纠正。
M556指令的执行：轴补偿可以很好的解决这个问题。
不幸的是，我看不出数学应该如何做到这一点:(（尤其是在 X 和 Y 之间）。
也许有人会很快看到如何实现这个？