What would you like to see in the 8-bit firmware?  

Result ?

@jakub-dolezal-2

When does this enquiry end ?
What has been choosen or is on the shortlist ?

Option for load light filament after dark ones. So you don't have to press "No" multiple times.

An option like "Load filament dark to light" that will extrude a lot more during loading so you don't have to press "No" 10 times till your white filament comes out clear after you printed something in black. 

Yes, good suggestion.  I echo that.

I've switched from a metallic to a light PLA many times and had to purge over and over to get the metallic sheen totally out of it.

color change

Or even better.  The MMU profile allows you to define how much to purge in the slicer, when going from one color(extruder) to another.  Maybe this could be combined with the single filament printing when you insert a filament change in your print.  So not only do you say change filament at height X, but but maybe have an integer that defines how much to purge after doing so.

Purge length

Posted by: @lups

An option like "Load filament dark to light" that will extrude a lot more during loading so you don't have to press "No" 10 times till your white filament comes out clear after you printed something in black. 

What about having a "select box" that defaults to "Yes" to stop the purge, but allows you to also select a purge length using the scroll wheel ("No, purge XX cm more")?

Pruge

Posted by: @balu

 

Posted by: @lups

An option like "Load filament dark to light" that will extrude a lot more during loading so you don't have to press "No" 10 times till your white filament comes out clear after you printed something in black. 

What about having a "select box" that defaults to "Yes" to stop the purge, but allows you to also select a purge length using the scroll wheel ("No, purge XX cm more")?

That would be a good idea.  I currently use octoprint to do this.  Firmware would be better,  

What plugin?

Posted by: @cwbullet

 

 

That would be a good idea.  I currently use octoprint to do this.  Firmware would be better,  

What plugin do you use for this?

Purge until pressed, or allow user-defined purge length perhaps?

Posted by: @balu

What about having a "select box" that defaults to "Yes" to stop the purge, but allows you to also select a purge length using the scroll wheel ("No, purge XX cm more")?

My crappy little Monoprice Cadet does have a "purge until button pressed" option.  I know the Marlin codebase includes an option to define the purge length, so this is a low-effort change.

extrude

Posted by: @lups

 

Posted by: @cwbullet

 

 

That would be a good idea.  I currently use octoprint to do this.  Firmware would be better,  

What plugin do you use for this?

You don't need a plugin to extrude x mms.  

octoprint

Posted by: @bobstro

Posted by: @balu

What about having a "select box" that defaults to "Yes" to stop the purge, but allows you to also select a purge length using the scroll wheel ("No, purge XX cm more")?

My crappy little Monoprice Cadet does have a "purge until button pressed" option.  I know the Marlin codebase includes an option to define the purge length, so this is a low-effort change.

 

Marlin will do it and I am pretty sure M600 will:

https://marlinfw.org/docs/gcode/M600.html

In octoprint, there is a terminal to send commands to the printer.  I am not sure if it is a plugin or now.  I have installed so many.  

Yes to randomized sheet positions

i would be very happy to see randomized sheet positions as an option

local cache

I would like to see the installed SD card act as a local cache when printing via USB.

In between layers it would be nice if the printer could take in a few lines of G code and store it locally. PrusaSlicer should just USB into the printer, hit go and you can just print live. You should be able to pre-calculate how long it takes to send the gcode to the printer.

After that point, it should be no issue if the PC's USB connection drops or the PC restarts or whatever people say makes USB unviable.

Its kinda silly really how we need to have this intermediate step of either an SD card or a completely separate ARM linux computer just to stream to it, when they could behave like a regular paper printer in the first place.

8 bit firmware imposed limitations

Posted by: @pepe-le-vamp

[...] Its kinda silly really how we need to have this intermediate step of either an SD card or a completely separate ARM linux computer just to stream to it, when they could behave like a regular paper printer in the first place.

Unfortunately, the 8 bit controller limits transfers from the USB port to the SD card to serial speeds (256Kpbs IIRC) so transfers of even small prints can take hours. Your printer has a small fraction of the processing power of just about any other smart device in your home. It only runs a single core 8 bit CPU at low clock speeds with minimal memory. Any sort of background processing is likely to cause print failures.

local cache

Yeah I'm familiar with what it is. Its not quite enough of a detailed answer as to why you can't do it. I'd like to know more about what cpu or memory resources can be made available in between layers. For example, pausing for a 5ms between each layer will buy you some good time for downloading gcode. 

The amount of cached gcode doesn't need to be very large - it only needs to be slightly ahead of what the printer is currently printing. Enough to survive a dropped connection - which I'm told is the core of why people don't print from their PC. Even though raspi on the mainboard is still exactly that.

Posted by: @bobstro

Posted by: @pepe-le-vamp

[...] Its kinda silly really how we need to have this intermediate step of either an SD card or a completely separate ARM linux computer just to stream to it, when they could behave like a regular paper printer in the first place.

Unfortunately, the 8 bit controller limits transfers from the USB port to the SD card to serial speeds (256Kpbs IIRC) so transfers of even small prints can take hours. Your printer has a small fraction of the processing power of just about any other smart device in your home. It only runs a single core 8 bit CPU at low clock speeds with minimal memory. Any sort of background processing is likely to cause print failures.

 

the installed SD card act as a local cache when printing via USB.

SD cards are not suitable for this sort of use, they are optimised for occasional replacement of large files, think camera, not repeated small write/read cycles.  You might make this work with an SSD but that is a different beast.

Cheerio,

Anyone who has attempted a large cp or tar on a Raspberry Pi can attest to the fact that the SD card is much slower.

Remember, what's driving this beast is basically an 8 bit Arduino.  Those are very good for low-level machine control but not for data processing.

RE: What would you like to see in the 8-bit firmware?

i bit the bullet and bought a flashair card.

no regrets there, sending files to print is now just saving them to a network drive.

for future prusa machines it would be preferable if there was a usb/network/wifi connectivity built-in

Legacy design issue, new printers won't have the same limitations

Posted by: @xenon

[...] for future prusa machines it would be preferable if there was a usb/network/wifi connectivity built-in

Prusa has stated that all new designs will use 32-bit processors, so these sorts of things will be less of an issue. The situation now is very different than in 2016-2017 when the Mk3 was designed. For older designs with 8-bit boards, some sort of external processing support works well, and OctoPrint handles many of these situations quite well.

Posted by: @bobstro

Posted by: @xenon

[...] for future prusa machines it would be preferable if there was a usb/network/wifi connectivity built-in

Prusa has stated that all new designs will use 32-bit processors, so these sorts of things will be less of an issue. The situation now is very different than in 2016-2017 when the Mk3 was designed. For older designs with 8-bit boards, some sort of external processing support works well, and OctoPrint handles many of these situations quite well.

 

But does Prusa actually design the computer hardware? I was told that the main control board is an off the shelf product, not a Prusa product. Is this incorrect?

Custom but not in-house designed or manufactured (AFAIK)

Posted by: @annier

 But does Prusa actually design the computer hardware? I was told that the main control board is an off the shelf product, not a Prusa product. Is this incorrect?

I believe the Mini "Buddy" controller is a custom design, though I doubt it's actually designed or manufactured in-house. In any case, 8-bit controllers are now more expensive than commodity 32-bit controllers, so I'm fully expecting the Mk3 to be the last of the Prusa printers with 8-bit boards.