Einsy improved octoprint from SD card (?)
Some of the Einsy discussions have me wondering something: Will the Mk3/Einsy deliver the advantages of SD card printing with the advantages of Octoprint? If not, what is missing?
It sounded as if the Einsy may improve USB->SD upload speed, which would get me half-way there. All that would be missing is periodic feedback on the current position from the Einsy to the Octoprint over USB. Wouldn't want to send full gcode back or we'd be limited by the usb-serial rate again, but a once per layer update on z-change should do it.
The other possibility would be to remove the USB bandwidth limitation and just print from Octoprint at 12Mbit/second vs 250k or 115k. USB should be able to handle the bandwidth, I'm assuming it is a ftdi usb-serial conversion that is the limiter. I'm curious what it would take for the boards to increase the available USB bandwidth.
(I've got my Rostock and Ultimaker both upstairs printing flutes from Octoprint, and I noticed the ultimaker stuttering as it approached the center of a concentric circle external infill, hence the question)
Re: Einsy improved octoprint from SD card (?)
Would love more details on this as well.
As much as I read on the topic, there seems to be a disconnect between the features and accesability, and the way it is implemented. You can choose one or the other, but there is a inverse give and take relationship.
Re: Einsy improved octoprint from SD card (?)
The limitation is the 2560 processor not the USB to serial conversion.
The processor and the lack of flow control across UART is the fundamental limitation.
This is why folks groaned when the new board was still a 2560.
Again, the part you don't seem to understand is the very processor running the printer is rather outdated and has no native high speed connection. The SD card is on the SPI bus of the processor and then all in and out communications are serial UART.
That means to copy data to the SD card you need processor cycles and move in small chunks due to limited RAM.
Then again, the OTHER issue is that the serial communications lacks proper flow control and requires processing time.
So sending a file across a serial UART to a processor, and then that same processor writing to SD card was never a good idea.
Re: Einsy improved octoprint from SD card (?)
Again, this is why solutions like using a Toshiba Flash air card, where it has it's OWN processor and network to upload files directly to the flash memory of the SD card bypassing the known limitations of the mega2560 and overall system architecture is the preferred way. While this is for a different printer, the configuration and what works is the same http://www.allaboutjake.com/toshiba-flashair-wifi-enabled-sd-card/
We are literally pushing the limits of what this rather old and outdated tech of the mega2560. Again, the same stuff was used in 2009 when I started this hobby. While yes, a lot has been done with firmware and code and cheaper and better stepper drivers- you cannot get blood from a turnip.
Re: Einsy improved octoprint from SD card (?)
Again, this is why solutions like using a Toshiba Flash air card, where it has it's OWN processor and network to upload files directly to the flash memory of the SD card bypassing the known limitations of the mega2560 and overall system architecture is the preferred way. While this is for a different printer, the configuration and what works is the same http://www.allaboutjake.com/toshiba-flashair-wifi-enabled-sd-card/
We are literally pushing the limits of what this rather old and outdated tech of the mega2560. Again, the same stuff was used in 2009 when I started this hobby. While yes, a lot has been done with firmware and code and cheaper and better stepper drivers- you cannot get blood from a turnip.
Which I assume is specifically why everyone was moaning about the lack of a 32bit solution on release?
Second hand information but, there were a few people saying that even if it were to move to a different architecture the way the current iteration works, it might not be particularly beneficial in terms of quality of print?
Is there any truth to that?
Because another commenter said that there were newer protocols that can take advantage of 32bit, and could be beneficial, particularly in the near future.
And if I am reading between the lines correctly, it sounds like it would support better backend functionality as well?
All speculation, from what little information I have been exposed to, but it sounded like this will certainly be the last 8bit board because there is nowhere to go from here?
Re: Einsy improved octoprint from SD card (?)
I understand the processor is slow/old, but if it can read at high speed from SD, it can read at high speed from any SPI device. I am skeptical that the processor is the limitation, I think it is that a slow built-in UART is used for serial/USB comms (because it is easy and has always sort of worked), while the SD card connection is over a higher speed SPI. That seems fixable at the board level (although just swapping to a 32 bit ARM board definitely feels like it would be less work).
What is the status of 32 bit Marlin? Is it stable on an inexpensive 32 bit ARM platform? I would speculate that prusa might be waiting for that to stabilize before switching. I’m guessing I’ll be able to upgrade to a 32 bit platform in about a year when the mk4 comes out.
Re: Einsy improved octoprint from SD card (?)
I understand the processor is slow/old, but if it can read at high speed from SD, it can read at high speed from any SPI device.
Can it, though? Read at high speed from SD, I mean?
Re: Einsy improved octoprint from SD card (?)
I understand the processor is slow/old, but if it can read at high speed from SD, it can read at high speed from any SPI device.
Can it, though? Read at high speed from SD, I mean?
Good question, and my assumption as been yes. The uart/serial interfaces on my printers tend to run at 115K or 250K bps. A general arduino 2560 SD card access with the SDFat library is 200-600 KB/s (Byte, not bit). A factor of 8 or so faster.
The other question is “does it matter? Isn’t 250 kbps fast enough?” Generally, yes, or nobody would print from Octoprint. However, reading around, it is generally acknowledged (even by Gina, the octoprint dev) that at high print speed, with many short segments, the amount of gcode can surpass the available USB/serial bandwidth. When this happens, your print will slow down and it may affect quality.
Octoprint has “upload to SD” and allows printing from SD for this reason. However, the upload to SD is painfully slow (at least on my ultimaker/marlin), some firmware or hardware limitation.
I heard Josef mention they were working on speeding up that SD upload. If they did it would be very close to ideal: SD print, octoprint control/visibility. Marlin feeding a progress indicator back (if it can’t already) would be the last step.