›

Connection problem after upgrading to 0.70

LutunenLutunen
in Repetier-Server
I have two equal printers with motherboard Andciv CM3E 3D. I had problems with connection also with server version 0.65 but after installing new Windows 7 computer I almost get rid of those problems. Sometimes still the connection broke after 2-3h printing time.

I installed new server version 0.70 and now the symptoms got much worse. After starting a new job, printer stops in few seconds without any information in log file. Server keeps "green" but cannot control the printer (for example "move" commands do not have any effect). If I disconnect usb cable and reconnect connection becomes back.

I have tried with different baud rates but it doesn't help. 115200 and 76800 seem to function best in version 0.65. Also tried larger buffer and communication timeout (90)  Have to mention that on printers side the baud rate seem to be 100.000. Motherboard always resets baud to this after booting the printer. Repetier Server doesn't have this baudrate option in baud rate list. However I tried to change the baud rate to 100000 manually in configuration file but couldn't get any contact to the printer.

This connection problem must be some kind of compatibility issue between Repetier Server and my motherboard. I don't have any connection issues with other software (for example Simplify 3D).

Otherwise I love concept of Repetier Server if I just could achieve trusted connection. I hope we could solve this problem somehow.

Comments

  • RepetierRepetier
    First your printer never should have 100000 baud. It should have one of the default baud rates like 115200 and that mus match exactly the server baud rate. If they differ you will get problems.

    Communication timeout only says when we assume we have missed a firmware response and continue with next command.

    Important things to solve the problem is:
    1. What firmware are you using?
    2. What does the log say Do you get also errors during print it recovers from?
  • LutunenLutunen
    The firmware is andcivfw.bin which I got from the manufacturer in China. My printers are Clitar 6C  which have Andciv CM3G3 mainboard. It has been really difficult to get information/support from there. 

    But the printer itself works fine (if printed from SD card) and has good size build volume 300 x 200 x 600mm. 

    Only errors I have got are simply:
    "Warning: Communication timeout - resetting communication buffer."

    Repetier Server version 0.65 worked almost perfectly but with 0.70 the printing just stops without any warnings.

    Could it be that the installation went wrong: I first tried to "upgrade" from your website, but upgrading just looped. Then I uninstalled 0.66 and downloaded 0.70 and installed this new version?

    Is it possible to use Repetier firmware with this motherboard? 


  • RepetierRepetier
    No, our firmware is not compatible with that chip. We also do not have the board so I even do not know what firmware and special cases they have added. I guess you are using the marlin firmware setting and hope responses match to marlin style?

  • LutunenLutunen
    This is correct, I use Marlin settings. If I try to ask the manufacturer information to get the board function with Repetier server what should I ask?
  • RepetierRepetier
    I guess the most important question is what the exact baud rate is. 100000 sounds very odd.

    Other question would be if the firmware uses the same commands and especially response format as marlin or if there are differences. We have a folder firmwares in repetier server where we define response formats for different firmwares, so in case there are differences you could copy marlin.xml and make a new one with modified responses to adjust to different firmware.

    BTW: If you send M115 what does it say which firmware it is?

  • LutunenLutunen
    Printers LCD screen actually shows only 3 digits, when I boot the printer first it shows 125 and then it will turn 100.
    According to the manufacturer of Glitar 6C printer, the slicer is Cura. Setting instructions were to use Marlin as firmware.
    By default the manufacturer instructed to print from SD. Actually I got the Windows driver later after asking for it several times.

    It might be, that the motherboard Andciv CM3E 3D may have some problem with Windows connection in general if instructed to print through SD -card.. Who knows?

    Anyway sending M115 returns this:

    14:05:11.891: N27 M115
    14:05:11.894: ok M115 FIRMWARE_NAME:Welcom-MINGDA-15.6101 BID:3 FIRMWARE_URL:http://www.mingda.com PROTOCOL_VERSION:1.0 MACHINE_TYPE:Welcom-MINGDA
    14:05:11.972: N28 M105
    14:05:11.975: ok M105 T:19 B:21
    14:05:13.012: N29 M105

    Have a nice weekend!
  • RepetierRepetier
    And the firmware url does not exists. Not good if you want a broader support of hosts.

    With the name it seems like something self made. Using marlin for slicer does not say much as this only defines general commands that are more or less the same everywhere. So all that keeps is watching a written log (not the one in browser).
    The ok response is Marlin style without helping line number. That means if we miss a "ok" you will get a hang after a few misses for timeout seconds. Then print should continue until the next missed "ok" responses.

     If you print it works for a while and then something happens that is more interesting. Have a look at that part to see what is going wrong or post it. Add 100 lines above/below the pause.
  • oborobor
    Hi
    Got same pb here with raspberry b2 and v 0.70
    Erratic behavior.
    Logs show comm links errors mis match Checksum.
    I want to revert to 0.65 but can t find the software anymore on repetier server download home page...
  • LutunenLutunen
    OK, I'll inform if I find something in printed log. 

    I made clean installation of 0.70 but printing stops in few seconds. I had to revert 0.65 because it more or less functions in my case. As informed earlier I don't have connection issues with other slicers using online connection with the printer. I presume there is something new in version 0.70 which doesn't function with my motherboard.
  • RepetierRepetier
    Ok, seems liek a bug in 0.70.0. Marlin users seem to have problems with it as well.
  • oborobor
    Hello, could you please make available previous repetier server versions, right now I am blocked. Thanks  
  • RepetierRepetier
    0.65 is downloadable on www.repetier-server.com, just click the Download older version button to see them. Or replace version in link.
  • RepetierRepetier
    PS: 0.70 has split the settings.sql database into settings.sql and key.sql so make sure to disable a licence before downgrading and delete key.sql from database directory to prevent problems.
  • oborobor
    ok thanks. 
  • RepetierRepetier
    0.70.1 is released, no need to downgrade any more:-)
  • oborobor
    thanks for the quick update, 0.70.1 works much  better than 0.70.0
    Well at least during a first 7h print. Tonight, I tried again and after approximately 1hours, it paused erraticaly during the print.
    Again, and it happen the same way as it did with 0.65...
    May be Marlin/Arduino2560/Ramps is the problem, but the logs of repetier server do not show any checksum error...  I have no idea what it could be....
  • LutunenLutunen
    In my case connection works with 0.70.1 similar as with 0.65. Printing stops in about 30min - 2h after start. I have tried with 2 printers (Andciv CM3E 3D  motherboard). Log of both test prints/ printers seem to be normal until the stop happens. After connection brake Repetier Server connection stays "green", but no possibility to connect to the printer (move.. etc doesn't work). New connection requires unpluging/pluging the usb- cable. 

    This is the end of the log:
    < 20:09:28.880: N110442 G1 X164.844 Y97.287 E15.3121
    > 20:09:28.880: ok
    < 20:09:28.903: N110443 G1 X164.953 Y99.371 E15.5619
    > 20:09:28.903: ok
    < 20:09:28.976: N110444 G1 X164.953 Y99.995 E15.6367
    > 20:09:28.976: ok
    < 20:09:28.976: N110445 G1 X164.906 Y101.870 E15.8612
    > 20:09:28.976: ok
    < 20:09:28.997: N110446 G1 X164.768 Y103.418 E16.0473
    > 20:09:28.997: ok
    > 20:09:29.031: ok
    < 20:09:29.105: N110447 G1 X164.731 Y103.655 E16.0761
    > 20:09:29.105: ok
    < 20:09:29.213: N110448 G1 X164.669 Y104.279 E16.1511
    > 20:09:29.213: ok
    < 20:09:29.317: N110449 G1 X164.453 Y105.657 E16.3181
    > 20:09:29.317: ok
    < 20:09:29.349: N110450 G1 X164.256 Y106.673 E16.4420
    > 20:09:29.349: ok
    < 20:09:29.349: N110451 G92 E0
    < 20:09:29.369: N110452 M105
    < 20:09:29.442: N110453 G1 E-4.5000 F2400
    > 20:09:29.442: ok
    < 20:09:29.532: N110454 G1 X145.751 Y102.500 F4800
    > 20:09:29.532: ok
    < 20:09:29.688: N110455 G1 E0.0000 F2400
    > 20:09:29.688: ok
    < 20:09:29.688: N110456 G92 E0
    > 20:09:29.688: ok M105 T:210 B:50
    > 20:09:29.688: ok
    < 20:09:29.688: N110457 G1 X144.448 Y108.551 E0.7411 F1800
    > 20:09:29.688: ok
    < 20:09:29.692: N110458 G1 X143.938 Y114.001 E1.3966
    > 20:09:29.692: ok
    > 20:11:01.723: Warning: Communication timeout - resetting communication buffer.
    < 20:11:01.723: N110459 M105
    > 20:11:01.763: Warning: Communication timeout - resetting communication buffer.
    < 20:11:01.763: N110460 M105
    < 20:11:01.763: N110461 G1 X144.080 Y119.474 E2.0521
    < 20:11:01.773: N110462 G1 X145.039 Y126.044 E2.8470
    > 20:12:33.768: Warning: Communication timeout - resetting communication buffer.
    < 20:12:33.768: N110463 M105
    > 20:12:33.808: Warning: Communication timeout - resetting communication buffer.
    < 20:12:33.808: N110464 M105
    < 20:12:33.808: N110465 G1 X147.882 Y125.245 E3.2006
    < 20:12:33.818: N110466 G1 X150.258 Y124.204 E3.5112
    > 20:14:05.813: Warning: Communication timeout - resetting communication buffer.
    < 20:14:05.813: N110467 M105
    > 20:14:05.853: Warning: Communication timeout - resetting communication buffer.
    < 20:14:05.853: N110468 M105
    < 20:14:05.853: N110469 G1 X152.353 Y122.851 E3.8099
    < 20:14:05.863: N110470 G1 X154.149 Y121.238 E4.0988
    > 20:15:37.862: Warning: Communication timeout - resetting communication buffer.
    < 20:15:37.862: N110471 M105
    > 20:15:37.898: Warning: Communication timeout - resetting communication buffer.
    < 20:15:37.898: N110472 M105
    < 20:15:37.898: N110473 G1 X156.438 Y118.492 E4.5269
    < 20:15:37.908: N110474 G1 X158.608 Y115.119 E5.0072
    > 20:17:09.902: Warning: Communication timeout - resetting communication buffer.
    < 20:17:09.902: N110475 M105
    > 20:17:09.942: Warning: Communication timeout - resetting communication buffer.
    < 20:17:09.942: N110476 M105
    < 20:17:09.942: N110477 G1 X160.331 Y111.474 E5.4899
    < 20:17:09.952: N110478 G1 X161.784 Y106.971 E6.0565
    > 20:18:41.947: Warning: Communication timeout - resetting communication buffer.
    < 20:18:41.947: N110479 M105
    > 20:18:41.987: Warning: Communication timeout - resetting communication buffer.
    < 20:18:41.987: N110480 M105
    < 20:18:41.987: N110481 G1 X159.139 Y104.948 E6.4553
    < 20:18:41.997: N110482 G1 X158.363 Y104.523 E6.5611
    > 20:20:13.992: Warning: Communication timeout - resetting communication buffer.
    < 20:20:13.992: N110483 M105
    > 20:20:14.032: Warning: Communication timeout - resetting communication buffer.
    < 20:20:14.032: N110484 M105
    < 20:20:14.032: N110485 G1 X159.168 Y104.308 E6.6608
    < 20:20:14.042: N110486 G1 X159.892 Y103.970 E6.7565
    > 20:21:46.037: Warning: Communication timeout - resetting communication buffer.
    < 20:21:46.037: N110487 M105
    > 20:21:46.077: Warning: Communication timeout - resetting communication buffer.
    < 20:21:46.077: N110488 M105
    < 20:21:46.077: N110489 G1 X160.546 Y103.512 E6.8522
    < 20:21:46.087: N110490 G1 X161.111 Y102.947 E6.9479
    > 20:23:18.124: Warning: Communication timeout - resetting communication buffer.
    < 20:23:18.124: N110491 M105
    > 20:23:18.134: Warning: Communication timeout - resetting communication buffer.
    < 20:23:18.134: N110492 M105
    < 20:23:18.134: N110493 G1 X161.570 Y102.292 E7.0435
    < 20:23:18.171: N110494 G1 X161.907 Y101.568 E7.1392
    > 20:24:50.176: Warning: Communication timeout - resetting communication buffer.
    < 20:24:50.177: N110495 M105
    > 20:24:50.216: Warning: Communication timeout - resetting communication buffer.
    < 20:24:50.216: N110496 M105
    < 20:24:50.216: N110497 G1 X162.114 Y100.796 E7.2349
    < 20:24:50.226: N110498 G1 X162.184 Y100.000 E7.3306
    > 20:26:22.221: Warning: Communication timeout - resetting communication buffer.
    < 20:26:22.221: N110499 M105
    > 20:26:22.261: Warning: Communication timeout - resetting communication buffer.
    < 20:26:22.261: N110500 M105
    < 20:26:22.261: N110501 G1 X162.114 Y99.204 E7.4262
    < 20:26:22.271: N110502 G1 X161.907 Y98.432 E7.5219



  • RepetierRepetier
    @obor If the logs don't show anything check the pi you are running. Especially the load. There is a nice tool htop you could install:
    sudo apt-get install htop
    that shows processes and subprocesses including load. Maybe one component is drawing too much load making communication hard.

    Lutunen Your problem is much clearer. The usb communication is broken. That is no server problem at all. It is more caused by something else normally on the printer side. My guess is that the usb serial converter there got a problem from voltage drops or communication errors. Not sure. Have seen this also on windows and with other software happen. Unplugging usb/disabling the printer restarts everything and then it works. As long as it gets power from usb the converter will not restart and hence not work. So far at least my theory to this problem. Some users could produce the problem with simply turning some lights on or other things like washing machine. Whatever is on the same power network and draws sudden high currents. Then a USV for the printer helped. 
  • LutunenLutunen
    I do not believe the reason is voltage drop because the server and both 2 printers are behind UPS-devices that keep constant voltage several minutes after total power loss. In my experience I have not seen communication breaks with other slicers printing in  usb-connection. 

    Next days I'll test some long prints with another slicers (which I have thought functioning  in direct usb-connection). If I manage to get breaks as with 0.70.1, then my problem might be in hardware or elsewhere. If I don't manage to get any problems, then my problem is elsewhere or in software.


  • oborobor
    @Repetier Thanks for the hint, i'll check the CPU, may be my WIFI bad connection is eating cpu. Also i discover on my Ramps 1.4  that the solder of  heat bed connector on the PCB was getting bad. I resolder it and will try again.
  • RepetierRepetier
    @Lutunen That is already a good start to stability. SO we can assume at least the PU gets constant power. So only the 5V on controller board needs to stay stable. What I wanted to say is that this image means the usb stack with that device is not working. Since it has 2 ends we have 2 possible sources but from experience I always guess on the printer side.

    @obor Bad wifi s always a pain. I had very bad wifi and switched to ethernet which made my work much easier. No timeouts any more.
  • oborobor
    edited December 2015
    After having replaced the RAMPS1.4 and motor controller by brand new parts, I still get strange behavior and  freeze problems with 0.70.1 and Marlin. 
    The print fails eratically, il seems the head stops for some second (or more) and restart again.  

    The repetier server is running on a Raspberry pi2.
    CPU idle is > 95% , and there no other application running in the Raspberry pi2, Wifi traffic is low

    Any idea about  the reason for this   7 second stop ? 
    image



  • RepetierRepetier
    With marlin it is hard to see where a ok belongs to since we buffer several commands in advance, so a ok is for a command some lines before. This part at least shows no reason to delay. Would be easier with a marlin version that shows line numbers in ok, which also adds reliablility. Not sure if this already available in stable branches. What I think is that the ok after M105 maybe belongs before M105 for the logic. That would mean one command took 7 seconds to execute. Especially if you start missing a "ok" the buffer gets reduced until you get a block and it needs to time out to reset buffer length (that is where line numbers in ok come in play, which allow detecting and correction on the fly).

    If communication is ok and error free all the time it could also be something keeping pi busy for a short while preventing the server to run. Like you know from windows when a starting program takes all cpu time. That is something you can not analyse easily since it is gone before you notice it and 1 minute load does not show it. Check for running daemons and cron jobs that might interfere.
Sign In or Register to comment.