Problems with Sunlu S8 Configuration

When I initially purchased Repetier Server I was able to configure and use my Sunlu S8 printer (worked very well). Since then Repetier Server and Cura released updates which now have made it impossible for to use Repetier Server to print on my Sunlu S8.

When I print through the micro SD card the S8 is very fluid and prints continuously. When I send the job through Repetier Server and the USB cable - the printer continually stops and starts creating blobs of filament due to the delays in processing. It's almost like the printer is waiting, and waiting, and waiting for gcode to be sent to it. I tried multiple USB cables, removing the 2 cameras to reduce power load on the raspberry pi, configuration changes in Cura and Repetier with no luck. 

I do have a 2nd printer connected to the Raspberry Pi Repetier Server that I have not had an issue with (Any Cubic Mega S). Not sure what changed but it makes Repetier useless if I can't manage multiple printers with it.

Repetier Autodetected the printer as:
Input Buffer: 127
Baud Rate:115200
RTS: Low to High
DTR: Low to High
Ping Pong Mode: Set to No 
Communications Timeout: 3s
Max Parallel Commands: Unlimited

One thing I haven't tried was to replace the PI power supply. Not sure if this would improve USB communications speeds. I have not found a way to upgrade the firmware - stock Marlin 1.0.

Any help that can be provided would be appreciated.

Dana 

