Printer only connects with 46 input buffer

edited July 9 in Repetier-Server
I know that the most common input buffer is 63 or 127 bytes. But the only way I managed to connect my printer was with 46bytes.

I would like to know first what it may be due to. The printer board is a GT2560 V3. Could I be lacking memory?

On the other hand, if I leave it set to 46bytes, what problems could occur?

Thank you

Comments

  • If it really needs such a low value you better enable ping pong mode. It might mean that it can not handle more then one command in queue, also the official supported firmwares have no problem with this.

    What firmware are you running? The board can handle 63 or 127 bytes with no problems. If it can't it is because the firmware is not compiled to do so.

    What happens if you increase the value? Did you see some errors or did it not connect at all? Ok it would have connected but guess it disconnected after a short while not getting what was expected. But that size does not have influence on data transmission. It only limits the amount of data send before getting the "ok" from firmware.
  • First of all I thank you for the quick response. Much appreciated.

    If you put a value greater than 46bytes, it directly did not connect. It said to check the baudrate and the firmware.

    I am using Marlin 1.8.0.3. The printer is a clone of the Geeetech A10, and the firmware is customized by the vendor. Maybe they were wrong in the configuration of some parameters, but I can't identify what it can be.

    I attach a link with the files configuration.h and configuration_adv.h:
    https://we.tl/t-wl0UpKMiCt

    When I compile the firmware these are the memory values.
    Sketch uses 125564 bytes (49%) of program storage space. Maximum is 253952 bytes.
    Global variables use 5007 bytes (61%) of dynamic memory, leaving 3185 bytes for local variables. Maximum is 8192 bytes.
  • In configuration_adv.h you have

    // Host Receive Buffer Size
    // Without XON/XOFF flow control (see SERIAL_XON_XOFF below) 32 bytes should be enough.
    // To use flow control, set this buffer size to at least 1024 bytes.
    // :[0, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048]
    //#define RX_BUFFER_SIZE 1024

    So it is unclear how big the buffer gets selected. Make it
    #define RX_BUFFER_SIZE 128

    and it should work fine with 127 byte. Your config also can buffer up to 10 lines 96 byte so if firmware is fast enough it should be no problem anyway. But that requires fast update while the rx buffer is handled in interrupt, so that way you are safe.
  • Repetier said:
    In configuration_adv.h you have

    // Host Receive Buffer Size
    // Without XON/XOFF flow control (see SERIAL_XON_XOFF below) 32 bytes should be enough.
    // To use flow control, set this buffer size to at least 1024 bytes.
    // :[0, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048]
    //#define RX_BUFFER_SIZE 1024

    So it is unclear how big the buffer gets selected. Make it
    #define RX_BUFFER_SIZE 128

    and it should work fine with 127 byte. Your config also can buffer up to 10 lines 96 byte so if firmware is fast enough it should be no problem anyway. But that requires fast update while the rx buffer is handled in interrupt, so that way you are safe.
    I think I had already tried that, anyway I will try again.
    I wasn't sure if it was the TX or RX value that I had to configure. But I had tried both.

    Thanks again! If it doesn't work I'll post again.  :)
  • edited July 9
    So, I flashed the firmware with the option you told me:
    #define RX_BUFFER_SIZE 128

    Then I went to pronterface, connect to the printer and M502  M500 (is this ok?)

    Now I configure it with a buffer of 127 in repetier server. But the only way to connect is if I activate the option "ping-pong Mode". 

    Is this ping pong bad? this doesnt use a buffer right?



  • ping pong mode only sends one line and wait for "ok". That is not bad - that is what all other hosts do. It is just not as fast and will timeout on the first missed "ok". But if that fast sending causes for some reason problems it is not bad to use it. Only thing is that my other marlin printers have no problems with this.
Sign In or Register to comment.