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

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

Posted by: @blindside_o0

Some of these might not be things of the 8-bit so please Haribo bear with me.

• I want to be able to include a prompt during my prints that asks (while still keeping everything hot) whether its ok to continue. This would allow me to clean the nozzle moments before the intro line.

Why not just modify your start gcode to do that ?  No need for printer firmware change for that.  Inserting a pause in the right place should do the trick.

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

Filament spools on file that the system can tell you how much of a spool is left. This could be performed by using the dial to enter the code from the side of the spool and saving it in a file on the SD Card.

This is, of course, impossible.  The printer has no way to know how much filament was on the spool in the first place - in the last week I have used 2kg, 750g, 500g, and on the printer now is a 1kg spool; if you have more printers each has no way of knowing how much the others have used.  If you want to keep track use the value given by the splicer and weigh any failed prints.

This could be performed by writing on a label on the spoo.

Cheerio,

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

As i use octoprint to control the printer it would be really nice if there was the ability the printer statistics as the Total Print Time, been updated as if the machine was printing from it's own sd.

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

Posted by: @diem

Filament spools on file that the system can tell you how much of a spool is left. This could be performed by using the dial to enter the code from the side of the spool and saving it in a file on the SD Card.

This is, of course, impossible.  The printer has no way to know how much filament was on the spool in the first place - in the last week I have used 2kg, 750g, 500g, and on the printer now is a 1kg spool; if you have more printers each has no way of knowing how much the others have used.  If you want to keep track use the value given by the splicer and weigh any failed prints.

This could be performed by writing on a label on the spoo.

Cheerio,

Or use Octoprint on every printer and a plugin called filament manager were you can track the filament consumption on every spool when printing via Octoprint (not via SD-card).

Best regards, Clemens

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

@clemens-m

This is what I have.  I have a Pi4 on each printer and filament manager.  I am slowly converting to Spool Manager.  I really like this products.  They works well with a history plugin and the Cost Estimator. 

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

This may be off topic, but i would prefer a MKx 32-bit board for better handling of my 0.9 moons. This would also allow bobstro's ideas and more to be implemented.

regards,

Karl

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

@cwbullet

Yes I will also switch from Filament-Manager to Spool-Manager but at the moment the external database for the filament spools is not implemented (not finished). But as soon as a new release is out I will try and test it.

Best regards, Clemens

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

@Clarmrrsn:

Something like the idea I posted in this thread?

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

Fixing the false Y axis crash detections introduced in 3.9.1, gone in 3.9.2 and back again in 3.9.3 would be nice.

People confirm it's still there in 3.10.0 RC2.

I dont like running with crash detection disabled. I've had one close call and fear the day I'm not there when a real crash happens.

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

Proposal: OLED Screen for the MMU2S to show the error and how to solve it.

I find it pretty devastating when all the LEDs are flashing and there is this crackling noise and you have to look for something pointy to press the reset and try to figure out what went wrong and what's next.

The prusa MM control has a unused port labeled "sensor" that is an I2C-Bus. Its quite easy to directly wire a Arduino OLED Display SSD1306 with F/F Jumper Wires to the MM control. A small text-only version class for outputting the text will fit into the memory of the MM control to directly communicate with the display  https://github.com/greiman/SSD1306Ascii

Of course it's possible interpret the I2C stats with an ESP32 and create some more fancy artwork here but having basic information what I need to solve would be the next best thing.

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

I guess it might be more of a slicer feature request, but maybe also something for the firmware to take into account...

Would it be possible to natively support sequential prints which includes managing the print head path to safely navigate between already printed parts while printing subsequent parts?

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

Something else which I am sure will not just simply be a firmware feature, but might need some firmware component would be a way to clean, not just the nozzle, but the bottom of the printhead/hotend from any buildup of plastic.

To me the number of times that I face some kind of build up is still not ideal and from time to time it impacts on the quality of the print due to some particles getting stuck on or wiped into the print.  It just feels like something that should be avoidable.

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

Maybe add support for a purge bucket ?

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

@danie

I have built something like this and adapted the start gcode so that every time the filament is changed, the nozzle is flushed with the new filament and any leftovers are wiped off the nozzle. With this I print without wipetower.

The x-carriages I have changed as appropriate and the rest is fine tuning.

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

@karl-herbert

I had seen something like this before I got my MMU. Have you posted this some where?

Most I have seen have to many moving parts that can give problems I think.

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

@baklin

No, I have not published this construction. As I said, some parts on the MK3 have to be reprinted for this. The area of the wiper I have printed from CarbonPEEK, because this should be a little more temperature stable.

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

@karl-herbert

No problem. I thought I'd ask before starting to have a go my self.

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

Didn't see this above but might have missed it.  I'd like to see an (optional) check for the sheet name to match a sheet name added to the gcode file at startup.  This would require adding an optional item to the slicer to specify the name of a print bed sheet probably via a new G-code.  Then that G-code would check the name for agreement with the name set as the current plate on the printer and stop on error.  As someone who doesn't change filaments that often I find I have often changed filament and plate and forgotten to change the plate setting in the printer, only to have a mess of a first layer.  Seems like it would take very little code to check this and would be in the same vein as the nozzle check and printer type check.  Since the check wouldn't happen unless the gcode was inserted it would be optional based on the slicer.

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

@danie

That's a slicer feature request indeed and it's something we're currently working on 🙂 You'll most likely see it in the upcoming PrusaSlicer 2.4 alpha

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

I'd love to see the printer pass custom gcode to a print host. I'm imagining starting a print on the SD card from the printer so that you avoid losing power-loss resume and avoid any issues with a slow print host (I don't know what the reliability of using the Pi0 as a print host with Octolapse turned on is, but I've seen that it may be problematic for print quality), but the gcode having custom commands (like Octolapse's @OCTOLAPSE TAKE-SNAPSHOT) that get forwarded to the host. I could imagine this having a configurable timeout for a response.

This entire scenario is tailored to me saying "I want to run Octolapse on a Pi0 but don't want to compromise on the features of the printer or risk remote print monitoring or timelapses overloading the printer and causing issues with print quality.", and it seems like passing custom gcode to the host in a way it can react to would get the job done. 

This addition, alongside the existing faster print host file transfers and hopefully also long file-name support for prints hosted on the SD card of the printer directly would make me start utilizing the Pi0 I have plugged in to my printer for more than just remote monitoring at the moment. I don't know what other advantages could come from passing data from the gcode on the printer to the print host, but it seems like a promising enough feature to my mind.