评论
.jpg "Creater 打印机在打印中途停止问题 #451"){kind=avatar}
|
我没有在日志中看到任何错误。代码的设计使其可以在 FIFO 缓冲区中接收多条消息并进行处理。 我认为您的补丁只是以一种糟糕的方式对抗这种设计。我不确定您使用什么软件将 GCode 发送到 Creatr。但是 Cura 在它的 GCode 发送器中有大量的日志记录和错误案例捕获。我看到在带有 Cura 的 Ultimaker 上出现通信错误的唯一情况是 USB 连接本身出现故障。 |
.png "Creater 打印机在打印中途停止问题 #451"){kind=avatar}
|
戴德， 谢谢回复。关于补丁以糟糕的方式对抗设计，你是对的，我会说非常糟糕的 HACK。我正在使用最新版本的 Repetier。但我昨晚成功打印了一个 81 层的部件，我尝试打印至少 10 次，每次打印机都在打印中途停止。再次与打印机对话的唯一方法是断开连接并重新连接。 我会在没有补丁代码的情况下尝试您的 CURA，看看调试是否可以更好地定位我和其他人遇到的问题的根源，请参阅https://github.com/ErikZalm/Marlin/issues/436 谢谢 |
|
Daid，顺便说一句，看到垃圾字符处理“ok”消息是否正常，如下所示，它们也在日志中： &$?ok 我注意到有关日志的有趣之处在于，在打印调试消息后，我在字符串中搜索“ok”，但从未找到。这意味着它是从另一个例程发送的。我在代码中的每个“ok”前面都放了一条调试消息，如果没有调试消息，就会出现垃圾“ok”，所以除非代码是动态编写的，否则它不是代码。我怀疑这是与 USB COM 端口的通信协议，可能是 FTDI 问题（我正在运行 Windows 7 SP1 64 位，64GB 内存，Intel P6 @ 2700MHz 核心处理器，双 ATI Radeon HD 5700 和一些TB 的可用空间；所以我怀疑我的电脑有什么问题）。 实际上，当我输入上面的内容时，我突然想到问题可能与 6 核和多线程有关，这可能就是为什么有些人有问题而其他人没有的原因。 想法？ |
|
也许是 Repetier 或 Marlin 中的缓冲区溢出问题？ 我还没有在 Cura 上看到它，但 Cura 不会被这些琴弦窒息。串行消息将被损坏，这是众所周知的事实。所以你需要能够处理它。 我正在寻找 Cura 一行中的“ok”，不仅在开始时，而且在任何地方。这将有助于防止换行符被损坏。 |
.jpg "Creater 打印机在打印中途停止问题 #451"){kind=avatar}
|
串行消息不应该被破坏，因为 USB 传输层 闻起来像是某个地方的错误，可能是 USB 驱动程序、FTDI 驱动程序，或者 2013 年 4 月 16 日 18:21，daid notifications@github.com写道：
|
|
理论上它们不应该损坏，但在实践中我已经看到数据损坏发生，即使 USB->ATMega 线很短，它们也非常接近来自步进器的一些高发射线。 |
|
那么错误的PCB设计。如果您不能 2013 年 4 月 16 日 18:51，daid notifications@github.com写道：
|
|
感谢您的回复，USB 电缆长 4 英尺，带有铁氧体，距离最近的步进驱动器约 1 英寸。我试过 3 个 MEGA 板，结果都一样，我用 CURA 打印了测试模型，没有问题。我现在正在打印多次失败的模型。到目前为止，我在日志中看到了两个 ok�ok，还有 6 个小时，特殊字符是一个底部填充的菱形，换句话说，它是一个带有 ? 的深色菱形。 好消息，CURA 并没有像 Repetier 0.85b 那样在这方面卡住，所以 Repetier 处理串行错误的方式可能存在问题。 |
.jpg "Creater 打印机在打印中途停止问题 #451"){kind=avatar}
|
我想知道 AUX-1 是否是较新的 RAMPS 上的问题。TX 和 达斯汀 在 2013 年 4 月 16 日下午 01:50，DavidH137 写道：
|
|
Dustin，好主意，但我重新布线，因此根据 Creatr 论坛中指出这可能是个问题的帖子，电机线和步进驱动器的线都至少分开 10 厘米。我什至将连接到打印头的加热线、温度线和电机线分开。 你是对的，步进线靠近 Mega 上的电源线，但这些我也移动了 10 厘米远。剪断D0和D1是什么意思？ |
|
我的意思是 RAMPS1.3/1.4 本身的缺陷或设计薄弱，如果那是 在 2013 年 4 月 16 日下午 02:27，DavidH137 写道：
|
|
正如我所说，我特别注意 Cura 中的 USB 串行通信。我使用了 Pronterface 中的大部分技巧并添加了一些增强功能。固件可能有问题，但我认为主机软件应该能够处理尽可能多的问题。 改进所有领域是好的恕我直言。因此，如果 Marlin 代码中某处存在错误，请找到并修复它。但是解决该错误的方法并不是真正的解决方案（当我看到对时间敏感的固件代码出现“延迟”时，我有点哭了）。同时主机软件应尽可能多地处理。 |
.png "Creater 打印机在打印中途停止问题 #451"){kind=avatar}
|
It might be Marlin. I’ve had the same issue with Pronterface for some time, and finally switched to SD card printing exclusively, which doesn’t exhibit the issue. I feel like it could be a latency/timing problem. Notice the difference when printing circles and other groups of many small moves. It is choppier via USB than via SD. I don’t think it’s my RAMPS hardware, but there is some buzz that USB can get flaky if there’s too much EM noise. |
|
I didn’t want to say it but: I love this hack. I was struggeling with Marlins terrible serial comms ever since I installed it. I used Sprinter before, and never had any comm issues. EDIT: comms still seem to ‘hang’ pretty much all the time With this fix, I can connect and issue commands just fine, from there, the SD takes over so the delays don’t really bother me (i’m on 9600 Baud). Thanks so much for the fix, there certainly must be done something to improve comms on Marlin. I’m quite sure it’s not the USB. DFTBA. |
.png "Creater 打印机在打印中途停止问题 #451"){kind=avatar}
|
The marlin serial functions are almost the same as the sprinter serial functions. I think you changed more then only Marlin to Sprinter. |
如果打印机只是在打印中途停止，我无法使用此 Marlin 代码创建大型打印件。计算机没有挂起，但打印作业已损坏。
我修补了代码（在调试后描述）并且很想更好地理解为什么这个修复会解决停止问题。（它在 process_command 结束时序列化了 get_command 处理）。
我做了一些调试，如下所述，发现：
当打印停止时，发现以下是常见问题。这些
字符（或它们的变体）在日志中：
&$? ok
?
ok
我以前看到过一些“ok”消息，但大多数时候我没有看到“ok”消息，所以我插入了一些代码，在打印过程中捕获每一站，并且每一站都有“ok”消息。要调试，请执行以下操作：
在模块 Marlin_main.cpp 中插入以下内容并重新加载固件：
void process_commands()
{
unsigned long codenum; //丢弃变量
char *starpos = NULL;
// 在 char 语句上方插入调试代码
SERIAL_ECHO_START;
SERIAL_ECHOPGM(“命令：”);
SERIAL_ECHO(cmdbuffer[bufindr]);
SERIAL_ECHO(”最后一个 N:”);
SERIAL_ECHOLNPGM(“”);
// 结束调试代码
这将导致在停止之前日志中出现如下消息：
20:21:11.302 : N814 G1 X29.251 Y1.984 E2563.721 *64
20:21:11.305 : echo:Command:N813 G1 X156.142 Y128.875 E2552.526 *125813″
20:21:16.652 : N815 G1 X30.036 Y1.985 E2563.77 *127
20:21:16.684 : echo:Command:N814 G1 X29.251 Y1.984 E2563.721 *64814″ ok
20:21:16.688 : echo:Command:N815 G1 X30 .036 Y1.985 E2563.77 *127815″
18:26:08.799：回声：命令：N311 G1 X23.858 Y200.94 E135.052 *74311″
18:26:08.828：N313 G1 X51.72 Y228.016 E137.5592 *115
18:26:09.713：回声：命令：N312 G1 X23.858 Y200.154 E135.1011 *6631&$?ok
18:26:09.717 ：回声：命令：N313 G1 X51.72 Y228.016 E137.5592 *115313″
16:44:52.400: N1196 G1 X32.757 Y1.459 E5.05497 *74
16:44:52.510: echo:Command:N1195 G1 X23.333 Y10.882 E4.47453 *122LLNM$?ok
16:44:52.514 ：回声：命令：N1196 G1 X32.757 Y1.459 E5.05497 *741196“
16：45：41.100：N1197 M105 * 57
16：45：41.106：回声：命令：N1197 M105 * 571197“
16：45：41.114：回声：退出M105
16：45：41.115：N1198 G1 X33.58 Y1.459 E5.09082 * 113
16：45：41.126：回声：命令：N1198 G1 X33.58 Y1.459 E5.09082 * 1131198“
您会注意到命令回显的顺序与命令的正常日志不一致。我发现这是解决问题的关键。我发现 Marlin 代码在处理缓冲区以确保在下一行 gcode 发送到打印机之前执行每一行 gcode 方面存在问题。
我想出了一个修复方法，如下所述。
此补丁的目的是使 Marlin 代码一次处理一个命令，并且在前一个命令完成之前不继续处理另一个命令。我不确定为什么这会起作用，因为 Arduino 板应该只按顺序处理代码（我认为），但它对我有用。我怀疑它修复了缓冲区填充打印命令的方式中的一个错误，该错误导致将“ok”乱码消息发送到打印机，从而导致代码停止。
在#includes 之后的 Marlin_main.cpp 中放置以下语句：
布尔 tnext = 0;
同一个模块在第一个 {（左括号）之后在 void setup() 中添加一行，如下所示
void setup()
{
tnext=0;
同一模块在 void get_command() 中的第一个 { 之后添加以下内容
while (tnext != 0) {
延迟(1);
}
这会导致 get_command 循环，直到处理完上一个命令。
在同一模块 void process_commands() 中执行以下操作：
在第一个 { 之后输入以下行：
tnext = -1;
在每次“返回”之前；在每次“休息”之前；输入一行：
tnext=0;
如果您错过了一个“tnext=0”，代码将不会被设置为允许 get_command() 中的循环结束。
在同一模块中，在 void ClearToSend() 中的 }（结束括号）之前添加以下内容
tnext=0;