Just for the record and to have chimed in on this thread "officially":
Just opening the UI in a browser should actually not produce blobbing. Everything gets cached agressively to avoid just that, however I can't vouch for third party plugins, and in completely fresh browsers caching won't have that big of an impact, so yes, that can happen, though in general it shouldn't really.
I'm well aware of the GIL, I'm well aware of possible work arounds for it, and yes, all of that is on my TODO list. But considering that I'm running this project pretty much alone things take time.
A BUFSIZE of 4 is useless. I've successfully tested BUFSIZE of 32 - even on 8 bit boards without issue.
A BUFSIZE of 128 is possible (but probably too large) on most 32 bit boards.
A patch is pending for Marlin to remove delays caused by a planner sync (ie buffer flushing) on issue of an M114 command. This also leads to micro-pauses and blobbing.
Trying to blame issues for incorrectly configured and tuned Marlin on Octoprint is just silly.
Do whatever you all want. I'll refrain from posting any findings in the future. The facts are that if the data never stopped being sent the buffer size is irrelevant as long as there is one.
Since this is a known issue that Octoprint presents I'll just make sure to have workarounds in the firmware to try and mitigate issues with Octoprint stopping the sending of the serial data for whatever reason. The default BUFSIZE in Marlin is 4, look at their base config.
That all being said I will not be publishing any more findings or wasting more of my limited time testing the issue since you all just seem to want to deny there is any problem here. I spent a lot of my time to narrow down the issue. Presented facts showing that the UI loading causes the blobs and you all still want to argue with me. There is a video on our YouTube channel showing the pausing happening when the UI is loaded. Increasing the BUFSIZE does "fix" this but it's really just covering up the fact that Octoprint stops sending data sometimes and that is why the blobs occur.
Same goes for me. I try to put forward info that you clearly did your homework on for the benefit of everyone and all you get is a bunch of butt hurt comments from everyone but the actual developer. And the kicker is that it's clear that most comments are by people who clearly didn't read the entire document that I posted or they would know that you were not blaming anyone, but rather reporting a finding that you can easily reproduce. In fact I've been able to reproduce it myself.
What ever... I'm done trying to be helpful here. Sorry Gina but it's just not worth my time dealing with the people that inhabit your forum.
There is a difference between default config and recommended.
As an example, the BTT based board example configurations have a BUFSIZE of 32. It is set that high for a reason. With any decent printing speed and the default Cura resolution (0.05mm), 4 commands can equal a whole 0.2mm. There quickly becomes a point in curves when even 115200 baud can't keep up with tiny steps - hence you have to have pre-buffered commands if printing via USB. This can even be an issue on SD card printing - let alone any other issues caused by factoring in a Pi etc.
ARC support is required to fix this problem - but I'm not aware of any common slicers that actually support it.
If you do chose to base everything on the default config, you should realise that the defaults are constrained to run on 8-bit boards with much less RAM than the boards you are building.
Yes, you did do work to show issues - however in most situations, your findings are tainted by badly tuned firmware parameters that drastically amplify the problems you were seeing.
Whichever board you are working on, if its an STM32 based, you should easily get a BUFSIZE of 64 to even allow tight and smooth curves at higher print speeds - and this even works with Pi's older / lower spec'ed than a Pi 3B+.
To assist with your research, I'd suggest enabling ADVANCED_OK which will show you the Planner Buffer (P) and Serial Buffer (B) available space to find other issues. Ideally, P should be zero, and B should be your max-1. That can easily be achieved on even 8bit MCUs.
Yes, I'm not surprised that you saw issues with the settings you used, but yes you can mitigate the majority of these issues with correct configuration in how you build Marlin.
Oh - and the other issue you might be facing if you have an attached TFT that grabs the current print head location via M114 causes the planner buffer to be emptied before reporting the position. This also causes blobbing.
That's fine and dandy but the core issue why we need a large buffer is because Octoprint fails to consistently and smoothly send the data. Not everyone is running a 32bit board either so the boards cannot handle the larger sizes. I'm going to run a very large buffer on our EZBoard firmware in the next release but based on the test compiles people with 8 bit boards are not going to have a very good chance when many options are enabled.
Seriously, acknowledge that the actual problem is the data flow being interrupted from Octoprint to the printer board. That is the issue here. The buffer is a workaround, not a proper fix for the actual issue. It would be like my electric company telling me I should have a huge battery backup for my house when the issue is that the power keeps dropping out. If you cannot see that then I am 100% done here.
Yes. It can be - although even on a Pi2 I wasn't able to reproduce this with correctly tuned Marlin.
The truth is that its a lot more complicated than you seemingly want to admit. BUFSIZE of 4 can even stutter when reading from SDCARD - so then it depends on the print resolution and slicer settings to ensure a smooth print. So again, the solution is to increase the buffer sizes - which also is the fix (or workaround if you prefer) for printing over USB.
If you have a TFT based screen that does M114 for position retrieval, then up until now (literally, an hour ago), then this still wouldn't have helped you due to how Marlin handles M114 commands.
I am consistently able to reproduce the issue with a BUFSIZE 4 on any Pi. That BUFSIZE is going to get changed in the releases I maintain to as high as the boards can support without crashing or exceeding limitations of the CPU. So for 8 bit boards there are going to have to be some compromises in features and the BUFSIZE, which can be accounted for in the firmware.
Absolutely. I don't notice the issues with S3D sliced files. It seems to not use as much detail for the line segments in the default profiles. But that's an issue to tackle in another thread on another forum.
Not using TFTs on any machines, not a fan of them at all.
Keep in mind that I don't believe the STM32 CPU supports EMERGENCY_PARSER - which means the more buffer space you have, the long it will take to cancel a print. I'd suggest 32 or 64 as the highest. You'll probably find your issues with buffering disappear completely at those sizes.
Agreed - and this is where suitable CPUs & RAM vs wanted feature sets is so important. The 1284p is pretty much the lowest possible MCU that can do a basic feature set - and even that is borderline.
I'm thankful the BTT boards can do 512K flash - as even with a reduced featureset (no neopixel support etc), you can easily exceed 256Kb in program size.
I don't have any branches with the STM32, we're using the LPC1769 which does support that.
Be careful. There have been multiple reports of people using those past 256K and the watchdog stops working due to corrupt memory (which is why it was disabled in the first place) and heaters getting stuck on. I've got 512K on the LPC we use so its not an issue, actual 512K not a hack.
The Air Force sent me away to a one-week class called Black Box Troubleshooting, a part of my 7-level training. I would suggest that it was a formative experience for me. The technique allows one to troubleshoot a relatively unknown system of connecting parts for the purpose of finding a fault somewhere within that system. The basic idea is a binary search based upon a series of litmus tests to follow the bug.
What we're chasing now is just like that. It's a problem in a relatively unknown collection of software and hardware and we need a systematic way of finding out what's causing it.
Earlier, I mentioned that we need a litmus test: Marlin-with-SD versus Marlin-streaming. To assume that OctoPrint is the only streaming software without testing others seems to be trying to take a shortcut. When you jump ahead several steps—having not tested the same rig with Repetier—then you assume that OctoPrint causes this based on the testing you did accomplish.
I do think we need to back up and review any software that could stream to Marlin. If the same hardware rig stutters across-the-board while streaming with the default Marlin BUFSIZE, for example, then we should table the discussion about OctoPrint for the moment and follow the bug wherever it takes us.
Assuming that's the way this plays out then we can always return to OctoPrint later, the browser and those thoughts as something to also check.
This a curious thing. I run the latest Octoprint on a RPI 2 for my Anet A8 that's has the older Skynet firmware (2016). I run 36 hours prints with the Octoprint website open watching vid while recording timelapse and even accessed the remote vid while at work and I have never noticed this issue. I'm curious what my buffer size is set too; it's whatever Skynet firmware is defaults too. Guess I'm glad I never upgraded to latest marlin
