The weakness of printing via USB is that gcode with many short segments can overwhelm the "serial over USB" interface. This looks like one of those cases.
The major bottleneck is from the ping pong approach. Usb adds latencies in the serial communication. A bulk/interrupt transfer is for full speed usb only scheduled every 1ms, meaning we get 2ms turnarround time at least to get an OK reply back.
This can be seen when e.g. Replacing the usb to serial with a native serial port from raspberry - I don't get any blobs anymore.
An improvement to get arround those latencies also for usb 2 serial converters would be to support the ADVANCED_OK feature of Marlin, this one prints the internal buffer status, so that the host know how much it can still feed the buffer until it oberflows.
Reporting of the availability of this feature is also done via M115.
Are there any plans to support advanced ok in future?
Still the major cause of all issues are the "interesting" choices of the communication protocol on Marlin. Instead of using one of the normal serial handshaking mechanisms, a new "ok" ping pong scheme was invented, making life much more difficult.
A nice rts/cts or xon/xoff scheme would have prevented such issues.
Best regards,
Kai
Found this here:
Is this integrated in any available version of Octoprint? E. G. one of the release candidates?
I will get my pandaPi board very soon it is a shield for the pi.
With it you can run Marlin 2.0 and octoprint directly on the pi.
Lets see if it is better ...
No, the PR is still working and has been marked to "needs more work": https://github.com/foosel/OctoPrint/pull/3209
Thanks, so I stick to my native UART approach. Btw. It is feasible to access hw wise on a raspberry pi 3 the 2 UARTs at the same time, as long as you don't require Bluetooth. The 2nd UART gpios are not accessible on pin headers, but with some reverse engineering involving raspi-gpio and a scope they can be found easily and made available with a small patchwire.
Now, that I have 2 uarts working, I don't require advanced communication anymore 
Best regards,
Kai
Does this mean that if I connect raspi directly to SKR 1.3 using RX/TX pins on both then there will be no bottleneck and quality from OctoPrint would be identical to that from SD?
It's not the connection: It's the transfer protocol and the 8-bit processor power of the printer boards that is driven at it's edge.
USB alone is fast enough and with a 32-bit board it should work quite well.
AFAIK there are not enough tests made with 32-bit boards concerning this problem (less quality when printing over USB).
I print for years on 32bit boards and never had this problem
1 Like
Great to know! And you are using standard USB connection?
Yes, usb is indeed itself fast enough in terms of transfer speed, but has no low enough latency. Speed and latency is a major difference. Due to the fact that we are not writing a stream of data, but have interruptions by the ping pong approach these latencies matter a lot and get dominant, if short line segments are part of the print.
Latency is the time between the raspberry starts a serial write towards when the serial data comes out of the port.
For full speed usb this will take arround 1ms, for high speed usb (usually 3d printer devices are full speed) 1/8ms.
Those latencies are inherent to the USB standards and cannot be made smaller.
As there is also a phase of read you'll get those latencies twice. Here it also matters which polling interval is setup in the cdc interrupt endpoint - it can in total even be more than 2ms of "pause" in the communication.
With a local serial port those latencies are much lower. You will get a few microseconds likely.
Yes, you can directly use a PI serial port and you will get much better results. Have improved 2 printers with this. They prints now like from sd card.
Developed a lot custom usb devices and usb stacks in the past, but it is up to you to trust this or not. I think we all agree to, that using a local uart will not hurt for cases, where just an ftdi or ch340 or similar usb uart is used on the orinters board.
1 Like
yes, smoothieware on smoothieboard, smoothieware on teartime modded to run it ... normal usb connection from both rpi and opi sbm
1 Like
I tried to fix a marlin 8bit printer by removing the CH/FTDI chip and going directly serial2serial and I still had issues. I believe the problem is that buffer on 8bit boards marlin make is too small and the latency that comes from 8bit board calculating checksum for verification for many short moves is what creates blobs... on the other hand arm calculates crc in hw and even if you calculate it by cpu it's still not taking significant resources compared to what happens on 8bit board... not to mention, 32bit boards run the USB on the mcu itself, so the whole CDC stack is implemented in firmware and the USB/CDC latency is actually higher than what you experience with CH/FTDI and still there are no blobs and issues with short lines so that's why I believe I'm right when I say the CRC calculation is the major issue for 8bit boards...
2 Likes
Isn't this one of the arguments to use Klipper? I've personally never used/tried it so not sure. I don't typically print much with small segments so haven't really experienced this issue myself either with my Einsy board running Marlin.
1 Like
I was planning to try klipper since it was introduced to me but can't find the time, I even follow closely their FB group but really my experience with it is non existing, I just received toolchanger from e3d and I migrated one of my printers to duet3d recently so klipper was somehow skipped ... I seen that they had same issues with short segments and is solved by something called "virtual sd card" ... I'm sure enough ppl here use klipper that they can chime in with real data 
... I delay playing with both replicape and klipper for a while as of python (takes too much energy to deal with it)
but yes, klipper (with that virtual sd thing) also do not have this problem, and is cheap upgrade as you already have rpi and your 8bit board just becomes a step generator ..
Klipper sounds interesting. Is my understanding right, that the whole motion planning is done on the PC with python and it is more or less a smart pulse generator for the steppers with some additional code for things like endstop handling,...?
Sounds interesting.
Maybe it has less #if magic and no overloaded floating point stuff for 8 bit processors (must be pain to maintain Marlin).
Can you explain, how the conversion from g code to Klipper commands work in the context of Octopi?
Damn, just have everything running and tuned nicely and now my interest is high in trying Klipper out...
take it with grain of salt but the gist is something like this: the rpi, opi, computer, whatever python runing system runs the path planner that trough usb sends stepper commands to the stepper generators ... (the input is same gcode as for marlin or any other gcode controlled machine) ... on the usb you have attached the "stepper generator and io boards" that play the ordered stepper info and get info about temperatures and gpio states ... to create these boards you can take your standard atmega board (like most marlin boards) or some other supported (they support huge range of boards) and upload special firmware to them that makes them "stepper generators" ... you can have many of them attached to single instance ... you then create a config file where you define what and where does what (what stepper on what board is what axis for e.g.) and that's it .. klipper then reads the gcode and plays it out like any other ... now since klipper itself have no "interface" it is mostly controled trough octoprint but that's where "how" that I know stopps so ..
as i have written above the pandaPi shield looks like a good solutions.
It runs Marlin directly on the pi and directly controls the motors.
there is a stm32f103c8t6 U3for controlling the temperatures because the pi doesn't have enough GPIO Pins.
You can edit the marlin config and compile it with the octoprint interface.
hopefully i will get my shield soon.
1 Like
It's definitely an interesting option. Looking forward to hearing about your results. Are you going to use TMC2209 drivers?
At first i will use it on a Makibox.
One printer isn't finished.
the other 2 work to great with the prusa firmware.
I think i will use alegro's or LVxxxx first which i have lying around.