没有人？:-(

抱歉，我无法测试您报告的问题，因为我没有 arduino mega 板。
您是否尝试更改 LaserGRBL 中的一些设置，如软重置、硬重置和线程模式？

LaserGRBL 是我测试的唯一开始发送 18H 后跟“？”的程序？“？” 立即无需等待起始字符串。

当连接打开时，LaserGRBL 进入连接状态并启动计时器。

SetStatus(MacStatus.Connecting);
connectStart = Tools.HiResTimer.TotalMilliseconds;

现在，如果 LaserGRBL 从 grbl 收到任何报告机器状态的状态报告（空闲、运行、暂停、门…），右下角状态栏中显示的状态反映收到的状态，但如果它没有收到从在不到 10 秒的时间内连接到其他东西，超时到期并且连接将关闭。

if (MachineStatus == MacStatus.Connecting && Tools.HiResTimer.TotalMilliseconds - connectStart > 10000)
	OnConnectTimeout();

发送“？” 是 LaserGRBL 必须强制 grbl 回复状态报告的唯一方法。

LaserGRBL 包含一个诊断模式，可以通过命令提示符设置，记录整个通信过程。

如果您从命令提示符或通过带有“comlog”参数“C:\Program Files (x86)\LaserGRBL\LaserGRBL.exe comlog”的快捷方式启动 LaserGRBL，程序将记录一个名为“comlog.txt”的文件，位于“C: \用户\你的名字\AppData\Roaming\LaserGRBL”。

在 comlog 文件中，您可以找到从 LaserGRBL 发送/接收的所有串行数据。
以下是有效的 comlog 的样子：https ://github.com/arkypita/LaserGRBL/files/2636346/comlog.txt

在尝试硬/软重置设置没有结果后，我发现将线程模式设置为慢速可以更好地连接。但并不完美。
它最多需要 5 次尝试“连接 – 断开连接”，直到有响应。
有时，软件也会因尝试次数过多而崩溃。
所以这似乎是一个不安全的解决方法。
不幸的是，我不完全理解软件中的启动机制，也没有重新编译软件的编程设置。
我看你发的是“.” 然后 ”？” 反复地。然后等待 GRBL 的状态消息。但我找不到 GRBL 的欢迎字符串是在哪里处理的。

我的猜测是，该软件并不总是正确地从 GRBL（版本）读取欢迎字符串，或者在连接后不清除 RX 管道。
硬件在重置后立即发送欢迎字符串，而无需来自主机的任何请求。在我看来，这是 GRBL 非常糟糕的事情。在适当的通信中，未经请求不得发送任何数据。
我目前正在禁用 GRBL 中的启动字符串，然后尝试是否可以更可靠地与 LaserGRBL 进行通信。
这个软件的可悲之处在于，我测试的所有其他程序都可以即时连接以与开发板通信。这表明我没有董事会问题。
当然，带有 GRBL 的小型 Arduino Nano 板不如 Mega 板快。这可以解释为什么 Nano 的问题较少。

哦，你比我快。我会尝试日志。

我的猜测是，该软件并不总是正确地从 GRBL（版本）读取欢迎字符串，或者在连接后不清除 RX 管道。
硬件在重置后立即发送欢迎字符串，而无需来自主机的任何请求。在我看来，这是 GRBL 非常糟糕的事情。

LaserGRBL 不需要“Grbl 1.1f [‘$’ for help]”欢迎字符串来认为自己已连接。

LaserGRBL 需要正确解析状态报告消息，如 <Idle|MPos:0.000,0.000,0.000|FS:0,0|Pn:S> 以认为自己已连接。

恕我直言，您的大型董事会没有回复“？” 带有状态报告，或者它正在回复格式错误（或不特定）的报告。

这个软件的可悲之处在于，我测试的所有其他程序都可以即时连接以与开发板通信。这表明我没有董事会问题。

其他程序根本不使用状态报告中的数据，它们认为自己已连接，只是因为它们成功打开了 com。作为副作用，他们通常不使用状态（Idle、Run、Hold、Jog、Alarm、Door、Check、Home、Sleep）来过滤/调节他们的 UI 按钮，使其仅在正确的条件下处于活动/启用状态，从而为用户提供知道什么时候按下按钮是正确的或不正确的任务。

LaserGRBL 仅在知道按下按钮正确时才启用按钮，但它需要状态报告才能做到这一点。

如果上传 comlog.txt 还要上传 sessionlog.txt

我有同样的问题，我设法忍受它的方式是点击连接，等待超时等待 10 秒，点击连接并且它有效，如果你只是继续尝试连接它永远不会，直到你在两者之间等待一段时间第一次和第二次连接尝试，我看到后面没有人，我会做通讯日志和上传，谢谢

您好，附件是文件，希望这有助于将 lasergrbl 干净地连接到我的 Mega，
谢谢
comlog.txt
sessionlog.txt

你好@sinfocomp
正如我已经说过的，我无法测试您报告的问题，因为我没有 arduino mega 板。除其他事项外，很可能使用不同的卡不会出现问题。

但是，感谢您提交文件。

comlog.txt 记录了 LaserGRBL 和 grbl 之间的所有通信，它清楚地显示了发生了什么。第一列是 LaserGRBL 启动的时间（以毫秒为单位），第二列是递增计数器，第三列是动作类型（tx 数据或 rx 数据，或 com 端口动作，如打开、关闭等），第四列是数据（读取或写入） ).

