›

RX Buffer Full - Pi4

wabbitguywabbitguy
in Repetier-Server
Repetier Server 0.94.3 on my PI4 (4GB) every few days grinds to a halt with a last console message of: Full RX Buffer

There doesn't seem to be any way to get it going again and the printer just sits there, heated up and doing nothing. I have to reboot the server to get it going again and it doesn't resume.

For the push messages:

When using @pushmessage, on my phone I see the title "Message from printjob" and then under that the actual message I sent which is printer specific like "Delta 1 Print Job Done".

However on my iWatch it says "Repetier Server" and the message is "Message from printjob"... and with four printers running, message from "printjob" is useless on the watch and I'm not welded to my phone.

So how do I replace the "printjob" text with the actual NAME of the printer (GCODE) that sent the message so it shows on my iWatch?

Mel

Comments

  • wabbitguywabbitguy
    Recv:20:02:35.228: OOOOOOOOOOOOOOOOOOOOOOOOOOOOOO succeeded.
    Recv:20:02:35.232: LA10C: Linear Advance mode: 1.5
    Recv:20:02:35.240: echo:Advance K=0.05 (2)
    Recv:20:02:35.305: Full RX Buffer

    So it just quit four more times in a row. This is what I got in the console.
  • RepetierRepetier
    In next server release the printer name is part of title which is what you see on iwatch. You can not change that. It is just not showing the text content.

    What printer and firmware are you using? Never saw a message Full RX Buffer. RX is the input buffer so that is the size you also define in communication settings. But it could also be full when server thinks there is a timeout and sends new commands which then make the buffer full. Here a complete log including ack/send commands starting a bit earlier would be helpful to see how the full buffer happened. Since it happens as I understand at print end I assume there are some commands in the end gcode causing this somehow.
  • wabbitguywabbitguy
    Printer - PRUSA i3 MK3S firmware 3.9.2
    MMU2S - Firmware 1.0.6

    I have the input buffer set to 127. I've never seen the RX buffer full either, matter of fact it's only the Raspberry PI4 that I've seen this. Never saw it on the Pi3.

    At the moment the Rasp Pi4 is in the parts box and I'm running the server from a MacBookPro, the printers connected via a powered USB hub. Printing with the same GCODE haven't seen the RX buffer issue.

    The GCODE is being generated from PRUSA Slicer 2.3.0 Beta1...and I thought like you that perhaps there's some GOCDE in there that's causing a problem. The RX buffer full happened all the times during a filament colour change (in the waste block) but once on the second layer, the others on random layers.

    However, running the same GCODE from the MacBookPro install of Repetier Server Pro worked just fine. So I the GCODE doesn't make sense logically since it should do it on both. Maybe a timing issue since filament changes don't happen very fast...?

    Always pays to have options which is why I pushed the Mac into server duty, otherwise it just pretty sits there unused.

    If I shove the PI4 back into server I'll turn on the debugging. Kind of wondering about the PI4...not feeling the trust as I have with the PI3...And I can't live without Repetier Server Pro!!!!

    Great to hear about the next release! Thanks for the news on it!

    Mel
    ---
  • RepetierRepetier
    And on pi 4 it is also same software then on pi 3. So yes, it sounds like a timing issue cause pi 4 is a bit faster. For testing I will update my prusa and test with my pi 4 as you say pi 3 does not work. I normally have it connected to pi 3+.
  • RepetierRepetier
    So far I could not reproduce it with 1.0.x. One change from older versions is that the buffer size is not reduced to 63 byte after the first 5 errors. So what input buffer size are you using? I always use 127 byte with no problems.
  • wabbitguywabbitguy
    Now this, apart might remotely be a timing issue (I don't think it is) and the fact deltas can chew through gcode like a starving person, with 3 deltas and a cartesian running it could also be a power issue on the PI4. Which is what I think it probably is and changing the buffer size shouldn't affect that at all. 

    Having said that, I've had the PI3's and PI4's work great for a period of time and then at some point the SD card fouls up and I have to do a complete reinstall. Which reminds me, I really like the backup/restore function now!

    Repetier Server is the only server I've ever been able to use for the three deltas that can even remotely keep up the data stream for all of them at the same time.

    I got tired of microSD cards/PI's and pressed a Mac Mini into service as the Repetier Server. It's working just fine with 127 byte buffer size and through a powered hub.

    Being able to send directly from PRUSA Slicer directly to any printer on the server is just the icing on the cake.

    With the server sending out the printer name for the job finished messages is absolutely wonderful! Thank you VERY much for that addition!

    Mel
    ---
  • RepetierRepetier
    Just a note to rx buffer - it could also be the one to the MMU2. I had time ago some communication troubles with that and they also use serial communication as it seems. Since the last firmware upgrade I haven't had any big problems except that inserting filament automatically is always having a chance of failure.
  • wabbitguywabbitguy
    Ah yes the MMU, can be a problematic child. I have the MMU2S and changed the PTFE to 2.5ID throughout and used passthru PC4-m10 fittings for input, Selector and extruder (i.e. all PTFE in the MMU2S). Spent some time figuring out the best way to calibrate the PINDA sensor, the IR sensor worked from the get go. When I print, every print is in MMU2S multi-mode, even if it's a monochrome print. Haven't have any MMU2S problems other than bad filament that's gotten brittle and snapped. Even prints TPU just fine.

    Still, I'll keep an eye out on the serial line driving the MMU2S. Thanks!
Sign In or Register to comment.