Random stops on a tcp/ip connected printer

edited January 2019 in Repetier-Server
I will try to give all possible data on my setup so that someone can make sense of it. 

When i print i get random stops while printing. like 0.2  - 2 second long (which result in blobs in the print).

Here is an example of a print log that does that: 

I see a ton of timeouts.
My best guess is always human error.. but maybe im wrong.
My setup is marlin deployed with my own setup of the Flsun delta printer setup from my branch of marlin where i store all my settings:
The board i am running is a MKS L gen 1.0

On that its aux port i have a 
ESP8266 CH340G
NodeMcu V3 Lua Wireless WIFI Module Connector ESP32 Development Board ESP12E Micro USB ESP8266 CP2102 Based L293D
With the latest  ESP3D sektch

I also have the latest raptier server installed on a 
Raspberry Pi Zero W/WH
RPi Zero WH Mini PC RPI 0 WH 1GHz CPU 512MB RAM with Bluetooth 4.1 wireless LAN 40PIN GPIO headers
It is a clean install on a blank OS:
Raspbian Stretch Lite 
Version:November 2018
Release date:2018-11-13
Kernel version:4.14

And the latest  Repetier-Server Free 0.90.7 - Poseidon-95  running.

Now the ESP3D is by default configured with 
in config.h
and the Marlin is running with 
in config_adv.h

in raptier i have tried to set the input buffer size to 16 and it stutterers every 1-3 seconds
With 512 every 10 seconds... lol..
ping pong is off and i tried timeout 1 and 3 seconds and even 30 no change....

I am on end with what to do.. pls help Q_Q.... 


  • N5697 M109 S200
    triggers the timeouts I see at the beginning. First your timeout is set to 2 seconds, which is too low. Your firmware uses busy protocol but you should add at least 1 second to the difference firmware uses for safety. You see once temperature is reached it resends and communication works again.

    Marlin surely has a maximum of 127 byte as input buffer.

    I haven't had time to check what this ESP3D exactly is supposed to do. But if you have pi zero w why not connect that directly to the printer. Each hub between sending and receiving is potential failure point.
  • i need the pi to be doing other things <span>:wink:</span>
    it has to earn its money. i cant have it always connected to the printer.
    Joke aside i need it to be always on to connect to it and the printer is not always on. 
    I tried the timeout on 6 seconds didnt change a thing.. 
    Il try to increase the 
    #define SERIAL_RX_BUFFER_SIZE 512
    to 1024 to see if that helps.
    ESP3d is a wifi tcp/pi interface to the printer it is connected to serial pins on the mks. 
  • > Joke aside i need it to be always on to connect to it and the printer is not always on. 

    Ok, but what is the connection? It is ok to disable printer connected to pi. Server will reconnect when you enable it or eventually power the printer board over usb also I'm not sure how much the zero can deliver here. A full pi would do it.
  • it seems the joke did n`t get trough :smile: which makes it a bad one :P 
    The pi is on a different part of the room for me to use it to control sometimes other stuff via the the io pins and to run simple mqtt server on it to admin my aquarium lights, pumps dosing and other stuff. The PI can handle it without problems. It did so from earlier to. The problem is only how to set up the Server to send data. 

    So to summarize: You are telling me to set the timeout to 3-4 seconds... Im only missing the buffer size.. it is a delta printer so the buffer is small... and when i set it to 127 i still get stutter.
    Soooo... what now?  
  • On delta use repetier-firmware:-) There buffer 16 gives more time then on marlin. Delta handling and transformation is done completely different normally giving much smoother moves and as planner can move over more segments less stuttering. Also communication is more effective with binary format which just needs 50% of data size compared to ascii. As long as the wifi is stable and fast enough you should have no problems. 

    In communication config in server make sure ping-pong is disabled. 127 byte is the limit of firmware. Since you have ESP3D in between I'm not sure if increasing this is good or not. If ESP3D throttles the amount on it's own you can increase to the limit of it, if it just passes is through the instance it gets it you need to limit to 127. Normally if buffer is set too high you get many resend requests, so it is easy to see if your value is too high.

    Do you also get timeouts during normal print? I mean your example was when it was waiting for M109 also that should have prevented timeouts anyway as it is in list of slow commands. But during normal print where commands are executed fast you should have no timeouts.
  • Ok for documentaion sake. i found out what was causing the hickups.

    The esp3d got compiled with Visual studio. That sucker installed his debugger lib. which clutered the uart output. 

    AND the es3d has to be correctly set with the XY feedrate Z feedrate and E feedrate mine was set to high tht cause the problems. 
Sign In or Register to comment.