Hard-coded timeout? "No valid response seen within 10 seconds from printer, restarting connection"

Hi there,

I have a fairly old printer - Felix 2.0 to be exact. I've recently revived it so I have more print capacity. Connected it to Repetier Server 0.9 successfully in an Ubuntu 20.04 LTS running on decent hardware (Mac Mini 2009). After upgrading to 1.0 however it stopped connecting successfully. Here's what's in server.log:

"No valid response seen within 10 seconds from printer, restarting connection"

So the root cause is that the printer board is taking longer than 10 seconds to start up and start responding. This happens to older boards. Very occasionally I was able to connect, because the printer board decided to respond quicker.

Is there any way I can change that timeout? Running "strings" on the RepetierServer binary, it seems that this message is hard-coded i.e. the "10 seconds" is hard coded. If this is really hard-coded, is there a workaround I can do in the <connectionCommands> tag in the firmware config under /usr/local/Repetier-Server/firmware to avoid this 10 second timeout check initially?

Yes, I know a good fix is to swap out the board, but I really don't want to rip out the printer again due to time limitations. I've already spent too much time rebuilding the print head. Besides it's probably good for the environment to reuse electronics, to reduce e-waste.

Thank you so much for your help!

Comments

  • Yes 10 seconds is hard coded, and no your printer is not taking longer - at least I doubt that. The 10 seconds was always there and I even prolonged some parts. First I hope you are on 1.0.2 where all known issues are fixed.

    Does the printer have an lcd and do you see it rebooting everying 10 seconds? Which firmware does it use? I know newer felix printers use repetier-firmware but older might have a different firmware. Anyhow it should start with "start" directly within a second and that is what we are waiting for and what prevents the timeout. If it is not resetting try changing RTS/DTR. On the old boards a switch triggered reset. So try high->low or low->high and see if it works with one of them. Make sure no other software is trying to connect to same port - that also causes problem. For example ModemManager often installed on linux tries to communicate when it sees a new serial port and makes server always fail at startup.
Sign In or Register to comment.