Connection problem

Hi,
I've started using repetier-server on my raspberry Pi 3B+. But I've had some problems. At the beginning the installation and the managineg of settings has been ok. But when I've started the first print, the printer went too slow (one command every 30 seconds more or less). And after that I'm not able to connect to my modem paga (192.168.1.1) and even to the repetier-server page to control the raspberry.
What could be the problem?

Thanks

Comments

  • First connect using ethernet cable. That solves any wifi problems that might slow down communication in case it was slow. Don't forget you get a new ip for ethernet connection while wifi ip still exists! Click on home in server and you see at the bottom the ips for eth0 and wifi.

    Go to console to check on communication. 1 command every 30 seconds sounds like you get a timeout which happens when you get no response. If you see messages from printer baud rate is normally ok or very close by. But it might be that firmware does not send anything (enable ack to see all responses from firmware). Sometimes RTS/DTR switch in printer settings->connection need to be high or low so firmware sends something. Try all 4 combinations and see if it gets better. Also make sure right firmware is selected. Repetier-Firmware on marlin will not work and show similar problems.

    Your descriptions sounded like there are 2 problems at once so hope these 2 ideas help at first to get it running. Then we can check closer when communication with printer is working good.

  • Sorry, maybe I wrote too fast and forgot some details. I'm just using the ethernet cable for the raspberry. Anyway now on my pc I'm not able anymore to access to the modem page...
    The printer is an Alfawise U30 Pro.
    I've checked with ACK enabled and I had no errors of timeout connection, about this I could try what you say in your answer.
    First thing now I want to solve is the access to the modem page... I've tried reboot and reset the modem, but nothing change.
    Another thing is that now I'm not able to access the page of repetier server too (in my case is 192.168.1.196)
  • I apologize for the second postof answer, anyway I want to tell you that I've solved the internet "issues" on the computer, I've made a reset for the internet settings and now it works again! <span>:smile:</span>
    I'll let you know about the printing. Thanks for your kindness! :)
  • I still have problems, I've tried to switch RTS and DTR but same issue... There are moments that the print works fine but between these moments there are some breaks, as you can see in this piece of log:

    14:37:19.470: N1114 G1 X111.392 Y101.039 E224.12210
    14:37:19.676: ok
    14:37:19.676: N1115 G1 X111.392 Y100.632 F7800.000
    14:37:19.677: N1116 G1 F2400
    14:37:19.715: ok
    14:37:19.715: N1117 G1 X119.368 Y100.632 E224.39208
    14:37:19.790: ok
    14:37:19.790: N1118 G1 X119.368 Y119.368 E225.02627
    14:37:20.205: ok (2)
    14:37:20.205: N1119 G1 X100.632 Y119.368 E225.66045
    14:37:25.511: M117 Layer 11/99
    14:37:25.515: ok
    14:37:25.516: N1120 G1 X100.632 Y100.632 E226.29464
    14:37:25.529: ok
    14:37:25.529: N1121 G1 X111.332 Y100.632 E226.65681
    14:37:25.542: ok
    14:37:56.539: Warning: Communication timeout - resetting communication buffer.
    14:37:56.539: Connection status: Buffered:82, Manual Commands: 1, Job Commands: 5000
    14:37:56.539: Buffer used:82 Enforced free byte:24 lines stored:2
    14:37:56.539: M117 ETA 15:02:58 day 2
    14:37:56.539: N1122 G1 X111.332 Y100.225 F7800.000
    14:37:56.540: N1123 G1 F1200
    14:37:56.562: ok
    14:37:56.563: N1124 G1 X119.775 Y100.225 E226.94260
    14:37:56.566: ok (2)
    14:37:56.566: N1125 G1 X119.775 Y119.775 E227.60435
    14:37:56.574: ok
    14:37:56.574: N1126 G1 X100.225 Y119.775 E228.26609
    14:37:56.582: ok
    14:37:56.582: N1127 G1 X100.225 Y100.225 E228.92784
    14:37:56.590: ok
    14:37:56.590: N1128 G1 X111.272 Y100.225 E229.30176
    14:37:56.606: ok ok
    14:37:56.607: N1129 G1 X111.639 Y100.481 F7800.000
    14:37:56.618: ok


    What could it be?
  • As you get "ok" back, the rts/dtr settings are ok. Your problem arises if firmware sends an "ok" and server does not receive it, e.g. due to communication errors. Sooner or later that causes a timeout where server assumes that just that problem happened and continues. On of these examples you see here:
    14:37:56.606: ok ok
    There the newline was missing so server only sees one "ok" and one command is blocking space in buffer from there on. When all bytes of buffer are occupied from such com errors you get the next timeout and it continues.

    What does M115 return? If it supports busy protocol you can reduce timeout to 3 seconds making it react a lot faster. There are also other things firmware could do to help detecting such errors more quickly or even on the fly like
    - Adding line number to ok
    - Sending wait when all commands are executed.

    But that requires recompilation of the firmware with the settings activated and uploading the new firmware.

    Are you sure baud rate is correct. e.g. 230400 works also with 250000 baud but would have a lot more errors in communication. Vice versa same problem.
  • Firstly I've tried to set timeout to 0,1 seconds, it reacts fast but the commands get slow for a while, ruining the printing.
    Another thing I've tried to do is to enable PingPong mode and set timeout to 0,1 seconds, doing this it looks like is working really fine but I want to ask you if it's a good idea.
    My BAUD at the moment is set to 115200 and is the same I have on Marlin firmware. I've tried to set it at 250000 but my Alfawise screen doesnt work anymore with that value, so I prefer to leave the original one.
    About the 2 things you've said to recompile the firmware I have no idea about how to do that, if you can give a more detailed explanation would be great :) (about this I know how to use arduino IDE to recompile, but I dont know where to change the code).
    The following is the result of M115, does it support busy protocol?:

    19:09:06.856: FIRMWARE_NAME:Marlin 1.1.9 (Github) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:3D Printer EXTRUDER_COUNT:1 UUID:I've deleted before publish ;)
    19:09:06.856: Cap:SERIAL_XON_XOFF:0
    19:09:06.859: Cap:EEPROM:1
    19:09:06.859: Cap:VOLUMETRIC:1
    19:09:06.861: Cap:AUTOREPORT_TEMP:1
    19:09:06.861: Cap:PROGRESS:0
    19:09:06.864: Cap:PRINT_JOB:1
    19:09:06.864: Cap:AUTOLEVEL:1
    19:09:06.866: Cap:Z_PROBE:1
    19:09:06.866: Cap:LEVELING_DATA:1
    19:09:06.870: Cap:BUILD_PERCENT:0
    19:09:06.872: Cap:SOFTWARE_POWER:0
    19:09:06.872: Cap:TOGGLE_LIGHTS:0
    19:09:06.876: Cap:CASE_LIGHT_BRIGHTNESS:0
    19:09:06.879: Cap:EMERGENCY_PARSER:1
    19:09:06.881: Cap:AUTOREPORT_SD_STATUS:0
    19:09:06.884: Cap:THERMAL_PROTECTION:1
  • You don't have busy support compiled in as it looks. So timeout 0.1s is bad idea. Every time a command that is not known to be slow takes more it will assume a missed ok which will cause frequent communication errors that will get fixed, but I don't think that would be that good.

    If you have the firmware sources for your printer it is easy to fix firmware. Otherwise you need to find out configuration and that requires experience. So assuming you have a source, all you need is open config_adv.c and search for the options. Not sure how they are named exactly but you see it from comments containing wait / ok line number and busy for the 3 options that were programmed in marlin to help here. So enable them recompile and upload. Then you can set timeout to 3 seconds.
  • I understand what you're saying, but I don't manage to find the correct lines in my firmware to fix. I'm really sorry but I need a lot of help xD. The lines I've found are these, is it correct?

    // Bad Serial-connections can miss a received command by sending an 'ok'
    // Therefore some clients abort after 30 seconds in a timeout.
    // Some other clients start sending commands while receiving a 'wait'.
    // This "wait" is only sent when the buffer is empty. 1 second is a good value here.
    //#define NO_TIMEOUTS 1000 // Milliseconds

    // Some clients will have this feature soon. This could make the NO_TIMEOUTS unnecessary.
    //#define ADVANCED_OK

  • I've also this lines:

    // Host Keepalive
    //
    // When enabled Marlin will send a busy status message to the host
    // every couple of seconds when it can't accept commands.
    //
    #define HOST_KEEPALIVE_FEATURE        // Disable this if your host doesn't like keepalive messages
    #define DEFAULT_KEEPALIVE_INTERVAL 2  // Number of seconds between "busy" messages. Set with M113.
    #define BUSY_WHILE_HEATING            // Some hosts require "busy" messages even during heating
  • Yes you need
    #define NO_TIMEOUTS 1000 // Milliseconds
    #define ADVANCED_OK

    and the busy lines you found are already correct in your example.
  • wow it works!!! Thanks a lot for help!!! :) I have learned and understood a lot of things thanks to you ;)

    Now just let me satisfy my curiosity... do you know if Octoprint uses "Ping-Pong" mode for firmware/host communication? Because I've tried that and it still gives me problems... (I ask it as a user of Repetier-Server Pro, so I'm not doing any competition)
  • Yes, as far as I know Octoprint uses what we call ping-pong mode. No parallel sending of lines. But that is required to detect missing ok on the fly. Otherwise you need to wait for timeout or wait depending on what comes first to detect it.
Sign In or Register to comment.