注释
成员
|
@Joushou:您可以随意分叉和修改 Grbl 源代码,但 arcs 将保留在 Grbl 中。它真的没有添加那么多并且工作得很好。我发现预处理器造成的问题多于它们的价值,因为不清楚是什么导致了问题。 |
作者
|
我从来没有打算直接删除它——我只是提出了将它添加到无穷无尽的配置选项列表中的想法,假设它可以通过一两个 ifdef 来完成。我的主要问题是,除了程序内存(这并不是那么有趣)之外,它是否会首先节省任何东西来做这件事。Grbl 在非常紧张的内存预算下运行,但我不知道弧计算消耗了多少预算。 至于预处理器 – 它们与愚蠢的 gcode 导出器没有太大区别,这往往也是一个薄弱环节(这就是为什么我决定首先制作一个。MakerCAM 和 Inventables 的 Easel 导出不兼容或延迟的 gcode,分别)。它是一种工具,可以纠正 GUI 的错误,并通过提供比 grbl 的一部分更高级的功能来帮助手动 gcode 编写者。但是,与许多爱好项目一样,这当然主要是我自己喜欢的(而且足够令人惊讶,相对没有错误!这对我来说是一种全新的体验)工具。 不管怎样,谢谢你的意见!毕竟,这只是我的一个变态想法,我以为我会说出来。 |
贡献者
|
@Joushou:画架开发者在这里? 我很高兴听到您不喜欢 Easels gcode 的地方。您可以通过 Easel 右下角的小问号按钮让我们知道,或者直接发送电子邮件至paul@inventables.com给我。 |
作者
|
@paulkaplan哎呀!当你在背后说话时,别人不小心听到了,这真是太尴尬了。? 我已经在 Easel support thingie 上发送了一条消息(这是一个错误的决定 – 我应该使用你的电子邮件,考虑到时差、消息长度等)。我会热切地等待回复! |


我正在编写一个预处理器/流光处理器,它可以很好地处理弧线,并且在未来还会协调偏移量、起始位置、固定循环、yadda yadda。
所以,我有一个肮脏的想法:是否会剥离 Grbl 以仅具有允许从外部引导其余功能集的功能(无弧,无偏移等)释放内存以具有更大的计划或串行缓冲区?
这是一个非常实验性的想法。我认为通过一个简单的预编译定义暂时禁用弧应该相当容易(?),但除了从 mc_arc 中节省一堆堆栈空间外,我不确定后果。
任何意见?