MatterControl communication timeout setting?
PWBarrett last edited by
I'm having exactly the same problem described by Glen1963 below.
I don't suppose there's anywhere to set a longer communication timeout? As it is, I have to comment-out the G29 command in the Start-GCode section.
Since this was the only thread I could find mentioning this error, I hope you don't mind me reviving it a bit.
I too am getting this error on my Printrbot Simple Rev D, but only in a specific situation that I created and can easily avoid. Still, I am wondering if there's something I can do.
I compiled my firmware to allow for 9 points of advanced probe leveling. If I have Start G-Code that calls G28 (home all) then G29 (Z-probe), hit Print, MC throws the semaphore error and disconnects after the G29 completes, when the printing should start.
If I call G28 and G29 manually, then click Print, the problem doesn't occur. So is it that MC has issued the next series of commands after issuing the G29, and my printer took too long to respond? Is there something I could do to test that theory or prevent it?
If I change to 4 points of leveling (really, should be sufficient), the problem doesn't occur, so I assume it is related to how long the G29 takes.
So, this is not a serious problem for me, but I am curious to know if there is a possible solution. Is it something that could be altered in the MC code if I went there?
ryan.lutz last edited by
Is this a Windows error or does the error occur in MatterControl?
Can you email us (firstname.lastname@example.org) a print log that shows what happens in the G-Code Terminal when the timeout occurs? http://wiki.mattercontrol.com/Send_Debugging_Information#Print_Log_.2F_Terminal_Log
MatterControl should wait indefinitely after sending any command to the printer, so there's a chance that the issue is related to drivers and not the program itself.
We did some more investigation with one of our own Printrbots and were able to track down the problem. The issue will be fixed in the next version of MatterControl, or you can get it now by downloading an experimental release.
Here is what was going wrong. While the printer was busy doing the G29 command, MatterControl would keep sending commands repeatedly because it didn't get a response yet. After a while, the serial buffer would fill up with all the unprocessed commands, blocking MatterControl from sending any more. The serial driver would throw an IO error. MatterControl was interpreting every IO error as a disconnection, when in fact that is not the case.
Now MatterControl only disconnects if there is an error while reading from the serial port. If there is an error while writing (due to the buffer being full) MatterControl will print a message to the terminal and continue trying to print. This also takes care of the semaphore timeout issue mentioned in the other thread.
MatterControl will also now print more information to the terminal whenever a disconnection happens for any reason.