Error: Too many consecutive timeouts

Are you sure you didn't forget to change some old start gcode?
Check the gcode file you wanted to print for M190 S80 - that's the gcode for raising bed temperature to 80Β°C

I found this:

2019-12-07 07:19:15,406 - Send: N0 M110 N0*125
2019-12-07 07:19:15,421 - Recv: enterStopPrint:"0ok N0 P15 B3
2019-12-07 07:19:45,450 - Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.

Curiously the same happens at 14:53/14:54 at the same point of the procedure.
Already tried the "Tape over 5V" thing I mentioned above?

I didn't try to start a new print, just wanted to heat bed so I could remove my old print.

Well at least octoprint thought you want to print

2019-12-07 07:20:48,777 - Changing monitoring state from "Starting" to "Printing"
2019-12-07 07:20:48,786 - Send: N2 T0*56
2019-12-07 07:20:48,791 - Recv: echo:Active Extruder: 0
2019-12-07 07:20:48,793 - Recv: ok N2 P15 B3
2019-12-07 07:20:48,795 - Send: N3 M190 S80*83

Could you try another browser?

Where do you get 14:53/14:54 from? I don't follow.
And just to be clear, the only commands I gave was to set bed temp at 40Β° (or maybe 38, 43... can't remember exactly) If the log suggests I did something more it wasn't me.

I appreciate a lot that you look at the logs!

No, I haven't taped over the 5V pin, Guess that is the next thing for me to try.

Story of my life :smiley:

Sure, can try another browser but it seems a bit far fetched? Any particular reason if I may ask?

I just want to make sure that there is no weird cache problem or some kind of plugin doing odd stuff

1 Like

Ahh, Ok I see. Good point!

From your octoprint.log.
This issue happens just after Changing monitoring state from "Connecting" to "Operational"
I have the same printer here too. I've modified a USB cable and disconnected the 5V wire. It runs more secure because the printer draws current from the 5V rail of the USB.
That can make issues with the USB of the Pi.

In detail: instead

M110 N0*125

the printer received this:

"0ok N0 P15 B3

And that is no good.

2 Likes

Thank you so much for checking and comparing logs!

Well, it's settled, the 5V pin has to go :slight_smile:

Did you have problems as well with your T-Rex then I assume?

Not in that way, but when the Pi with OctoPrint was connected to off powered printer, the display was still lit and I got the under voltage issue message in OctoPrint.

Else the the printer runs fine. I only hat to adjust the nozzle height of the right extruder, it was a bit too high.

I'm generally happy but I cant fine tune that last little thing to satisfy me. It seems to me that it cant handle retractions very well, or it's just my slicer settings...

Have you tried the latest Marlin FW?
I want to try but I'm unsure of how to do it. I have downloaded arduino and try to read as much as I can on how the configuration shall be.

Here is the marlin example config for the Trex 3

2 Likes

Nice! :handshake:

1 Like

I'm thinking about to install it.

The 5V pin is in the trash, literally.

Thanks again and hopefully this will be the end if this.

/Micke

1 Like

Just thought I would share my situation. I updated from the Creality firmware to the Marlin 2.0.X bug fixes branch, and immediately started getting the communication connection issue. Tried all of the published suggestions...remove extensions, handshake setting in octoprint, new Pi, reflashed to new SD...nothing worked. Rolled back to the 2.0.7 release of Marlin, and the communication issue was gone.

This link will MAKE YOUR DAY!

1 Like

iTS SO EASY you'll be pissed you went through HOURS of BULLSHi77777

1 Like