哇哈！这个框架很棒:-)

红色边框只是安全提示，并不真正限制输入。我认为您已经尝试过使用大于 1000 的数字并且它有效，对吗？

但是，由于 Bitmap 对象的限制和应用程序内存限制，在 32 位环境中每个进程接近 2GB，因此存在最大大小和分辨率的硬限制。

如果您需要以 20 线/mm 的速度使用 1000x1000mm LaserGRBL，则需要在内部生成 20’000×20’000 像素的位图（无论原始图像大小如何）。每个像素需要 32bit，所以这个尺寸的图像需要 20000x20000x32/8 = 1.6GB

因为整个过程需要一些步骤，并且每个步骤都需要在位图上工作，有时我可以在内存中有 2-3 个这种大小的位图，所以很容易达到 2GB 的限制并且程序崩溃。

我通过实验发现我可以管理最大 6000×7000，这意味着尺寸为 300×350 @ 20lines/mm（或 600×700 @ 10lines/mm 或 1200×1400 @ 5lines/mm 等）。我已经在 LaserGRBL 上硬编码了这个限制，所以线/毫米分辨率在内部被限制为一个可靠的值（尽管根据要求设置了什么）。

所以…是的，您可以使用更大的图像尺寸，直到您想要的任何尺寸，但 LaserGRBL 会限制分辨率。

但你很幸运！

第一：现代 64 位操作系统没有每个进程 2GB 的限制，因此我可以轻松删除我的硬编码分辨率限制器以允许在 64 位环境中处理更大的图像（我将在下一个版本中为您做这件事）。

请注意，如果我这样做，处理 9×9 英尺 @ 10 线/毫米的大图像需要
27’430×27’430 像素位图来处理（接近 3GB 的数据！）。由于LaserGRBL需要在内存中使用多个位图，3GB在处理过程中可能会变成9GB。

如果你的电脑没有这么大的内存，整个过程可能会非常非常慢，因为需要在磁盘上交换（当你没有足够的物理内存时，Windows 使用慢速硬盘作为内存）。

其次，我可以在 LaserGRBL 中进行很多优化，使其能够处理如此巨大的图像尺寸：

• 消除在内存中使用多个图像的需要（需要更少的内存）
• gcode生成中的一些优化（加快整个过程）

是的，事实上，你是对的，它们只是暗示……
你是神。
期待更新。
并感谢您快速而详细的回复！
最好的，
伊根

你好@eganfrantz我已经删除了 6000×7000 分辨率限制。

现在 LaserGRBL 可以处理高达 22000*22000 (480Mpx)，这意味着 2.2mt x 2.2mt (7x7feet) @ 10lines/mm 分辨率的图像。

我已经用 1mt x 1mt @ 10lines/mm (100Mpx) 对其进行了测试，在 2.8GHz 四核上生成 GCode 大约需要 10 分钟 – 使用 5GB RAM。它可能有点慢（但与执行时间相比并不算什么），但是我在进一步优化方面还有改进余地。

现在就这样了，您可以通过下载预发行版 2.8.21来尝试这些更改

让我知道你是否愿意用你不可思议的设备做一些测试:-​​)