• LaserGRBL 从 PC 端打开 com 端口。（第一行，启动后6.6s）
• 然后它发送实时命令 0x18 (ctrl-x) 应该会导致 grbl 重置自身并发送欢迎消息。（第二行）
• 然后它每 500 毫秒（状态报告查询）发送 0x3F 命令以鼓励 grbl 向他发送状态行。

他做了 10 秒的工作，但没有收到 grbl 的响应：没有欢迎消息，也没有状态报告，所以 10 秒后它关闭了连接（在第 22 行，启动后 16.6 秒，连接后 10 秒）。字符串“[CORE]”表明主动关闭com口是内部超时逻辑。

几秒钟后，您再次按下连接按钮，LaserGRBL 打开 com 端口（第 23 行，启动后第 28.5 秒）。LaserGRBL 做完全相同的事情（0x18，比开始每 500 毫秒发送 0x3F）但现在 grbl 正确反应发送欢迎消息（Grbl 1.1l [‘$’寻求帮助]\r @ 第 27 行）并在每次 LaserGRBL 发送 0x3F 时发送状态报告.

LaserGRBL 正确解析从 grbl 发送的状态报告并认为连接有效，并解析来自机器的空闲状态和位置信息。

在第 39 行，启动后的第 31.5 秒，您通过单击断开连接按钮 [USER] 关闭连接。

sessionlog.txt 确认所有信息

