Unable to connect in Repetier Server, but successful in Repetier Host

edited October 2017 in General
I have a PrimaSelect P120 V3. It is a Malyan M200/Monoprice Select Mini V2(without the E3D clone hotend) rebrand.

It has the V2 firmware, and the board with the extra fan for the mainboard.
I have no issues connecting it to Cura, S3D, Repetier Host and such. But it just will not connect to Repetier Server. I have a V1 of the same printer, and it connects, allthough not without it's hickups.

How to fix this problem? I the reason I have Repetier Server Pro is to be able to run multiple printers from one location with cameras and all.

Specs:
Windows 7
USB

Tried:
Different drivers
Changing ComPort both phsically and in software
Restarting
Plugging/unplugging
New Cable
Adding Ferrite ring to USB cable
Connecting and printing og Repetier Host, Cura and S3D
All Baudrates
«1

Comments

  • Make sure to select the right firmware. Marlin with repetier selected e.g. will not work and vice versa causes problems. Of course baud rate and port must match and no other software must be connected to printer.
  • I have tried all this. And as said I can easily connect it to Repetier Host, Cura and Simplify3D. I just don't get why Repetier Server can't connect. It's sending data, but not recieving anything according to the stats. It seems it wait for some sort of greeting/initializing command or something from the printer. It does not restart the printer(the display does not flash or anything) on the V1 eighter. If something happens to the V1 making it lose connection, I have to manually shut the server down and start it up again to have it connect. So it seems not everything is as it should be in the communication.

  • Can you show a log from connection in repetier-host with all log options enabled? Maybe that gives some hints. I think if a company adds some delay before sending "start" that could be a problem. But I would expect it to reset on connect if it happens with host as well. Both toggle the same connection flags (DTR/RTS).
  • So here are the logs for the V1 that connects, and the V2 that does NOT connect:
    V1 That works:
    10:27:20.365 : No start signal detected - forcing start
    10:27:20.387 : N1 M110*34
    10:27:20.387 : N2 M115*36
    10:27:20.387 : N3 M105*36
    10:27:20.387 : N4 M114*35
    10:27:20.388 : N5 M111 S6*98
    10:27:20.397 : N6 T0*60
    10:27:20.398 : N7 M80*28
    10:27:20.398 : N8 M105*47
    10:27:20.437 : ok N1 P15 B15
    10:27:20.455 : NAME: Malyan VER: 3.0 MODEL: M200 HW: HA02
    10:27:20.470 : ok N3 P15 B14
    10:27:20.470 : Warning: Missed line detected - correcting buffer usage.
    10:27:20.553 : ok N5 P15 B13 T:17.2 /0.0 B:19.8 /0.0 T0:17.2 /0.0 @:0 B@:0
    10:27:20.553 : Warning: Missed line detected - correcting buffer usage.
    10:27:20.598 : X:120.00 Y:120.00 Z:41.39 E:-2.50 Count X: 120.00 Y:120.00 Z:41.39
    10:27:20.611 : ok N7 P15 B12
    10:27:20.611 : Warning: Missed line detected - correcting buffer usage.
    10:27:20.625 : ok N8 P15 B12
    10:27:20.649 : echo:Active Extruder: 0
    10:27:20.663 : ok N8 P15 B13
    10:27:20.677 : ok N8 P15 B14
    10:27:20.739 : ok N8 P15 B15 T:16.5 /0.0 B:19.1 /0.0 T0:16.5 /0.0 @:0 B@:0
    10:27:23.420 : N9 M105*46
    10:27:23.488 : ok N9 P15 B15 T:18.4 /0.0 B:20.3 /0.0 T0:18.4 /0.0 @:0 B@:0

    V2 That does not want to connect:
    11:20:36.213 : No start signal detected - forcing start
    11:20:36.234 : N1 M110*34
    11:20:36.235 : N2 M115*36
    11:20:36.235 : N3 M105*36
    11:20:36.235 : N4 M114*35
    11:20:36.235 : N5 M111 S6*98
    11:20:36.247 : N6 T0*60
    11:20:36.248 : N7 M80*28
    11:20:36.248 : N8 M105*47
    11:20:36.272 : ok N1 P15 B15
    11:20:36.273 : NAME. Malyan VER: 3.7 MODEL: M200 HW: HH02
    11:20:36.274 : BUILD: Jul  5 2017 19:38:10
    11:20:36.274 : ok N3 P15 B14
    11:20:36.274 : Warning: Missed line detected - correcting buffer usage.
    11:20:36.298 : ok N5 P15 B13 T:182.5 /0.0 B:54.7 /0.0 T0:182.5 /0.0 @:0 B@:0
    11:20:36.298 : Warning: Missed line detected - correcting buffer usage.
    11:20:36.298 : X:0.00 Y:110.00 Z:41.39 E:-2.50 Count X: 0.00 Y:110.00 Z:41.39
    11:20:36.298 : ok N7 P15 B12
    11:20:36.298 : Warning: Missed line detected - correcting buffer usage.
    11:20:36.298 : ok N8 P15 B12
    11:20:36.298 : echo:Active Extruder: 0
    11:20:36.298 : ok N8 P15 B13
    11:20:36.298 : ok N8 P15 B14
    11:20:36.301 : ok N8 P15 B15 T:182.3 /0.0 B:54.6 /0.0 T0:182.3 /0.0 @:0 B@:0
    11:20:39.273 : N9 M105*46
    11:20:39.277 : ok N9 P15 B15 T:179.4 /0.0 B:53.3 /0.0 T0:179.4 /0.0 @:0 B@:0

  • edited October 2017
    Seems they actually TALK a little bit. I set it up like it should be with extruder etc. And when I set an extruder temp over and over again, it finally takes, and the printer heats up. So they talk a little bit it seems...

    The connection sumbol changes from RED to AMBER back and forth

    Every time the connection state changes to AMBER I have like a window of a couple of seconds to for example adjust the fan speed. So the printer IS listening for what the server software has to say :) It just seems the server software is not listening.
  • I wonder what firmware they are using. They do not send "start" so it seems host also does not reset printer. And M115 does not respond with a known firmware name also it looks a bit like marlin.

    Both versions seem to communicate, see no problem there. What I see are missing "ok" replies resulting in " Warning: Missed line detected - correcting buffer usage."

    That server switches between amber and red means it sees the port but the response lets it think it is not working correctly. Normally baud rate or firmware mismatch. If you enable logging you might see some communication in the log file.
  • edited October 2017
    I see, but my wonder is why it works like a charm in S3D, Cura and Repetier Host, but not Repetier Server? Is there something that can be done in a future update or something, as it seems to be a weakness of the software more than a problem with the printer.

    And yes I see in the log that there is some communication now and then, just seems they are not in sync like the other softwares

  • Have just checked the prima.com homepage and sow nothing about the firmware. From what I see it should connect with Marlin as firmware just as it does with Repetier-Host. But I do not have the printer for testing. Did you manage to get some logs from the server. If enabled it should be in connected.log of the printer. Deactivate printer at some point so that it does not get deleted all the time.
  • Looking at the Malyan wiki page it look like they either use a old (2 year) modified marlin or possibly a makerwaer type firmware.

  • < 10:01:42.825: N1 M105
    < 10:01:43.831: N2 M105
    < 10:01:44.721: M110
    < 10:01:44.721: N2 M105
    < 10:01:44.721: N3 M115
    < 10:01:44.721: N4 M220 S100
    < 10:01:44.721: N5 M221 S100
    < 10:01:44.721: N6 G92 E0
    < 10:01:44.723: M117 IP:192.168.0.116
    < 10:01:54.070: N7 M105
    < 10:01:55.070: N8 M105
    < 10:01:55.520: N9 M106 S235 P0
    < 10:01:55.980: M110
    < 10:01:55.980: N2 M105
    < 10:01:55.980: N3 M115
    < 10:01:55.980: N4 M220 S100
    < 10:01:55.980: N5 M221 S100
    < 10:01:55.980: N6 G92 E0
    < 10:02:05.283: N7 M105
    < 10:02:05.720: N8 M106 S237 P0
    < 10:02:05.930: N9 M106 S247 P0
    < 10:02:06.320: N10 M105
    < 10:02:06.370: N11 M106 S255 P0
    < 10:02:07.230: M110
    < 10:02:07.230: N2 M105
    < 10:02:07.230: N3 M115
    < 10:02:16.571: N4 M105
    < 10:02:17.571: N5 M105
    < 10:02:18.521: M110
    < 10:02:18.521: N2 M105
    < 10:02:18.521: N3 M115
    < 10:02:18.521: N4 M220 S100
    < 10:02:18.521: N5 M221 S100
    < 10:02:18.521: N6 G92 E0
    < 10:02:18.523: M117 IP:192.168.0.116
    < 10:02:27.829: N7 M105
    < 10:02:28.820: N8 M106 S227 P0
    < 10:02:28.830: N9 M105
    < 10:02:29.780: M110
    < 10:02:29.780: N2 M105
    < 10:02:29.780: N3 M115
    < 10:02:29.780: N4 M220 S100
    < 10:02:29.780: N5 M221 S100
    < 10:02:29.780: N6 G92 E0


    Not much, but it is what is in the logfile after adjusting the fanspeed and getting response from the printer

    It is MARLIN firmware of some sort, so that is not the issue. As I get it to talk to all other software. But is there a way to make the server software to force communication like the others do? As the other softwares have two ways com it should be possible to make it work.
  • The strange thing here is that there is zero response from firmware. So from that point closing connection and telling it does not work would be correct. Server requires a response pretty soon after connecting or sending commands or it assumes there is no firmware to talk to.

    When you connect with host, how long does it take until you see some responses from the firmware? 
    I have already seen firmwares that start with a fancy intro screen, but showing that blocked communication. Will try adding such a delay and see if I can add a variable to wait longer for such firmwares.
  • Sorry for the delayed answer. When I connect with Host there is no noticable delay or anything. It does not boot the printer as far as I can see. It seems it connects by just joining the conversation if you understand what I mean? Is there a command I can send to force the printer to "boot"?

  • No, if it does not boot with toggling dtr it can not from gcode side. Normally that is no problem since we simply send the commands anyway after a timeout. Only in some rare cases firmware is in an error state that makes this not working. Then hitting reset button on printer helps. But your log does not show any answer so that is not the problem here. Will try connecting with a due native port for verificaion that this is still working.
  • I must admit this sounds abit over my head, but as I understand you will try to make it work in a new version?

  • I will at least try to reproduce the problem. But that is with a different board and firmware so not sure if it will happen to me. It surely never did till now, but sometimes I add something with unintended side effects. So if this was the case it will then be fixed in next release.
  • Ok, trying with a due on native port is still working.

    If you look into server do you see a message like "No valid response seen within 10 seconds from printer, restarting connection" and what does server.log show when trying to connect? Normally you only see
    2017-10-20 15:59:39: Connection started: radds
    2017-10-20 15:59:39: Reset printer radds

    and then communication is working. After 3 seconds it will ask for some data and if it does not get anything after 10 seconds it will show the above error message.

    Since you have no response at all I suspect a problem with DTR/RTS function of the serial connection. All printers I know either ignore them or use them to reset the board. So we use it to reset the board as well setting them to false and then to true. Originally they were used for hardware flow control so it may have such a function in your case. Meaning that having these 2 signals high get interpreted as "please do not answer", which would pretty much explain the problem. On due native port for example I can only communicate with DTR set to true. Could you test your connection using coolterm

    http://coolterm.en.lo4d.com/download

    which is  a dump serial terminal. In Options->Terminal select line mode and in SerialPort you can select connection speed and initial state of RTS and DTR pin. Test if can for example issue M119 and get an answer. If with some DTR/RTS combinations you get no answer I know what to do.
  • Tested it out. I get answer in any combination with RTS and DTR pin. Here is a dump of the M503 command:
    ok N61401 P15 B15
    echo:Steps per unit:
    echo:  M92 X93.00 Y93.00 Z1097.50 E97.00
    echo:Maximum feedrates (mm/s):
    echo:  M203 X150.00 Y150.00 Z1.50 E50.00
    echo:Maximum Acceleration (mm/s2):
    echo:  M201 X800 Y800 Z20 E10000
    echo:Accelerations: P=printing, R=retract and T=travel
    echo:  M204 P3000.00 R3000.00 T3000.00
    echo:Advanced variables: 
    S=Min feedrate (mm/s), 
    T=Min travel feedrate (mm/s), 
    B=minimum segment time (ms), 
    X=maximum XY jerk (mm/s),  
    Z=maximum Z jerk (mm/s),  
    E=maximum E jerk (mm/s)
    echo:  M205 S0.00 T0.00 B20000 X20.00 Z0.40 E5.00
    echo:Home offset (mm):
    echo:  M206 X0.00 Y0.00 Z0.00
    echo:Invert axis: M562 XYZE
    XYZABCD-+-+-+-
    echo:PID settings:
    echo:  M301 P20.00 I0.02 D250.00 C100.00 L20
    echo:  M304 P10.00 I0.02 D305.40
    echo:Filament settings: Disabled
    echo:  M200 D1.75
    echo:  M200 D0
    ok N61401 P15 B15

  • Ok, so no apparent reason to not connect. And since V1 does work I have no idea what is different in V2 that it wont connect.

    On which OS are you trying this with the server?
  • Windows 7 I know! It just do not make sense at all. I am "this" far away from a clean install of the server. But I really don't think that will fix it. Well, I'll keep using Repetier Server on a remote desktop for now, and hope You can get to the bottom of it some day. Really love the Server software, so I hope it works itself out.
  • I have the same problem with the Monoprice Mini Delta (malyan is the manufacturer).  For some reason they require Hardware flow control (RTS/CTS) i.e for RTS to be asserted.  Most Ardunio based printers use DTR to reset the system which are also used for hardware flow control (DTR/DSR) so hardware flow control isn't used much with an Ardunio.  Even though these signals don't physical exist as on the malyan and is using a USB CDC gadget they still require the logical state to be asserted.  I had to add a virtual port between repetier server and the USB serial port and assert RTS to get mine to work.  It is a little involved so I am not going to go into the details.  Perhaps official support for hardware flow control will be added sooner then later.
  • No hardware flow control will be implemented I think. But what I could do is make it possible to set DTR and RTS to high/low/auto so you can set it in configuration. I think that is what you also did with your solution. Server will handle flow control on it's own through the firmware handshake.
  • Here is a log from OCtoprint after having problems connecting.
    I ended up pressing connect/disconnect rapidly, and BANG it connected to Octoprint via PI

    Changing monitoring state from 'Connecting' to 'Offline'
    Connection closed, closing down monitor
    Connecting to: /dev/ttyACM0
    Changing monitoring state from 'Offline' to 'Opening serial port'
    Connected to: Serial<id=0xae921710, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
    Changing monitoring state from 'Opening serial port' to 'Connecting'
    Send: N0 M110 N0*125
    Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1827
    Please see https://bit.ly/octoserial for possible reasons of this.
    Changing monitoring state from 'Connecting' to 'Offline: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:1827'
    Connection closed, closing down monitor
    Connecting to: /dev/ttyACM0
    Changing monitoring state from 'Offline' to 'Opening serial port'
    Connected to: Serial<id=0xae517730, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
    Changing monitoring state from 'Opening serial port' to 'Connecting'
    Send: N0 M110 N0*125
    There was a timeout while trying to connect to the printer
    Changing monitoring state from 'Connecting' to 'Offline'
    Connection closed, closing down monitor
    Connecting to: /dev/ttyACM0
    Changing monitoring state from 'Offline' to 'Opening serial port'
    Connected to: Serial<id=0xae517c50, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
    Changing monitoring state from 'Opening serial port' to 'Connecting'
    Send: N0 M110 N0*125
    Changing monitoring state from 'Connecting' to 'Offline'
    Connecting to: /dev/ttyACM0
    Changing monitoring state from 'Offline' to 'Opening serial port'
    Connected to: Serial<id=0xae6ce9f0, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
    Changing monitoring state from 'Opening serial port' to 'Connecting'
    Send: N0 M110 N0*125
    Connection closed, closing down monitor
    Recv: ok N0 P15 B15
    Changing monitoring state from 'Connecting' to 'Operational'
    Send: N1 M105*38
    Recv: ok N1 P15 B15 T:20.4 /0.0 B:23.8 /0.0 T0:20.4 /0.0 @:0 B@:0
    Send: N0 M110 N0*125
    Recv: ok N0 P15 B15
    Send: N1 M115*39
    Recv: NAME. Malyan\x09VER: 4.0\x09MODEL: M200\x09HW: HH02
    Recv: CLK:EXT BUILD: Aug 10 2017 09:53:33
    Recv: ok N1 P15 B15
    Send: N2 M21*18
    Recv: ok N2 P15 B15
    Changing monitoring state from 'Operational' to 'Offline'
    Connecting to: /dev/ttyACM0
    Changing monitoring state from 'Offline' to 'Opening serial port'
    Connected to: Serial<id=0xae6ce1b0, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
    Changing monitoring state from 'Opening serial port' to 'Connecting'
    Send: N0 M110 N0*125
    Connection closed, closing down monitor
    Recv: ok N0 P15 B15
    Changing monitoring state from 'Connecting' to 'Operational'
    Send: N1 M105*38
    Recv: ok N1 P15 B15 T:19.1 /0.0 B:21.3 /0.0 T0:19.1 /0.0 @:0 B@:0
    Send: N0 M110 N0*125
    Recv: ok N0 P15 B15
    Send: N1 M115*39
    Recv: NAME. Malyan\x09VER: 4.0\x09MODEL: M200\x09HW: HH02
    Recv: CLK:EXT BUILD: Aug 10 2017 09:53:33
    Recv: ok N1 P15 B15
    Send: N2 M21*18
    Recv: ok N2 P15 B15
    Send: N3 M105*36
    Recv: ok N3 P15 B15 T:19.1 /0.0 B:21.4 /0.0 T0:19.1 /0.0 @:0 B@:0
    Send: N4 M105*35
    Recv: ok N4 P15 B15 T:21.5 /0.0 B:19.5 /0.0 T0:21.5 /0.0 @:0 B@:0
    Send: N5 M105*34
    Recv: ok N5 P15 B15 T:21.0 /0.0 B:23.9 /0.0 T0:21.0 /0.0 @:0 B@:0
    Send: N6 M105*33
    Recv: ok N6 P15 B15 T:20.5 /0.0 B:23.8 /0.0 T0:20.5 /0.0 @:0 B@:0
  • Looks like you also have dtr/rts set to false here. So adding a selector for this to the server might help as well here, also I see that it also failed several times to connect so the printer seems to have at least a strange behaviour with that regard.

    On server you can also try reconnect by deactivate and activate in printer menu. If that would succeed after some tries like with octoprint I can not say since we toggle the signal. 
  • Was this issue resolved? I got repetier server specifically for my Malyan M200 so I'm rather bummed out that I can't get it to work. In OctoPi the connection would sometimes break, but mostly it worked.
  • No new server version so far. Working on some big features that are time intensive.
  • I have the exact same problem.   Windows 7, Pro License, V2, works on Repetier Host.  Maybe it is "someone else's problem, but it seems that Repetier is in the best position to fix this.  I tried turning on hardware flow control in windows 7 - did not help.  Please fix this not so big feature!  Thanks
  • After connecting to the host, I try to connect the printer to the server, but the server never complains that the port is in use.
  • If it is in deed related to the pins state, that would not be the problem. Next release will get a switch for the pins so we have more options to find reasons.
  • As indicated by the other posters, some version of repetier server worked with the V1 Monoprice Select Mini (MP200), and the current version of the repetier-host works fine with the V2 Monoprice Select Mini (MP200).  What's different between the server and host connection software or the communications protocols? 

    In step 2 of add new printer I eventually get
    "No understandable response  recieved ...."

    but the home screen and device list show that the V2 printer toggles between connected (yellow) and disconnected (red) every few seconds.

    I would be happy to beta test any fix you might have.

    Thanks



     
  • Main difference is that in server you tell firmware type and that defines communication protocol, while host normally is set to autodetect and only switches to repetier protocol if repetier is detected. But if you start in server with marlin as firmware selected it will just talk in ascii format like host would do. First command send might differ but that is all. DTR/RTS toggle should be the same.

    Regarding beta test, subscribe our tweet. I will post there if a beta is available. But current version is not complete so I have no versions except inside my debugger.
Sign In or Register to comment.