Prints are pausing and causing a "blob" effect when it happens on the sides. It doesn't seem specific to any particular long lines or sharp corners.
The current "Resend Ratio" that this is causing as an example is still 0% but sitting on 759 / 458.5k
What did you already try to solve it?
Through the Octoprint Discord, I have had a few suggestions:
Slowed down the printing speeds.
Changed USB/MicroUSB Cable (Although I have already ordered a better quality one recently which has yet to arrive to rule this out completely as I know it can be hit and miss)
Had suggestions at changing the Baud Rate but my Ender-3 MAX does not talk to 115k, only on 250k (And it was suggested to me to try 115k, but Octoprint never connects to it). The AUTO option also defaults it to 250k as well.
RX_BUFFER_SIZE from the Firmware (Present in Marlin FW 2.0.9.1)
Have you tried running in safe mode?
Not yet.
Did running in safe mode solve the problem?
As above.
Systeminfo Bundle
Attached to the post. Although the specific blobbing error in the Terminal log is this:
--- too many lines to buffer, cut off ---
Recv: T:199.91 /200.00 B:60.00 /60.00 @:84 B@:31
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
OctoPrint Version: 1.6.1
OctoPi Version: 0.18.0, running on Raspberry Pi 4, Model B Rev 1.4
Printer: Ender-3 MAX
Firmware: Marlin 2.0.9.1 with BLTouch options enabled
Browser: Google Chrome
Operating System: Windows 10
Current BUFFER options in the Firmware are as follow: #if BOTH(SDSUPPORT, DIRECT_STEPPING) #define BLOCK_BUFFER_SIZE 8 #elif ENABLED(SDSUPPORT) #define BLOCK_BUFFER_SIZE 16 #else #define BLOCK_BUFFER_SIZE 16 #endif #define MAX_CMD_SIZE 96 #define BUFSIZE 4 #define TX_BUFFER_SIZE 0 #define RX_BUFFER_SIZE 128 <- This is the only option that has been altered from default from 0 (The default for the system when set to "0" was 64)
All other options in the Firmware in general, with the exception of offset numbers and BLTouch/CR-Touch options, have also not been altered.
Plugins Installed:
(My Installs)
Creality Temperature (1.2.4)
Creality-2x-temperature-reporting-fix (0.0.4)
The 2x above i've been informed aren't needed, so I will be removing these for another test shortly if you think they could be having an effect.
Octolapse (0.4.1) - Although this was confirmed to be completely disabled at the writing of this post and through numerous tests/changes to ensure any Camera/information wasn't slowing something down.
Arc-Welder (1.0.0+u.bb71e8f)
(Defaults, as installed by the OctoPrint Install Process, if you needed them at all). To my knowledge, these are the latest available updated versions.
2021-09-18 17:35:01,801 - octoprint.server - INFO - ------------------------------------------------------------------------------
2021-09-18 17:38:51,642 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
There is quite a time gap. Please don't do that. We need all information in the logs.
Also the serial.log is not enabled. You may do that too for that also helps a lot.
You have a lot of checksum mismatches and communication problems.
Check for short and good USB cabling from the Pi to the printer
The source of your blobs is definitely the repeated communication errors. You've got timeouts & resends, which points to general communication problems.
There's lots of things that can be changed that could cause interference. With an Ender 3, check this:
Also check the USB cable is high quality, and that the electronic connections are all solid with decent ground to reduce noise.
octoprint-systeminfo-20210919002202.zip (1.4 MB)
Have attached the report from the print I did just a moment ago with the Serial log enabled. I also changed to different, shorter cable. The print seemed to be better in quality until the very end where it squashed out 3 blobs all together and messed up the head of the print...I think it was toying with me and getting my hopes up. The resend ratio was 28 / 53.1k...so I think still at the same rate as before.
I was also leaning towards a cable, so i've already ordered a gold plated, ferrite bead cable of about 1M since 0.5 I don't think will be long enough to reach around the printer. But if i'm desperate I will order the 0.5 afterwards and have my Pi hug the left side or something.
As for that Ender 3 case...I did see that already. The Ender-3 MAX, whilst not that popular yet, definitely went through some much higher quality control standards it seems. No plastic, the cables are tight and tidy by default, I have zero squashed cables, certainly none at any funny angles like that. My resend ratio is also no where near those levels (He mentioned 36%). I have a measly 0% drop, so whilst it is somewhat affecting my print quality, certainly not to that level.
But in the interest of keeping my options open, some people in there mentioned shielding the cable, so I will keep it on the table. Do you think maybe a back plate for the LCD screen would be useful? I hadn't got around to doing that yet as I was only going to for aesthetic purposes.
Use an Official Raspberry Pi power supply; there was some confusion about signalling on early models which meant the USB-C power port didn't behave well (or at all) with some chargers.
Use the USB2 sockets (black) rather than the USB3 since these also can be buggy.
Turn off Bluetooth and WiFi if you can, there is a known interference problem with the USB3 ports. Eventually buy a WiFi or BT dongle if you need them.
I do notice that when my Pi is online (And the printer is turned off) the LCD screen still turns on because I assume the power is coming through the USB. But I do make sure to unplug the Pi first before turning off the Printer and vice versa, I don't plug it in until the Printer is on.
I do use WiFi (Although it is possible for me to turn off), but I wasn't sure if that effected any jobs or just effects the connection to it's web portal.
I'll be getting my new comms cable today hopefully soon, so i'll try that and move on to suggestions
I changed the comms cable, same issue still (Although I think ever so slightly improved?!).
I have now plugged up the power socket of the USB Cable, and I think it's in the right positioned because although the Printer LCD Screen came on, nothing else did...maybe a small current still passes through.
Running a test print now, but i'm also popping out to get some cabling from work so i can also get rid of the WiFi requirement. If I plug in a cable, will I have to reformat the Raspberry Pi considering the WiFi information is in the coding? Or will it react like a normal PC and default to Ethernet itself?
It should automagically use the Ethernet socket. Once you are sure that it"s OK you can turn off wifi completely.
I really recommend blanking off the +5V, it's not good having both ends of the cable trying to supply 5V. Before I did mine I had to disconnect, reboot the Pi and the printer before reconnecting before each print.
I don't think i'm specifically suffering from this 5V issue is terms of operating things. But I have blanked it with some electric tape, and it also hasn't helped with the blobbing issue. Just trying to re-wire some things now and try without WiFi, also going to re-build the Pi in the meantime to ensure no settings of WiFi exist still.
Good news! Just did a print of at least 100k sent commands, and not had a single resend.
Here is my checklist of what i've done:
Bought a new/high quality USB Cable.
Covered the Power line of the USB Cable with Electrical tape. I'm assuming just going into the Raspberry Pi and disabling power output of all the USB ports would work equally as well.
Disabled WiFi.
Re-formatted and re-installed Raspberry Pi and OctoPrint (With all previous plugins as it was before).
The most significant was most likely the Disabling of the WiFi. I now have a Camera plugged in, and I also purposely didn't use Arc Welder to reduce the amount of moves, and it's definitely working ok.
Thanks for all your help Hopefully this goes a long way for other people who may have this issue.
What controller board is installed in your ender 3?
I had a similar problem when I fitted a BTT E3mini v2 control board to my Ender 3.
The fix was to change the priority of the USB serial port in Configuration.h file in marlin.
Old #define SERIAL_PORT 2
.
. #define SERIAL_PORT_2 -1
I have a Makerbase MKS Gen L Ver 2.1 controller in my printer using Repetier firmware and am using a Raspberry Pi 4B running Ubuntu 20.10 and octoprint to mange the printer. Pi connects to the printer via USB, and on my LAN via wifi.
When I was setting up the firmware I realized that for a 3D printer, speed of communication is not really important since it takes time to actually do the print commands. What is important is accuracy of the communication.
I set the firmware to a fixed 57600 baud and have never seen an error reported in the resend ratio of octoprint, nor have I seen any visible errors in the prints produced. Recently I have printed several large items that have required as much as 3 days to print. The most recent had a shell 190 mm X 260 mm X 200 mm.
My background is as a computer tech with extensive experience using serial IO modems in the 90s when most internet connection was via dial-up. Over the years I learned that the best speed (baud rate) to use is the fastest that gives no errors. Since the printers use serial IO over USB it still falls back to the need for clean signals.
My suggestion would be to try reducing the connection speed in the printer firmware to 57600 baud, try that and see what benefit you may gain by using a reduced connection speed. Even a 28800 baud connection would be seriously faster than most printers are able to process the print.
One other thing to note: Sometimes communications to the printers is more reliable when using the standard ANSI baud rates than it is with the in-between speeds common today.
The only downside to using 57600 is that objects with lots of short segments may print faster than that baud rate allows. This is serial protocol over USB so with a good USB cable your printer should be capable of a higher speed.
Just be aware that artifacts like blobs and zits in the print are often seen when the communication isn't getting commands to the printer fast enough.
True, but that supposition implies that the printer is physically able to print faster than the data could be transferred at 57600 baud. If faster data rates cause resend errors then the resends could cause delays and hesitation in printing movement with the resulting blobs. The fastest possible data rate may not be the best if it introduces errors.
Good data cables, an octoprint server that is not overloaded, and good data transfer rates all work together for clean and reliable printing.
My recommendation has always been the fastest data rate that does not introduce errors. 57600 is simply a starting point for me.
This victory was actually rather short lived The issue returned shortly after, and it turns out to be Octolapse itself. If I disable the add-on and send jobs through Octoprint, I don't get any blobbing it seems.
However, with Octolapse (I didn't even get a Camera running or anything being recorded, just simply active) the blobbing occured. I've read somewhere that improvements were made when they used a better SD Card, although this was more specific around the Class of the SD card. The stock Raspberry Pi SD Card is Class 10, but would it perhaps benefit to run with a Samsung Ultra or something?
I would assume the same, but then how are others printing without an issue. I haven't cheaped out anywhere and bought a Raspberry Pi Zero for example, I did ensure to buy the latest Pi 4B+ and turned off as many resources as possible such as the WiFi receivers etc because i'm cabled in.
I also turned off power output from the USBs since i'm running a Camera Module so any outage didn't interfere with the cable (Also still have electrical tape covering the power line of the USB to make sure it's not outputting anything).
I'm currently waiting for cooling/heatsinks to arrive to install those across all the components to see if that helps at all as well, although I already have one attached to the CPU, but I am waiting for the better case to turn up with the better more directed fan, but I can only see this having a fractional difference.
Unless the Pi was reporting overheating or undervoltage issues, it doesn't throttle it's speed. It will always warn you if it's having issues, OctoPrint reads the warnings and relays the info.
Agreed the CPU shouldn't be an issue with the Pi 4. The SD card can be the issue, since if OctoPrint can't read from it fast enough (it does try and use a buffer) it might cause stuttering. It's not often likely but if you have a spare one might be worth a try?
The issue returned shortly after, and it turns out to be Octolapse itself. If I disable the add-on and send jobs through Octoprint, I don't get any blobbing it seems.