Comments

  • The solution in such cases is always the console with disabled filters or even better activate logging and check the log. Communication is most likely still fast enough - blobs normally happen with communication errors and if the suddenly get higher, something is most likely wrong in communication settings causing more errors. E.g. if you send more then buffer can hold you get many resend errors. If you see "ok" responses get corrupted this will cause timeouts. So check log for that and if it is so obvious there is most likely a pattern.

    As first try select ping-pong which is normally the most reliable solution as it will not overflow commands. Only thing is it will timeout on every missed "ok" while parallel commands time out on 2 missed "ok". 
  • edited November 8
    https://drive.google.com/file/d/1Bwo-oKwvxez7VRzXltLgadShlaNAg81E/view?usp=sharing
    https://drive.google.com/file/d/1jeGOO9O4AVPnN5w5U_kXUgTdkleVedlU/view?usp=sharing


    Hello Repetier Team, I had Repetier Server "test multiple configurations" and selected the configuration with Ping-Pong mode. Three of the 4 test configurations showed "green" with no packet losses. The 4th errored out (baud rate too high). 

    I ran a test print of a small file - one of the penguins of madigascar. I had printed this file from the micro SD and it printed perfect - with tree support for the beak. Printing through Repetier (same file) using Ping-Pong mode worked better, but the print head paused as it printed instead of being a continuous print like it does with my Anycubic printer.

    The print was complete, but had filament blobs all over the bottom half of the print.

    I provided a link to the log file. There are lines that say - switching to slower mode, and many lines that say "waiting" in the beginning of the print.

    The 2nd file shows the current configure settings. The Sunlu S8 works well from the micro S8, most of the prints through Repetier end up in the garbage.

    Thank you,

    Dana
  • Hello. If a print has complex layers ping pong mode can be not optimal. Did you tried with the highest possible buffer configuration whidch is green? 
  • I'll run the print again and capture the log with ping-pong off and printer set to 127 buffer.

    I had the ping-pong off, and the buffer at the highest setting "127" when I was having all the issues with it pausing 5-10 seconds continuously while printing - making the print take about 10X the time needed to print an item, and the item had blobs all over it like.

    Dana
  • Ok, the thing is quite clear. The blobs are your timeouts as it seems. There are so many that this must be the case. It always looks like this:

    Send:19:21:39.800: N186209 G1 X139.791 Y146.312 E2817.08945
    Recv:19:21:39.813: ok
    Send:19:21:39.814: N186210 G1 X140.269 Y145.657 E2817.10293
    Recv:19:21:39.827: ok
    Send:19:21:39.827: N186211 G1 X140.806 Y144.994 E2817.11712
    Recv:19:21:39.840: ok
    Send:19:21:39.840: N186212 G1 X141.349 Y144.389 E2817.13064
    Recv:19:21:40.132: o-  T:200.00 /200.00 B:59.78 /60.00 @:57 B@:127
    Recv:19:21:41.132:  T:200.07 /200.00 B:59.75 /60.00 @:56 B@:127
    Recv:19:21:43.133:  T:200.03 /200.00 B:59.77 /60.00 @:57 B@:L    T:199.97 /200.00 B:59.74 /60.00 @:59 B@:127
    Mesg:19:21:43.841: Warning: Communication timeout - resetting communication buffer.
    Mesg:19:21:43.841: Connection status: Buffered:45, Manual Commands: 1, Job Commands: 5000
    Mesg:19:21:43.841: Buffer used:45 Enforced free byte:0 lines stored:1
    Send:19:21:43.842: M117 ETE 01:45:43
    Recv:19:21:43.846: ok
    Send:19:21:43.846: N186213 G1 X141.945 Y143.788 E2817.14472
    Recv:19:21:43.855: ok

    Not sure why but it seems when ok and temperature are reported same time it writes o- Temperature. That is no correct firmware response, but it is happening all the time.
    Recv:20:31:49.690: o-  T:200.07 /200.00 B:60.38 /60.00 @:56 B@:0
    Recv:20:32:02.714: o-  T:200.21 /200.00 B:59.87 /60.00 @:54 B@:127
    Recv:20:36:13.088: o-  T:200.10 /200.00 B:60.42 /60.00 @:55 B@:0
    Recv:20:41:07.595: o-  T:200.03 /200.00 B:59.92 /60.00 @:56 B@:0
    Recv:20:45:06.991: o-  T:200.14 /200.00 B:59.78 /60.00 @:54 B@:127
    Recv:20:46:57.134: o-  T:20r   zN  r    B:60.45 /60.00 @:55 B@:0
    Recv:20:48:00.201: o-  T:199.86 /200.00 B:60.51 /60.00 @:60 B@:0
    Recv:20:54:48.775: o-  T:200.00 /200.00 B:60.27 /60.00 @:59 B@:0
    Recv:20:55:16.817: o-  T:200.07 /200.00 B:60.43 /60.00 @:55 B@:0
    Recv:20:55:34.862: o-  T:200.24 /200.00 B:59.70 /60.00 @:52 B@:127
    Recv:20:56:05.910: o-  T:200.17 /200.00 B:59.84 /60.00 @:53 B@:127
    Recv:20:58:46.157: o-  T:199.89 /200.00 B:60.28 /60.00 @:60 B@:0
    Recv:20:59:11.171: o-  T:200.00 /200.00 B:59.96 /60.00 @:58 B@:127
    Recv:21:02:36.485: o-  T:200.  z & r    B:60.10 /60.00 @:56 B@:0
    Recv:21:02:44.488: o-  T:200.03 /200.00 B:59.82 /60.00 @:57 B@:127
    Recv:21:02:54.490: o-  T:200.03 /200.00 B:60.25 /60.00 @:57 B@:127
    Recv:21:03:25.536: o-  T:199.94 /200.00 B:60.15 /60.00 @:58 B@:0
    Recv:21:04:19.602: o-  T:200.00 /200.00 B:60.52 /60.00 @:56 B@:0

    Sometimes temperature response is defect as you see in above lines from log. So it looks completely like communication errors also very repeatable, which is the strange thing. Except a few of these errors all are the same.

    What firmware is it you have selected? Marlin?
    In your install folder in /usr/local/Repetier-Server/firmware/marlin.xml after line 211 which looks like this:
    <response type="ok" value="-1">^ok\s*N?:?(\d+)?</response>
    you can add
    <response type="ok" value="-1">^o- </response>
    and restart server. Then the timeouts will be gone, because you have marked the defect "o- " response as well as "ok". I see this as hack, bus as regular as this happens it would help here. Or find out why you get com errors like that, but if it is inside firmware there is no other solution.



  • https://drive.google.com/drive/folders/1xejavPeT3J8ag-X5gy8aNOrl-A5YtMb-?usp=sharing

    Video: https://photos.app.goo.gl/bbZAAsvUoyP1LuXx5

    Hello Repetier Team,
    In the attached links - I added the log from my last print with ping-pong off, printer configuration, and a link to the video clip that shows the print head stall over the print. It had hundreds of small print blobs all over the print. I found a print summary report and it said there were zero errors, but it couldn't detect temperature (odd because it showed it in the graph it generated through the print).

    I'm a novice when it comes to Linux. If I can edit the xml file by loading it into a windows text editor it should be fairly simple. If I have to make the changes at a Linux command prompt then I'll have to research on Youtube. Can a code be added to Cura - Machine:Start Gcode to address this issue as a temporary fix?

    The Sunlu S8 firmware is Marlin based - I believe V1.0. The original Repetier when I made my purchase worked well with the printer. After software updates it had been having the printer pause issue. The Anycubic Mega S that is also on this Pi server works perfectly (detected at a baud rate of 250K).

    I also have a 3rd printer that I would like to set up with Repetier - Qidi X-Max. When I bought it I thought I could connect it via USB port. After talking with Qidi they said that USB is for bootloader and storage. I have it networked (wired) and can't seem to connect it via TCPIP using Repetier. They sent me a video on taking apart the bottom of the printer to tap into the controller UART port, and from there an a TTL adapter to USB. Please let me know if there is a simpler way to connect this printer to the Repetier server I have.

    Thank you,

    Dana



  • Intersting, found also this
    Send:19:06:40.102: N161193 G1 X178.522 Y152.018 E3196.07992
    Recv:19:06:40.132: o- ok
    Recv:19:06:40.796:  T:199.91 /200.00 B:60.27 /60.00 @:60 B@:0

    So still starting with "o-" then followed by the "ok" it should have. In that log 50% are that way the other 50% are without "ok" but also with "o-" so the fix I told you would work.

    Easiest solution is to login via cmd.exe running
    ssh pi@ipnumber

    and then run
    sudo nano /usr/local/Repetier-Server/firmware/marlin.xml
    which opens a text editor that has the important shortcuts written at the bottom. Only one you need is save and exit (ctrl+x) once you have added the line.

    This is no server issue, that is what we receive and it is just wrong. But at least with the fix you compensate that.

    How did you update? New image or just autoupdate to latest release? Ne wimage has given you new linux version with new driver, so it might a problem in driver. But it is strange that it is always in combination with "ok" and sometime inside temerature.

    Did you change anything else? Other usb port, different cable or cable position on table. Other cables now crossing cable.

    For the Qidi it seems that network port 3000 outputs serial data. Someone propsed to put in /etc/rc.local

    sudo -u pi socat -d -d pty,raw,echo=0 pty,raw,echo=0 2>&1 > /dev/null &

    sleep 3

    sudo -u pi socat -v udp4-datagram:192.168.0.30:3000 open:/dev/pts/1,raw,nonblock,waitlock=/tmp/s0.local,echo=0,b115200,crnl 2>&1 > /dev/null &


    with 192.168.0.30 the ip of the printer. Don't like that it is udp as that does not guarantee correct order or receiving all data. So better first try our tcp with port 3000. Maybe they support both. But is seems true that the usb is not for serial communication and you need the adapter hack otherwise.

  • I did the Repetier update via the console auto install method. I was trying to preserve the printer and camera settings. I have a print job running on the anycubic Mega S. When that finishes I'll reinitialize the micro SD card and do a clean install of Repetier.

    For the Sunlu S8 - I tried it on every USB port on the Pi both USB 2/3. I tired 4 different cables, and purchased a high speed USB cable from Amazon that didn't improve the printer stalls. The new cable is now on the anycubic. This is a Raspberry 4 with 8 GB of ram, not sure if that makes a difference.

    The other odd piece is that the Sunlu S8 worked perfectly with the filament sensor on the earlier version of Repetier. I had to disconnect the sensor as it kept ejecting the filament at the start of a print job, and wait for me to reload the filament and it kept doing it over and over. I ordered and replaced the sensor and it kept doing the same thing - so the cord is pulled. The anycubic Mega S has a filament sensor that doesn't work with Repetier (disabled). I thought it worked on the earlier version - but it doesn't seem to do anything. 

    I'll start with reimaging the SD card for a clean start image, then try the command line workaround if I continue to have issues. 

    Thank you for your assistance,

    Dana
  • Hello Repetier Team,
    As a follow up - I completed a clean install of Repetier on the Raspberry card micro SD card. The clean install didn't fix the Sunlu S8 "freezing" issue when printing. I searched the internet and found firmware that someone put together for the Sunlu S8 that was configured using Marlin 2.0. I used Repetier to flash the firmware and it appears to have fixed the freezing issue. There is a bar that pops up on repetier that says something about processes running too slow and are being processed offline (something to that effect). Not sure what it means but I've been able to print through Repetier without all the blobs on my prints. 

    I was hoping the changes I applied would have faster throughput on the Sunlu S8, but no improvement. The Anycubic showed faster speeds after the clean install of Repetier.

    Dana
  • The slow precesses running are unrelated. These are computing renderings of uploaded gcodes that are running in background. It is just a hint why you see not some images that should be there.

    Good to know that new firmware helped here, so probably a problem in firmware. Did you try throughput test with new marlin 2 version? Parallel commands have normally a good improvement.

    But the biggest difference makes converted serial vs. native usb board and sometimes the driver add higher latency, so serial converter driver can also have influene - apart form baud rate.
Sign In or Register to comment.