Semaphore timeout period has expired
On a recent part I started getting a Semaphore timeout period has expired at the same point every time I tried to print the part.
Printer: Printrbot 1405 with revision D PrintrBoard
Hot End: E3D V6
OS: Windows 10
MatterControl version: 126.96.36.19967
The part itself is nothing fancy or complicated 140mm along the X axis, 83mm along the Y with the Z axis being 3mm in height and two 7.9mm round posts that are 7.3mm tall. Basically a protractor shape. When the print starts to lay down the skirt before the part it will generate the Semaphore timeout. Now I had this set to a slow print speed of 20mm sec with the Outside Perimeter speed set to 50%.
I redesigned the part many times, reinstalled the Teensy driver for the PrintrBot, ran the part through MeshMixer, NetFabb and still got the above mentioned error. After spending the bulk of an entire day on this I finally bumped the speed up to 50mm sec and the part printed without an issue. I do not use any other software for my prints as I love MatterControl and have it dialed in really well for my printer. This only seems to happen with parts that are above 110mm along the X axis and speed set to 20mm sec with the Outside Perimeter speed set to 50%.
Why would MatterControl generate this error at the slower speed? Is this something that can be fixed/changed?
unlimitedbacon last edited by
This sounds like a driver issue. Is there anything unusual about the way your are connecting to the printer? For instance, are you running it through a serial-bluetooth link?
Could you also check which driver you are using in the Windows Device Manager?
- Open Device Manager
- Find your printer, usually under the catagory "Ports (COM & LPT)"
- Right click and choose Properties
- Go to the Driver tab
- Post your driver provider, date, and version
If you are using a driver that was not provided by MatterHackers, that is probably the problem. Hit the Uninstall button and select the check box "Delete the driver software for this device." Then follow the instructions here to install the proper driver.
The driver being used was the one recommended by PrintrBot from here:
Uninstalled/Deleted that driver software and followed the instructions for manually installing the driver that is with MatterControl. Sweet, I now see PrintrBoard listed under Ports (COM & LPT). I change to my slow speed settings and the skirt stops at the same spot once again.
I'll chalk this up as being a PrintrBoard issue and not an issue with MatterControl at all. Granted my print area is 200mm x 200mm x 225mm as compared to the standard PrintrBot 100mm x 100mm x 100mm.
I think that it is time to just switch over to my RAMPS card that has been waiting to be used.
Thanks for your attention to this!
It may well be a MatterControl issue and not a PrintrBoard issue. Some fellow users at Printrbot Talk Forums have run at the speeds and sizes of the part I was printing (using Slic3r and Repetier and are not getting this to happen. One even slowed it down to the point it would take 24 hours to print the part and has no issues at all with it. You can see the full conversation here:
unlimitedbacon last edited by unlimitedbacon
The guys over on the Printrbot forum have been giving you good information. I also don't think that the print speed would make any difference. RetireeJay's explanation of the buffering is right on.
We've never seen this kind of error before, and all of our research indicates it is something happening on the USB driver level. Have you tried printing the same gcode using other host software, like Cura or Pronterface?
*Moves into corner and puts on dunce cap*
To bring this to a close. Just for fun I hooked up my PrintrBot to my desktop and had ZERO issues with printing the file at slow speeds. So it seems that my laptop is to blame for this issue. This was in no way related to MatterControl.
Glenn1963 last edited by
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?
unlimitedbacon last edited by
This issue has been taken care of. See this other thread.