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: @jsw

I used to keep a simple .gcode file on the disks to raise the print head and move the build plate forward.

I quit using that, figuring it was less time and fewer clicks to simply press the control knob and spin it.

Same with me.  

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

i'm pretty sure you can do that modifying the end-gcode from the printer profile 😉
not sure of the exact command though

I have added the following code to my custom end g-code (probably stolen from @bobstro):

G90 ; use absolute coordinates
{if layer_z < max_print_height}G1 Z{z_offset+min(layer_z+50, max_print_height)}{endif} ; Move print head up
G0 X0 Y210 F10200; present bed;

No need to use precious bytes in the firmware to accomplish this.

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

Just change the z+50 in the code above to move up however much you want.  Z+100 would move 100mm up with a maximum of your max print height, so on something like a MK3 if you changed it to Z+200 it would move it pretty much to the top each time.

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

Thanks, works a treat.

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

I withdraw my suggestion. The helpful people in this forum have pointed out to me that the 'after end' gcode can be edited in PrusaSlicer to cause the print head to park as high above the platen as desired. That method achieves exactly what I want.

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

Well, I like the 8bit frame working process but i would like to change the nozzle process and printer name definately.

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

250000 baud rate support in firmware (switchable via (that hidden experimental or regular) menu or some kind of autodetection like variant of https://github.com/Sjord/autobaud).

People use 250k (requires rebuilding firmware) with success. That would give twice the speed for feeding the printer from octoprint and hopefully would solve issues with broken prints due to too slow g-code feeding to the printer. Also would make octoprint upload to sd card twice fast.

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

Played a bit with speeds. Looks like prusa firmware is way slower in handling g-code than even 115000 connection, so updating to 250000 makes little sense. Bad :/

RE:

Posted by: @antimix

 

Posted by: @mnemic

 

• Show the current layer and be able to easily reference it in the Slicer.
  • This way if a print is paused or failed, you could in the slicer hide all the successful layers, and print only from there and maybe recover it.
  • I know it may not work, especially since you may fail part-way through the layer. But if you can figure out which layer, and where you were, maybe even mid-layer stuff can be resumed.
  • Possibly some live Z-adjustment can fix it once you're resuming.

That is a good idea. Better to have an LCD option in Print from SD: "Start from Layer: 1" (default value), that can be changed just before starting by confirming or changing the layer number. In this way if something went wrong, and we want try even the last resource to recover the print, we can insert the last layer level displayed from the failed print and try to resume. The optional Z-Adjustment (for that layer only) can help to fine tune.

Also good is the idea of the MMU disable, since I as many other have to unplug the hardware cables.

The remaining part of the flash memory I would like to devote fully to control the MMU2, displaying text messages, and managing much more signal between the MMU2 and the MK3S. There are too many actions that I would like to do on MMU2 from LCD.

I am clicking on the Like buttons, so PRUSA can use this post as a kind of poll. 😉 

Regards

I second you. Thanks for sharing your opinion.

RE:

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?

I would like to see an auto detection of the steel sheet I have on the print bed.  I am probably a bit more careless about it than others, but it has happened quite a few times with me that I have changed the filament, changed the print sheet, added my new gcode to the SD card and started to print, just to find that I have forgotten to adjust the print sheet on the menu.  So I end up either jamming into the sheet or printing the first layer in the air.  Stupid mistake, I know, but it would be nice if the printer just detected it and didn't leave me to it.

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

I like this idea. It'd probably require extra hardware (e.g. a barcode scanner) plus some sort of identifying mark on the sheet (e.g. a barcode on a sticker) but it's totally doable. 

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

Yes, not a bad idea. However, I doubt that there's enough space on the 8-bit board for it. The need for a sensor to detect a QR or barcode makes it a more likely candidate for a Mk4 (with a 32-bit board). But then again, I hope a Mk4 (whenever it arrives) will borrow the Nextruder technology from the XL, which makes this all a moot point as the nozzle itself will sense contact with the steel sheet.

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

The SD card sockets on both of my MK3s seem to be a bit flakey and do not "grip" that card as securely as I think they should. I believe this has led to occasional "halted"/ruined prints when vibrations from the movement of the axes has caused the card to lose continuity on one or more of its contacts. In these instances, removing and reinserting the card has not resulted in a recovered print. Would it be possible to include code that allows a print to be recovered, similar to when a power outage has occurred? I am hesident to try to adjust the contact "wipers" on the card socket, but is this the real answer to the problem, and is it easy/difficult/problematic to do?

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

RedDawg try this https://www.printables.com/model/15388-prusa-mk3-sd-card-slot-fix-not-reading-the-card-at.  

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

Nice that there is this fix/work-around, but the question remains if this "problem" can be addressed in the firmware. Can't the gcode be "tracked" and resumed from the point it stopped being read similar to a power drop?

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

Posted by: @reddawg

Nice that there is this fix/work-around, but the question remains if this "problem" can be addressed in the firmware. Can't the gcode be "tracked" and resumed from the point it stopped being read similar to a power drop?

I'm sure that if someone wanted to code it, it would be do-able to make a 'resume at level X' method in the firmware, space permitting, of course.

I have heard of people carefully manually editing .gcode files to do just that, with varying degrees of success and failure.  I have not tried it myself.

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

I have. My lesson from it: cut your losses, just print it again. Live is too short. 

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

Automatic sheet detection would be a great thing!
May it could be derived from the difference in detection height via nozzle contact (requiring a clean nozzle) vs. detection by PINDA.
And: it should be kind of a reminder, not preventing from printing.

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

Chris there is no detection of nozzle contact beyond ramming it into the sheet and trying to detect motor current increase.  That would at the minimum damage your print surface and might cause other damage to the steel sheet and also damage to the extruder too.  You can bend the heatbreak which means you need a new one.  

Basically this is a really bad idea.