›

Connection issue

runekcrunekc
in Repetier-Server
Hi, I have recently upgraded my Repetier-server computer from a Windows 7 laptop (which worked with no problems) to a PC with Windows 10 and I have problems connecting one of my 3D printers. My ender 3 connects perfectly but my other 3D printer with a Robin Nano V3 board doesn't, Repetier-Server sees the printer but connection is not working I have to unplug and connect again or stop/start Repetier-server before the printer is connected. According to Windows the printer is always connected. Does anyone have the same problem or a solution.

best regards

Rune

Comments

  • RepetierRepetier
    Try changing DTR/RTS value to always on or always off. Some use these bits for flow control not answering on one setting.
  • runekcrunekc
    Hi, thanks but I can only set LOW, HIGH, LOW to HIGH or HIGH to LOW...
    Why wasn't that a problem with my Laptop?? all my settings are the same?

    This is what it says at first boot of the PC in the printer console:

    Mesg:16:03:46.008: Warning: Communication timeout - resetting communication buffer.
    Mesg:16:03:46.008: Connection status: Buffered:23, Manual Commands: 0, Job Commands: 0
    Mesg:16:03:46.008: Buffer used:23 Enforced free byte:0 lines stored:1
  • RepetierRepetier
    Yes, I mean always low or always high.

    Timeout is because there is no response from printer. It can be the DTR/RTS issue, but also it might be a different com port on the new computer. Also make sure firmware is set correctly.

    Did you just install the xml config from win 7 laptop? Normally I would also expect same config to work on new computer - except com port which is newly numbered on each windows pc.
  • runekcrunekc
    LOW doesn't work HIGH does but the initial connection is still a problem, it only happens at boot...as I said all my settings are working after stop/start of Repetier-Server or if I unplug/plugin the 3D printer so something is missing at boot of Windows, is it possible do disable autostart of Repetier-Server? To see if a manually start after boot works?
  • RepetierRepetier
    It is just a service so open task manager and set Repetier-Server start to manually and it does not start automatically on windows. You can then start it there or use the start/stop scripts provided.

    What about disabling and enabling printer in server instead? That would be nearly the same as server restart.

    You could also enable logging connected.log and see how connection start happens. The main problem with native usb boards is that they do not reset on connection (also it can an advantage) so you never know in which state the connection happens. It might be in an error requesting resending a line or something. Also we have added all known tricks to solve such conflicts like sending reset line number at start you never know if new things happen. connected.log would probably show it - or just fail to connect on first try for some reason. Will be interesting to see what you find out.
  • runekcrunekc
    Hi, deactivate/activate does also work....so is it a hardware issue with my new PC or perhaps Windows 10?
    This is the log when a connection is established:

    Mesg:10:26:26.952: Connection started
    Mesg:10:26:26.952: Printer reset requested false
    Mesg:10:26:26.952: Dtr: false Rts: false
    Mesg:10:26:26.984: Dtr: true Rts: true
    Recv:10:26:29.996: Send init commands because we had no signal from a reset, assuming reset not available.
    Recv:10:26:29.996: Connection verified by:ok N1 P31 B31
    Recv:10:26:29.998: FIRMWARE_NAME:Marlin bugfix-2.0.x (Feb 2 2022 22:29:54) SOURCE_CODE_URL:github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:TwoTrees Sapphire Plus EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
    Recv:10:26:29.998: Cap:SERIAL_XON_XOFF:1
    Recv:10:26:29.998: Cap:BINARY_FILE_TRANSFER:0
    Recv:10:26:29.998: Cap:EEPROM:1
    Recv:10:26:29.998: Cap:VOLUMETRIC:1
    Recv:10:26:29.998: Cap:AUTOREPORT_TEMP:1
    Recv:10:26:29.998: Cap:PROGRESS:0
    Recv:10:26:29.998: Cap:PRINT_JOB:1
    Recv:10:26:29.998: Cap:AUTOLEVEL:1
    Recv:10:26:29.998: Cap:RUNOUT:1
    Recv:10:26:29.998: Cap:Z_PROBE:1
    Recv:10:26:29.998: Cap:LEVELING_DATA:1
    Recv:10:26:29.998: Cap:BUILD_PERCENT:0
    Recv:10:26:29.998: Cap:SOFTWARE_POWER:0
    Recv:10:26:29.998: Cap:TOGGLE_LIGHTS:0
    Recv:10:26:29.998: Cap:CASE_LIGHT_BRIGHTNESS:0
    Recv:10:26:29.998: Cap:EMERGENCY_PARSER:1
    Recv:10:26:29.998: Cap:PROMPT_SUPPORT:0
    Recv:10:26:29.998: Cap:SDCARD:1
    Recv:10:26:29.998: Cap:REPEAT:0
    Recv:10:26:29.998: Cap:SD_WRITE:1
    Recv:10:26:29.998: Cap:AUTOREPORT_SD_STATUS:1
    Recv:10:26:29.998: Cap:LONG_FILENAME:1
    Recv:10:26:29.998: Cap:THERMAL_PROTECTION:1
    Recv:10:26:29.998: Cap:MOTION_MODES:0
    Recv:10:26:29.998: Cap:ARCS:1
    Recv:10:26:29.998: Cap:BABYSTEPPING:1
    Recv:10:26:29.998: Cap:CHAMBER_TEMPERATURE:0
    Recv:10:26:29.998: Cap:COOLER_TEMPERATURE:0
    Recv:10:26:29.998: Cap:MEATPACK:0
  • RepetierRepetier
    That log is exactly what I expect on working connection.
    So good question what is otherwise happening. On failure we normally reconnect which is the same as deactivate/activate just a bit quicker.

    Only thing in firmware I see is
     Cap:SERIAL_XON_XOFF:1
    We do not support that, but we also do not send XON/XOFF ascii codes. Anyhow since firmware does not reset it might have communication blocked on first connect somehow. Did you compile it your self (I saw it is just 4 days old), so you can test if disabling the feature works better?
  • runekcrunekc
    Well I went back to Windows 7 and it works perfect....go figure. I did compile the firmware myself. I will leave it as is for now, thank you so much for your help.
  • RepetierRepetier
    Since it is same server as well only difference might be the driver that might be newer and behave a bit differently in windows 10.
Sign In or Register to comment.