Random stops on a tcp/ip connected printer

Comments

• Repetier

  January 2019

  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.
• sangoku

  January 2019

  i need the pi to be doing other things <span></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. 
• Repetier

  January 2019

  > 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.
• sangoku

  January 2019

  it seems the joke did n`t get trough 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?  
• Repetier

  January 2019

  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.
• sangoku

  February 2019

  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.