Zits/Blobs & Performance

Hello,

I am an avid user of Repetier Server and now a huge fan however I notice when switching to Repetier my prints especially in round areas how blobs / zits.  This looks like maybe a buffer issue.  I am using a Raspberry Pi 3B+ and it is headless, I am not seeing the memory or processor usage spike too high.

What can I do to remedy this, do you have any suggestions? In settings I did not see any way to disable features to speed up everything.

I have 3 printers connected via USB.

Comments

  • You should enable logging and check log for errors. iff it is server related it, it is normally that you have communication errors. One blob per timeout. Communication is done by linux in this case so we have no influence just work with what we get.

    For best performance there is now in printer config a test function that tests several methods and buffer sizes and checks when we get com errors so you can select the best working without frequent errors. Normally 127 byte no ping pong.

    Firmware wise you can compile a version that sends line number with "ok" and wait when idle. This is to help server detect problems more quickly than with timeout.
  • Thank you.  So I made a few notes... first - if you use the raspberry pis without a screen it's best to edit the repetier-config on the SD Card and disable the RUN CHROME option aka 0 so it saves lots of performance.

    Also, my issue was hardware - my one raspberry pi for some reason has this issue.  I got my other one which is just a 2 and flashed it, set it up and it's perfect, no performance issues.

    I think the built-in wifi on the Raspberry Pi 3B+ may be the issue.  On the RPi2 I am using a USB adapter from Tenda and it does not fail.  I believe the internal wifi locks up processes / resources on the 3B+ - maybe a kernel or driver issue. 
  • I have noticed too that I get random blobs/zits. I am running the latest RPi 4 with 4GB RAM and have two printers normally running concurrently. I use the Wifi builtin.

    I installed the 1.0.4 RPi Image and updated to the beta (ARMEL, but I think thats wrong) then 1.1.0 then manually to 1.1.2. I have a docker running with Home Assistant that I use for remote viewing of RS + Cameras + Temp Sensors + KASA KP115 for energy usage.

    If I execute, stupidly, a Docker update or similar there is a noticeable wait on the printer for that read/write to occur on the RPi. I would maybe suggest a higher speed SD Card.

    Overall, it seems very random when I get a zip/blob. But it does happen.

    I am looking at moving from the RPi to a second hand Dell Optiplex i5-4th gen 8GB RAM but not sure if I can retain the touch screen web interface. This will then enable me to get klipper up on the 3rd printer without a resource issue.
  • @twobit - I run a large farm, and we use many pis, and it's been over a week of testing Repetier and I have gotten great performance at this point.  I have one particular Pi 3B+ which has no known hardware issues, yet it has serious zit/blob issues with Repetier.  Works fine with other print servers (will not name for respect).  I tried different known working power supplies to no avail.

    I have two theories at this point:
    1. It could be an issue with the SD Card.  Maybe the SD Card in the pi is aging or has bad sectors, etc.  I would say try another card.
    2. It has to do with the built-in WiFi drivers.  The other Pis I use simple USB WiFi sticks and those have no issues.  It could be a coincidence, but there are known issues with built-in WiFi on the pi's locking up process priority on some old Linux kernels, it could be that.
    In the end I am on a RPi 2 with 1GB ram, stock power supply - open air case.  It's handling 3 printers (I have taped over the ground USB pin on all so they dont draw power from the pi - this is a good practice in general) and it's been a week of perfect printing with no reboots.  The printers run 24x7 and print large and small models including some very complex Gcode and I have had 0 performance issues.

    I have "rescue" turned on and all stock options turned on.  The only thing I turned off was the "Chrome" instance, which can be done via the boot partition on the sd card in the repetier-server setup text file.  This saves considerable resources since I do not run a monitor connected to by Pi.  I do run the awesome touch mobile interface built in on a tablet though and it's beautiful and fast.
  • >  (I have taped over the ground USB pin on all so they dont draw power from the pi - this is a good practice in general)

    Sure you did ground? We always tell to tape the 5v so all devices still have same potential for data lines but do not draw power. I'm not that big in electronics, but that is what I always read. 
  • Yeah ignore me, maybe it's the 5v, I followed the guide on your website.
  • edited August 2021
    luis84 said:
     I do run the awesome touch mobile interface built in on a tablet though and it's beautiful and fast.
    I thought the TouchUI was localhost only (http://localhost:3344/modules/front2/www/app.html/) , how did you get it to a tablet?

    I have been having some issues with my new Ender 6, not a RS issue but rather a PSU problem with multiple printers and the RPi getting unhappy. Resolved at last.

    Do you have any webcams/timelapse setup on the RPi?
  • edited August 2021
    @twobit ; - On the stock Repetier-Server image for RPI the touch UI works fine for my whole network, all I did was replace "localhost" with the IP of my RPi (I gave it a static IP via my router).

    Repetier-Server also appears to use Nginx, so you could just configure the rules to allow the TouchUI for the whole network if you installed Repetier-Server some other way (not using the image but the .deb for example) and the rules are off.  However, yep, on the stock RPi image for Repetier-Server the TouchUI works on whole network.

    Also on Android, once the UI is loaded in a browser go to the "3 dots - hamburger" menu and click "Add to Homescreen" and then Android adds it to the home screen, and it works like a full screen app with no annoying nav-bar.  Absolutely epic.
  • Thanks. I get "For security reasons this page can only be called over localhost IP!" it was the 1.0.4 RPi image, but I have manually loaded the 1.0.5 beta and since used the auto update to 1.1.0 then due to a bug the manual 1.1.2 upgrade.

    Ill look into the Nginx to see what lets me in.
  • Twobit - if you use the newest image it should work? Maybe review the URL, my RPi is running at 192.168.0.7 and via any computer on my LAN I can open it with:
    http://192.168.0.7:3344/modules/front2/app/app.html/

    The port is important to add.  If you have a segmented network aka router and then another AP with routing enable it may be segmented so even though you "see it" as one network, it's not.  My home network is a single router (built into my modem) and then Ubiquiti AP's with all DHCP off so only one main router.
  • I believe the issue is I have users setup on the RS itself which blocks the access for security reasons. I have users as I exposed my RS installation via Dataplicity so I can monitor it remotely. My internet is behind a CG-NAT and no accessible IP address/easy VPN setup; so a tunnel was my best option.
  • ^That could indeed be the cause.  You could just reconfigure Nginx, there is actually an example help page I just found (I was about to write one for you lol): 
    https://www.repetier-server.com/webserver-access-repetier-server/
  • However note in the above link there is a line:

            location /mod/front/ {
                    deny all;
            }
            location /modules/front2/ {
                    deny all;
            }
    
    That will need to be modified or else it won't work.  You can switch the modules/front2 to an allow or do a universal allow for your LAN segment:
    allow 192.168.1.0/24;
    
    You would just need to adjust the LAN segment to match yours.  You could also if you wanted allow it over the internet
    and add a user/pass via nginx but I would not suggest exposing to internet.
Sign In or Register to comment.