Serial comunication error (but work fine with Repetier Host)

edited September 2018 in Bug Reports
Hi Roland, just see the video, with the latest Windows Server there's a lot of problem with the serial port...

Marco


Comments

  • Ok, on first sight it looks the same just failing in server version. Is this a new phenomen for the server or the first try you use server with that printer?

    What board das the kossel use? If it is a malayan board try RTS High, DTR Low.

    Also please have a look at server.log in C:/ProgramData/Repetier-Server/logs and see if it contains some informations about the close reason.
  • 2018-09-27 18:22:13: Connection started: Kossel MAX
    2018-09-27 18:22:13: Reset printer Kossel MAX
    2018-09-27 18:22:19: Port closed for kossel_MAX
    2018-09-27 18:22:19: Connection closed: Kossel MAX
    2018-09-27 18:22:51: Connection started: Kossel MAX
    2018-09-27 18:22:51: Reset printer Kossel MAX
    2018-09-27 18:22:57: Port closed for kossel_MAX
    2018-09-27 18:22:57: Connection closed: Kossel MAX
    2018-09-27 18:23:57: Connection started: Kossel MAX
    2018-09-27 18:23:57: Reset printer Kossel MAX
    2018-09-27 18:24:03: Port closed for kossel_MAX
    2018-09-27 18:24:03: Connection closed: Kossel MAX
  • In this situation if i  manually restart the Repetier Server service the printer goes online...
  • edited September 2018
    I've found the problem, the printer goes offline when i push the emergency button on Repetier Host, connected to the Server.
    After this i need to restart the server service.
  • This is happening to me on repetierposerver 90.7 with the latest Marlin Firmware on all 5 of my CR10-S printers. I have 2 Rapsberry-Pi 3B+ that are experiencing the EXACT same problem where anytime a print job is Stopped or Emergency Halted you have to reboot the Repetier-Server to get the printers ACTIVE again.  The printers default goto DEACTIVATED and no matter what setting you use, no matter what port you switch them to, no matter how many times you can unplug/plug in the printer the ONLY solution is to reboot the Pi3b+.

    I'm so glad I'm not the only one experiencing this problem and has only occured in 90.7. Previous version I did not have this problem.

    What can we do?
  • I'm not really aware of a change in connection. What is new since 0.90.0 is that you can select how RTS/DTR is toggled, but default value is low to high like in host as well. So boards that require special settings of the state e.g. when used for hardwrae flow control they may not work with all combinations. E.g. I heard that the new Malayan baords need RTS high and DTS low. What board is used in your printer? Can you try if changing RTS/DTR gives a always connecting combination?
  • I use DUE board (RuRamps4D V1.3).
  • I'm using a Creality CR-10S which uses an Atmel 2560) running the latest Marlin Firmware.    

    Do we need to set RTS/DTR to be HIGH/HIGH or LOW/LOW?

  • Creality CR-10S uses a FTDI chip for communication (or a fake clone who knows). RuRamps4D no idea what they use as serial communication chip. Just tested with a read due and it could reconnect/disable/enable at any time. But they also use DTR only to create a reset on toggle and ignore RTS completely. So they do not implement any type of flow hardware control.

    Now since it sometimes works and sometimes not the assumption is that changing the pin states can block communication in the one or other direction. There is no standard for serial pin usages just ways often used.

    So fact is you might need one of the combination high/high, high/low, /low/low or low/high. Only tests can say if that helps to connect at any time. I do not really see a difference between connecting on start or later connect except that on the very first connection test we haven't touched RTS/DTR which is done after port is opened. So what we try is set them to the same mode as on first connect as it seems to work. So hopefully one of the 4 combinations make it work reliable.
  • Did you try starting a print job on the CR10S with the latest marlin firmware, then hitting the EMERGENCY STOP button? This is the part that causes the CR10S to go into being unable to be communicated with.
  • edited October 2018
    Just had this bug happen again with a printer that was working flawlessly now it's doing the same OFFLINE status after I hit emergency stop.

    I tried all 4 variations of HIGH/LOW in either option.  LOW/HIGH would get me a constant reboot cycle where the printer would consistently reboot  itself. 

    What version of Marlin are you testing the software with?

    At this rate I will have to roll back to an early version of Repetier that doesn't have this problem.  Is there a link to older versions of .90?  Looking for V8 as that was the one that is based off RP3B+ which is what I am using.


    finally, where can i find a log of the printer's connection errors?  Where does Repetier store logs of connections on the filesystem? 

    This may be useful for troubleshooting. This could be related to the RP3B+ as I had RP3B and didn't have this problem. 


  • Connections are logged in logs/server.log in storage directory.

    For older versions just replace the version number in download link:-)

    I do not think that 3B+ and 3B will behave different.

    Also firmware should not depend on it working or not. After a reset it will start again and send "start". What we do on emergency stop is send M112 and then toggle DTR/RTS also with fixed setting nothing will toggle, so only M112 will be send. If that stops firmware and does not reset firmware you will in deed have no more communication until you hit the reset button of the printer.

    Can you test what simply sending M112 does to the connection? Best while in console. 

    What Marlin version do you use? I normally test on repetier-firmware as my printers use it. I also have a Prusa with Marlin which I can test.
  • I am using marlin 1.1.9.  

    I'll try sending the M112 in the console when the printer is printing.  

    The only way I have been able to fix this problem is to reset the Repetier-Server on the RP3B+ itself. Resetting the printer does nothing, removing the USB power and power from the printer and plugging back in does nothing.  The only way that the printer is able to communicate with Repetier again is by rebooting the entire RP3B+.  This is not optimal as I have 3 Printers on Repetier running jobs and if one fails Emergency Stop stops all print jobs. I can't have that happen as that's wasted time and material especially on long prints.

  • That seems a very penetrant problem then. Normally reset, unplug or disable work on all printers I have. If new connection does not reset unplug + reset should do the trick.

    What is if you are in console and press the reset button on the printer. This is technically no reconnect. All that would happen normally is that you see in console "start" and firmware starts again but server detects it. So would be same result as emergency stop but would expect connection to still work.

    What is if you insetad of rebooting the pi only restart the server
    sudo service RepetierServer restart

    does that also help reconnecting? I think of another occation where another software was using the port. As a test you can do

    pi@FelixPi:~ $ sudo fuser /dev/ttyACM0 

    /dev/ttyACM0:        16104

    pi@FelixPi:~ $ ps aux | grep 16104

    repetie+ 16104  6.3  2.0 303448 19568 ?        S<sl 16:31   0:33 /usr/local/Repetier-Server/bin/RepetierServer -c /usr/local/Repetier-Server/etc/RepetierServer.xml --daemon

    pi       17599  0.0  0.2   4272  2012 pts/0    S+   16:40   0:00 grep --color=auto 16104

    Here my printer is on /dev/ttyACM0 and fuser tells me process 16104 is using the port. I have for example teh problem that when klipper is running on my pi it tries to use the port as well preventing server from connection. So on reboot server might just be first to connect so it works and later on the other software breaks it. Just an idea also I think not really that it is the problem. Then you would see server trying to connect over and over again.
  • The steps i'll do tonite is as follows:

    1. Restart the Repetier service on the inoperable Pi, see if this works.
    2. Start a print job, send the M112 code to the printer while printing. see what happens there.
    3. check the logs and examine the ports in question to see if the service is still trying to use the port after M112 is called or Emergency Stop.

    I will be doing this on a Raspberry Pi 3B+ with 2 CR10S' attached with Marlin 1.1.9 firmware and version 90.7 of Repetier. 

    Will report my findings
  • edited October 2018
    1. Restarting the service reconnects the printer but does kill all jobs running. Not ideal.

    2. I performed M112 on the console while printing. Printer restarted, firmware restarted. Connnection did NOT come back.

    Here is the part from the log file:

    >  2:12:58.910: Error:Printer halted. kill() called!
    >  2:12:59.028: start
    >  2:12:59.028: echo: External Reset
    >  2:12:59.028: Marlin TH3D U1.R2.2
    >  2:12:59.028: echo: Last Updated:  | Author: (TH3D)
    >  2:12:59.028: echo:Compiled: Sep 25 2018
    >  2:12:59.028: echo: Free Memory: 3367  PlannerBufferBytes: 1232
    >  2:12:59.028: echo:EEPROM version mismatch (EEPROM=V47 Marlin=V55)
    >  2:12:59.028: echo:Hardcoded Default Settings Loaded
    <  2:12:59.028: M117 Finished

    What in the name of the world is this? Why would my EEPROM be mismatched here? What could cause this?


    3. Ran fuser command and there was nothing running on that port:

    pi@CR10S-RS1:~ $ fuser /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1071DZ7-if00-port0
    pi@CR10S-RS1:~ $


    Not sure what is the issue here, could be the EEPROM mismatch, but then why would the printer work when server/service restarts and not after emergency stop? Is there something checking in repetier that is not accepting the firmware/eeprom? 
  • edited October 2018
    I found I didn't save my EEPROM. I fixed that by running a M502 and then M500. Saved my EEPROM, started a new print job. 

    I then did an emergency stop and the problem repeated itself: Once the firmware was restarted the printer was not seen by Repetier at all. No reconnection was found, could not activate, Repetier had to be reset in order to start printing again.


    Here's some of the log of the job:

    max_e_jerk>
    >  3:03:45.722: echo:  M205 B25000 S0.00 T0.00 X10.00 Y10.00 Z0.40 E5.00
    >  3:03:45.723: echo:Home offset:
    >  3:03:45.723: echo:  M206 X0.00 Y0.00 Z0.00
    >  3:03:45.723: echo:Material heatup parameters:
    >  3:03:45.723: echo:  M145 S0 H200 B60 F0
    >  3:03:45.723: echo:  M145 S1 H240 B100 F0
    >  3:03:45.723: echo:PID settings:
    >  3:03:45.723: echo:  M301 P22.20 I1.08 D114.00
    >  3:03:45.723: echo:  M304 P690.34 I111.47 D1068.83
    >  3:03:45.723: echo:Filament load/unload lengths:
    >  3:03:45.723: echo:  M603 L0.00 U100.00
    >  3:03:49.647: Warning: Communication timeout - resetting communication buffer.
    >  3:03:49.647: Connection status: Buffered:11, Manual Commands: 10, Job Commands: 0
    >  3:03:49.647: Buffer used:11 Enforced free byte:0 lines stored:1
    <  3:03:49.647: N1 M110
    >  3:03:50.308: Firmware was halted, trying to reconnect. Eventually running print is stopped.
    >  3:03:51.320: Error:Printer halted. kill() called!
    >  3:03:51.395: start
    <  3:03:51.395: M117 Finished
    >  3:03:51.422: echo: External Reset
    >  3:03:51.423: Marlin TH3D U1.R2.2
    >  3:03:51.423: echo: Last Updated:  | Author: (TH3D)
    >  3:03:51.423: echo:Compiled: Sep 25 2018
    >  3:03:51.423: echo: Free Memory: 3367  PlannerBufferBytes: 1232
    >  3:03:51.467: echo:V55 stored settings retrieved (655 bytes; crc 32826)
    >  3:03:51.467: echo:  G21    ; (mm)
    >  3:03:51.468: echo:  M149 C ; Units in Celsius
    >  3:03:51.468: echo:Steps per unit:
    >  3:03:51.468: echo:  M92 X80.00 Y80.00 Z400.00 E93.00
    >  3:03:51.468: echo:Maximum feedrates (units/s):
    >  3:03:51.468: echo:  M203 X500.00 Y500.00 Z15.00 E50.00
    >  3:03:51.468: echo:Maximum Acceleration (units/s2):
    >  3:03:51.469: echo:  M201 X1000 Y1000 Z100 E5000
    >  3:03:51.469: echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
    >  3:03:51.469: echo:  M204 P500.00 R1000.00 T500.00
    >  3:03:51.514: echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
    >  3:03:51.515: echo:  M205 B25000 S0.00 T0.00 X10.00 Y10.00 Z0.40 E5.00
    >  3:03:51.515: echo:Home offset:
    >  3:03:51.515: echo:  M206 X0.00 Y0.00 Z0.00
    >  3:03:51.515: echo:Material heatup parameters:
    >  3:03:51.515: echo:  M145 S0 H200 B60 F0
    >  3:03:51.515: echo:  M145 S1 H240 B100 F0
    >  3:03:51.516: echo:PID settings:
    >  3:03:51.516: echo:  M301 P22.20 I1.08 D114.00
    >  3:03:51.516: echo:  M304 P690.34 I111.47 D1068.83
    >  3:03:51.516: echo:Filament load/unload lengths:
    >  3:03:51.516: echo:  M603 L0.00 U100.00
    >  3:04:35.502: start
    >  3:04:35.502: echo: External Reset
    <  3:04:35.502: N1 M105
    >  3:04:35.528: Marlin TH3D U1.R2.2
    >  3:04:35.528: echo: Last Updated:  | Author: (TH3D)
    >  3:04:35.528: echo:Compiled: Sep 25 2018
    >  3:04:35.528: echo: Free Memory: 3367  PlannerBufferBytes: 1232
    >  3:04:35.572: echo:V55 stored settings retrieved (655 bytes; crc 32826)
    >  3:04:35.572: echo:  G21    ; (mm)
    >  3:04:35.573: echo:  M149 C ; Units in Celsius
    >  3:04:35.573: echo:Steps per unit:
    >  3:04:35.573: echo:  M92 X80.00 Y80.00 Z400.00 E93.00
    >  3:04:35.573: echo:Maximum feedrates (units/s):
    >  3:04:35.573: echo:  M203 X500.00 Y500.00 Z15.00 E50.00
    >  3:04:35.573: echo:Maximum Acceleration (units/s2):
    >  3:04:35.573: echo:  M201 X1000 Y1000 Z100 E5000
    >  3:04:35.573: echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
    >  3:04:35.573: echo:  M204 P500.00 R1000.00 T500.00
    >  3:04:35.621: echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
    >  3:04:35.621: echo:  M205 B25000 S0.00 T0.00 X10.00 Y10.00 Z0.40 E5.00
    >  3:04:35.621: echo:Home offset:
    >  3:04:35.621: echo:  M206 X0.00 Y0.00 Z0.00
    >  3:04:35.621: echo:Material heatup parameters:
    >  3:04:35.621: echo:  M145 S0 H200 B60 F0
    >  3:04:35.621: echo:  M145 S1 H240 B100 F0
    >  3:04:35.621: echo:PID settings:
    >  3:04:35.622: echo:  M301 P22.20 I1.08 D114.00
    >  3:04:35.622: echo:  M304 P690.34 I111.47 D1068.83
    >  3:04:35.622: echo:Filament load/unload lengths:
    >  3:04:35.622: echo:  M603 L0.00 U100.00
    >  3:05:18.628: start
    >  3:05:18.629: echo: External Reset
    >  3:05:18.629: Marlin TH3D U1.R2.2
    >  3:05:18.629: echo: Last Updated:  | Author: (TH3D)
    >  3:05:18.629: echo:Compiled: Sep 25 2018
    >  3:05:18.629: echo: Free Memory: 3367  PlannerBufferBytes: 1232
    <  3:05:18.629: N1 M105
    >  3:05:18.675: echo:V55 stored settings retrieved (655 bytes; crc 32826)
    >  3:05:18.675: echo:  G21    ; (mm)
    >  3:05:18.675: echo:  M149 C ; Units in Celsius
    >  3:05:18.675: echo:Steps per unit:
    >  3:05:18.676: echo:  M92 X80.00 Y80.00 Z400.00 E93.00
    >  3:05:18.676: echo:Maximum feedrates (units/s):
    >  3:05:18.676: echo:  M203 X500.00 Y500.00 Z15.00 E50.00
    >  3:05:18.676: echo:Maximum Acceleration (units/s2):
    >  3:05:18.676: echo:  M201 X1000 Y1000 Z100 E5000
    >  3:05:18.677: echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
    >  3:05:18.677: echo:  M204 P500.00 R1000.00 T500.00
    >  3:05:18.723: echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
    >  3:05:18.724: echo:  M205 B25000 S0.00 T0.00 X10.00 Y10.00 Z0.40 E5.00
    >  3:05:18.724: echo:Home offset:
    >  3:05:18.725: echo:  M206 X0.00 Y0.00 Z0.00
    >  3:05:18.725: echo:Material heatup parameters:
    >  3:05:18.725: echo:  M145 S0 H200 B60 F0
    >  3:05:18.725: echo:  M145 S1 H240 B100 F0
    >  3:05:18.726: echo:PID settings:
    >  3:05:18.726: echo:  M301 P22.20 I1.08 D114.00
    >  3:05:18.726: echo:  M304 P690.34 I111.47 D1068.83
    >  3:05:18.726: echo:Filament load/unload lengths:
    >  3:05:18.726: echo:  M603 L0.00 U100.00


  • edited October 2018
    Server.log has lots of:

    Connection Started
    Reset Printer
    Port Closed
    Connection Closed
    Connection Started
    Reset Printer

    All within the span of 10-15s.

    More logs after I restarted the Service:
    3:24:35.956: start
    3:24:35.956: echo: External Reset
    3:24:35.956: Marlin TH3D U1.R2.2
    3:24:35.956: echo: Last Updated: | Author: (TH3D)
    3:24:35.956: echo:Compiled: Sep 25 2018
    3:24:35.956: echo: Free Memory: 3367 PlannerBufferBytes: 1232
    3:24:36.001: echo:V55 stored settings retrieved (655 bytes; crc 32826)
    3:24:36.001: echo: G21 ; (mm)
    3:24:36.002: echo: M149 C ; Units in Celsius
    3:24:36.002: echo:Steps per unit:
    3:24:36.002: echo: M92 X80.00 Y80.00 Z400.00 E93.00
    3:24:36.002: echo:Maximum feedrates (units/s):
    3:24:36.002: echo: M203 X500.00 Y500.00 Z15.00 E50.00
    3:24:36.002: echo:Maximum Acceleration (units/s2):
    3:24:36.002: echo: M201 X1000 Y1000 Z100 E5000
    3:24:36.002: echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
    3:24:36.002: echo: M204 P500.00 R1000.00 T500.00
    3:24:36.049: echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
    3:24:36.049: echo: M205 B25000 S0.00 T0.00 X10.00 Y10.00 Z0.40 E5.00
    3:24:36.049: echo:Home offset:
    3:24:36.049: echo: M206 X0.00 Y0.00 Z0.00
    3:24:36.049: echo:Material heatup parameters:
    3:24:36.049: echo: M145 S0 H200 B60 F0
    3:24:36.049: echo: M145 S1 H240 B100 F0
    3:24:36.049: echo:PID settings:
    3:24:36.049: echo: M301 P22.20 I1.08 D114.00
    3:24:36.049: echo: M304 P690.34 I111.47 D1068.83
    3:24:36.049: echo:Filament load/unload lengths:
    3:24:36.050: echo: M603 L0.00 U100.00
    3:24:39.966: Warning: Communication timeout - resetting communication buffer.
    3:24:39.967: Connection status: Buffered:11, Manual Commands: 9, Job Commands: 0
    3:24:39.967: Buffer used:11 Enforced free byte:0 lines stored:1
    3:24:40.712: FIRMWARE_NAME:Marlin TH3D U1.R2.2 SOURCE_CODE_URL: PROTOCOL_VERSION:1.0 MACHINE_TYPE:TH3D U1.R2.2 EXTRUDER_COUNT:1 UUID:
    3:24:40.713: Cap:SERIAL_XON_XOFF:0
    3:24:40.713: Cap:EEPROM:1
    3:24:40.713: Cap:VOLUMETRIC:0
    3:24:40.713: Cap:AUTOREPORT_TEMP:1
    3:24:40.713: Cap:PROGRESS:0
    3:24:40.713: Cap:PRINT_JOB:1
    3:24:40.714: Cap:AUTOLEVEL:0
    3:24:40.714: Cap:Z_PROBE:0
    3:24:40.714: Cap:LEVELING_DATA:0
    3:24:40.714: Cap:BUILD_PERCENT:1
    3:24:40.714: Cap:SOFTWARE_POWER:0
    3:24:40.714: Cap:TOGGLE_LIGHTS:0
    3:24:40.714: Cap:CASE_LIGHT_BRIGHTNESS:0
    3:24:40.715: Cap:EMERGENCY_PARSER:0
    3:24:40.715: Cap:AUTOREPORT_SD_STATUS:0
    3:24:40.715: Cap:THERMAL_PROTECTION:1
    3:24:40.762: X:0.00 Y:0.00 Z:0.00 E:0.00 Count X:0 Y:0 Z:0
    3:24:40.813: echo:Unknown command: "G21"
  • any ideas or should I open a support ticket?
  • >  3:04:35.622: echo:  M304 P690.34 I111.47 D1068.83
    >  3:04:35.622: echo:Filament load/unload lengths:
    >  3:04:35.622: echo:  M603 L0.00 U100.00
    >  3:05:18.628: start
    >  3:05:18.629: echo: External Reset
    >  3:05:18.629: Marlin TH3D U1.R2.2
    >  3:05:18.629: echo: Last Updated:  | Author: (TH3D)
    >  3:05:18.629: echo:Compiled: Sep 25 2018
    >  3:05:18.629: echo: Free Memory: 3367  PlannerBufferBytes: 1232
    <  3:05:18.629: N1 M105
    >  3:05:18.675: echo:V55 stored settings retrieved (655 bytes; crc 32826)

    here you see clearly that reconnection works. We get the "start" from firmware and lots of output.
    What I do not see is any responses to commands being send just as if they do not get to the printer. I wonder if that is caused by fake ftdi chips. Some ftdi drivers are known to to bad tricks on them to stop produces from faking them. See for example here:
    http://www.starlino.com/ftdi-chip-real-of-fake-how-to-spot-a-fake-rt232r-rt232rl-and-others.html

    Could you test if you have a original or fake FTDI chip?
  • Original.  All these printers were working with earlier version of repetier, emergency stop was working, and never had an issue till I upgraded to the latest version of Marlin Firmware+Repetier....

  • Do you have compiled marlin with flow control? As I see the startup works the question is why we get no more feedback. Since you updated both it now hard to say whose changes cause the problem.

    What was the last server version that had no problems? Then I could compare the changes since then.
  • .90.4 did not have any issue.  I have marlin compiled with flow control turned on.   
Sign In or Register to comment.