注释
.png "雕刻速度慢 #38"){kind=avatar}
|
@mkeyno在 Arduino 328 上进行灰度图像雕刻时，您不太可能获得 10000 的进给率。尤其不是每毫米 20 个像素。在 Arduino Uno 上，我在每毫米 10 个像素时达到了大约 5000 个最大值。我尝试了 smoothie，但在 3800 左右时更糟。获胜的组合是运行在 120MHz Smoothieboard 上的GRBL-LPC https://github.com/gnea/grbl-LPC 。以每毫米 10 像素运行，我在灰度和抖动上达到了 13000，在线条上达到了 20000。 |
|
@mkeyno您正在尝试将每秒 3333 像素的速度推入每秒 12000 字节的管道。您拥有的每个 gcode 行大约有 20 个字符长，因此如果不进一步优化您的 gcode，您最多可以达到每秒 600 像素，或者最多 2000 个提要。 |
.png "雕刻速度慢 #38"){kind=avatar}
|
谢谢@mayhem2408, 老实说，我不知道如何计算优化的雕刻速度，非常感谢让我知道如何去做，但在使用 GRBL 之前，我使用了用于 CNC 激光的 Marlin的修订版，它的雕刻速度非常快，我是不确定它是由engrave Gcode 转换器插件的固件本身来的，但是我希望通过 GRBL 达到尽可能快的速度 @mayhem2408 你知道为什么 GRBL 雕刻中的运动看起来不像其他 CNC 雕刻机的快速往复运动吗 |
|
@mkeyno带有 328 的 Arduino 上的 GRBL 刚用完。在 Arduino Mega 上，更大的缓冲区似乎好一点，但 GRBL-LPC 只是把其他一切都踢出了公园。即使是 Mega2560 上的 Marlin 和它的 base64 方法似乎在 7000 左右的进给率下耗尽了处理能力。如果保持速度，GRBL-LPC 是可行的方法。我还发现出于某种原因，GRBL-LPC 接收数据的速度比选择的 115200 波特快得多。 因此，在运行 328 的 Arduino Uno 上，最大串行带宽为 115200（默认情况下，可以使用更高的设置重新编译），每秒可提供 12800 个字符。由于 GRBL 的 ping pong 成熟，我们只说 10000。所以你需要查看 gcode 文件并估计每行有多少个字符。您的屏幕截图显示了 21 个字符的行“G1 X0 Y0.05 F40000 S0”。回车加 2，得到 23。假设 20 是平均值。所以 10000 / 20 = 500。每行 1 个像素，每秒有 500 个像素。将分辨率设置为每毫米 20 个像素，即每秒 500 / 20 = 25 毫米，或每分钟 1500 毫米。优化 gcode 可以增加这一点。 我正在试验 gcode，其中 1 个像素看起来像“X12.4S465”，每行只有 11 个字符。所以我们每秒大约有 1000 行。我以每毫米 10 个像素进行灰度雕刻，即每秒 100 毫米或每分钟 6000 毫米。GRBL-LPC 的速度是这个速度的两倍多。 |
|
你好@mkeyno谢谢@mayhem2408 感谢您的宝贵意见和计算 在开发 LaserGRBL 时，我一直想着使用功率和速度有限的硬件的爱好，特别是 DIY 雕刻机高达 10W 激光二极管。速度更快、功能更强大的硬件通常具有针对控制器板优化的专用软件。 但是，如前所述，由于某些原因存在速度限制。 第一个原因是 arduino 的工作频率和 grbl 代码速度将步进频率限制在 30kHz 左右。你的 $100=126 这相当于 30000/126 = 238mm/s = 14’285mm/min 所以这不是极限。grbl/grbl#41（这不是你的瓶颈） 第二个原因是与 G 代码数据流相关的通信速度。以 G 代码语法（专为矢量指令设计）发送位图/光栅图像是一种可怕的字节浪费。尽管可以优化代码生成，但它始终需要发送 S(POWER) X(DISTANCE) 命令。即发送四个像素 200-212-212-209（4 字节），分辨率为 10 行/毫米（步长为 0.1 毫米），生成此代码：“S200 X0.1 换行符 S212 X0.2 换行符 S209 X0.1” 这些是一共33个字节。该数据流能够快速填满通信线路和 grbl 缓冲区（只有 127 字节） 这些不是 LaserGRBL 的限制，而是使用 G 代码/grbl 的固有限制。一个高效的系统需要一个将图像作为字节序列传输的协议，以及一个可以本地打印图像的硬件卡。 LaserGRBL 可以优化生成的 G 代码（即修剪空白，连接相同颜色的后续像素）但它永远不会有效，因为 G 代码不是用于传输/编码光栅图像。 |
|
@arkypita据我所知，DIY 爱好是许多此类 CNC 项目的重点，但您可能听说过中国制造的 K40 激光切割机。非常便宜，非常强大，光输出为 40W，但软件和控制器很糟糕。我花了 400 美元买了我的。本机最大进给速度为每分钟 30000mm (F30000)。超出了 GRBL Arduino 解决方案的限制，该解决方案以每毫米 80 步的速度限制在大约 F22000。Smoothieboards 没有这么低的限制，但由于某些原因，它处理 gcode 的速度比 GRBL 慢。现在来运行在 smoothieboards 上的 GRBL-LPC 绝对是迄今为止我遇到的最快的。就在昨天，我以令人印象深刻的每分钟 30000 毫米的速度推动了一个线稿徽标，这将龙门架和步进器推向了极限。 至于缓冲区，GRBL 非常小，但这是硬件限制。冰沙上的 GRBL-LPC 很大。249 规划器缓冲区和 8192 串行缓冲区。缓冲区欠载没有问题。在两个缓冲区之间，它的缓冲区中通常包含 800 多行 gcode。我知道 gcode 不是用来传输位图图像的，但是 GRBL-LPC 和 smoothieboard 组合确实对它的工作大有帮助。 在 base64 编码行中发送光栅数据的 Marlin 方法效果很好，理论上允许在 75 字节行中发送大约 50 个像素，这可能允许每秒 7000+ 像素或 F40000+ 的 Feed，但 Mega2560 耗尽了动力处理快速且通常在大约 F7000 时断断续续的数据，而不是因为串行欠载。 获得可靠的解决方案非常困难，因为在 gcode 中没有定义栅格数据的标准，因此它试图使其在标准内工作，如 GRBL，或制作新的东西，如 Marlin。两者都有优点和缺点。 |
|
谢谢@arkypita &@mayhem2408对于有用的信息，我尝试使用您的建议来提高速度，但是@arkypita真正声明“以 G 代码语法（专为矢量指令设计）发送位图/光栅图像是一种可怕的字节浪费”，我认为这是雕刻低速的瓶颈，也如前所述，我使用了修改版本Marlin 用于雕刻，我再次检查了代码，发现 用于创建光栅代码的 python 函数 def generate_raster_gcode(self, curve, laserPower, altfeed=None):
...
G7解释器的代码 #ifdef LASER_RASTER
case 7: //G7 Execute raster line
if (code_seen('L')) laser.raster_raw_length = int(code_value());
if (code_seen('$')) {
laser.raster_direction = (bool)code_value();
destination[Y_AXIS] = current_position[Y_AXIS] + (laser.raster_mm_per_pulse * laser.raster_aspect_ratio); // increment Y axis
}
if (code_seen('D')) laser.raster_num_pixels = base64_decode(laser.raster_data, &cmdbuffer[bufindr][strchr_pointer - cmdbuffer[bufindr] + 1], laser.raster_raw_length);
if (!laser.raster_direction) {
destination[X_AXIS] = current_position[X_AXIS] - (laser.raster_mm_per_pulse * laser.raster_num_pixels);
if (laser.diagnostics) {
SERIAL_ECHO_START;
SERIAL_ECHOLN("Negative Raster Line");
}
} else {
destination[X_AXIS] = current_position[X_AXIS] + (laser.raster_mm_per_pulse * laser.raster_num_pixels);
if (laser.diagnostics) {
SERIAL_ECHO_START;
SERIAL_ECHOLN("Positive Raster Line");
}
}
laser.ppm = 1 / laser.raster_mm_per_pulse; //number of pulses per millimetre
laser.duration = (1000000 / ( feedrate / 60)) / laser.ppm; // (1 second in microseconds / (time to move 1mm in microseconds)) / (pulses per mm) = Duration of pulse, taking into account feedrate as speed and ppm
laser.mode = RASTER;
laser.status = LASER_ON;
laser.fired = RASTER;
prepare_move();
break;
#endif // LASER_RASTER
inkscape 的示例栅格代码 |
|
@mkeynoMarlin 格式中使用的 G7 代码非常有效，但我的经验表明它的计算量要大得多。在开始断断续续之前，我可以使用 G7s base64 从 Marlin 获得的最大提要大约是 F7000，这不是因为带宽。G7s base64 应该能够每秒传输超过 7000 个像素，即每毫米 10 个像素，理论上可以达到超过 F40000 的进给。就 GRBL 而言，另一个问题是 Arduino Unos 内存中没有剩余空间来添加如此庞大的功能。它可能会添加到 GRBL-Mega 版本中，因为它有更多空间。我目前正在寻找用于 smoothieboards 的 GRBL-LPC，看看我是否可以向它添加类似的功能。 测试 1： 测试 2： 测试 3： 测试4：64 测试 5： 这些测试清楚地表明 G1 风格的光栅不是瓶颈，甚至 G7 也对微控制器有限制。GRBL-LPC 上的 G7 应该能够全面维持平稳的 F30000。我知道社区一般不愿意走 G7 道路，因为它不是标准，但我喜欢它并且已经使用它多年，甚至为水平、垂直和 45 度 Base64 雕刻定制了固件和个人想看看我是否能在 GRBL-LPC 中得到类似的东西。 |
|
如果 grbl 将实现一种光栅命令，与 merlin G7 相同或使用不同的语法，我将是第一个在其 GUI 中实现的人。 但是我知道 arduino UNO 上的 grbl 被推到了可用资源的极限，所以任何新代码/函数的实现都是一个大问题。 |
我按照下图设置了 GRBL 1.1f 和软件 2.6.6 配置，但是雕刻速度不是我预期的，我看到许多 CNC 机器在雕刻工作中使用高速率往复运动，但我没有看到这样的运动对于任何雕刻尝试，任何提示都非常感谢