00006644	00000	com	Open COM17 @ 115200 baud Ctrl-X
00006704	00001	tx	[18]
00006712	00002	tx	[3F]
00007220	00003	tx	[3F]
00007716	00004	tx	[3F]
00008217	00005	tx	[3F]
00008718	00006	tx	[3F]
00009219	00007	tx	[3F]
00009716	00008	tx	[3F]
00010217	00009	tx	[3F]
00010718	00010	tx	[3F]
00011218	00011	tx	[3F]
00011720	00012	tx	[3F]
00012218	00013	tx	[3F]
00012718	00014	tx	[3F]
00013215	00015	tx	[3F]
00013717	00016	tx	[3F]
00014216	00017	tx	[3F]
00014719	00018	tx	[3F]
00015218	00019	tx	[3F]
00015716	00020	tx	[3F]
00016216	00021	tx	[3F]
00016635	00022	com	Close COM17 [CORE]
00028574	00023	com	Open COM17 @ 115200 baud Ctrl-X
00028589	00024	tx	[18]
00028593	00025	tx	[3F]
00028595	00026	rx	\r
00028597	00027	rx	Grbl 1.1l ['$' for help]\r
00028648	00028	rx	<Idle|WPos:0.000,0.000,0.000|Bf:35,255|FS:0,0|Pn:ZS|WCO:0.000,0.000,0.000>\r
00029116	00029	tx	[3F]
00029125	00030	rx	<Idle|WPos:0.000,0.000,0.000|Bf:35,255|FS:0,0|Pn:ZS|Ov:100,100,100>\r
00029614	00031	tx	[3F]
00029622	00032	rx	<Idle|WPos:0.000,0.000,0.000|Bf:35,255|FS:0,0|Pn:ZS>\r
00030116	00033	tx	[3F]
00030124	00034	rx	<Idle|WPos:0.000,0.000,0.000|Bf:35,255|FS:0,0|Pn:ZS>\r
00030613	00035	tx	[3F]
00030620	00036	rx	<Idle|WPos:0.000,0.000,0.000|Bf:35,255|FS:0,0|Pn:ZS>\r
00031113	00037	tx	[3F]
00031122	00038	rx	<Idle|WPos:0.000,0.000,0.000|Bf:35,255|FS:0,0|Pn:ZS>\r
00031591	00039	com	Close COM17 [USER]

所有这些让我说 LaserGRBL 确实做了正确通信应该做的事情。

我不知道为什么grbl在第一次连接后没有反应。
我是LaserGRBL的开发者，不是grbl的开发者。

在我看来，您应该将问题转发给 grbl-mega 固件的开发人员。

但很少有人问你。

• 您是否已尝试取消选中设置页面中的“软重置”？
• 您是否已尝试在同一页面中检查“硬重置”？
• 以及它们的所有组合？

让我知道

我看了 Grbl version 1.1l
你的固件是从哪里来的？

您好，感谢您的回复，是的，我尝试了所有软/硬重置组合同样的问题，最奇怪的部分是我尝试过的 UGS、蜡烛和其他 guis 都没有同样的问题，固件来自https:// github.com/fra589/grbl-Mega-5X会联系他看看会发生什么

如果你愿意，你可以转储（监视）UGS（和/或蜡烛）和你的板之间的通信会话，以及 LaserGRBL 和你的板之间的通信会话。

有一个软件可以为你做到这一点，叫做“串口监视器”。
https://www.eltima.com/products/serial-port-monitor/

下载、安装、选择菜单“session-new session”，选择要监听的com口，勾选除modbus以外的所有选项，开始监听。

然后打开 UGS，连接到电路板，做一些事情（比如发送一个简单的命令，如 G0 X10 Y10），最后断开连接。

回到串口监视器，选择“session – close session”，保存session，文件名为“UGS.spm”。

然后对 LaserGRBL 执行相同操作（但请使用此设置配置 LaserGRBL）。

然后压缩两个 .spm 文件（ugs.spm 和 lasergrbl.spm，如果您也想要蜡烛）并在此处上传 .zip 文件。

嗯，你的 Mega 固件似乎有点奇怪……我刚刚用我的 Mega 和 GRBL Mega 版本的新副本尝试了 LaserGRBL，它可以直接连接，没有问题。我认为它可能是一次性的，所以连接并重新连接了 10 次，它仍然可以。

不过，我使用的是 GRBL-Mega 1.1g – 也许是“I”版本导致的？我认为 1.1I 不是来自 GRBL，而是某个地方的修改版本？

那么我的 Mega 固件肯定也有一些奇怪的地方，因为一年以来我一直有同样的问题。
我使用 Mega GRBL 1.1f https://github.com/gnea/grbl-Mega/releases/tag/v1.1f.20170802
什么是 1.1g 版本，你从哪里得到的？
我找不到任何版本“g”。对于我的固件，“f”是最新版本。