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

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

@Tim Can you explain why you would find the randomized print location dangerous?  

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

Sorry - the edit timed out.  Randomizing print location might make your sheet last longer.  .

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

Posted by: @jweaver

Posted by: @tim-2

Randomize print position? Perhaps that makes sense in farm mode, but a worthless and dangerous option for me. As a data point, I've been using the same smooth PEI for over three years, printing in the exact same center for 99.99% of prints. Plastic still sticks fine. Soap and water works.

Personally, I disagree.. I would like this feature (it could be a user selectable option so that we could choose the behavour which suits us).. I have no problem with adhesion anywhere on the bed.. But I am getting a blister in the middle of mine, as I keep doing small prints and forgetting to move the object in slicer.

I recall that in one of the GitHub discussions, one of the devs (@bubnikv I think) suggested providing a slicer feature that would optionally allow the user to install a bitmap to drive automatic placement in the slicer (where it makes the most sense, IMO). Solid colored areas would indicate "do not use/avoid" (e.g., I've got a tear in my PEI sheet at this location), less solid or other colors indicate "available for part placement". You could even use a gradient to prefer the center of the bed, but still allow use of the outer regions if necessary. I personally think this is very clean and effective, yet isolates the complications to the slicer where it's less likely to have disastrous effects -- or at least be immediately obvious in preview -- and provides a nice, user-friendly GUI interface to the whole procedure. Maybe even call up MS Paint with a pre-shaped template. I really don't see much benefit to "randomize positions" in the printer firmware, and I'm trying to imagine all the reconfiguration that would ber required if too many features are stuffed into firmware if you have to do a factory reset, esp. without a "backup firmware configuration" option. That's yet another nice-to-have babysitting feature that I'll turn off.

Someday, when we're running 64bit OS on the printer, it'll make sense to provide all kinds of comfy features and yet still get a visual confirmation that the printer is doing what we want it to. The poor Mk3 has to make do with trying to communicate using 4 short lines of text, and people have a hard enough time interpreting meaning from forum posts already.

For me, one of the features I want is better handling of the "Sheet" change so that it adds "ARE YOU SURE" (or some kind of confirmation).. I can't tell you how many times I have suffered for hours with object not sticking and then realised I accidently clicked on SHEET.

It might make sense to re-write the display for some configuration functions rather than depending on the little hints in the current busy display. Wipe the display and print information about sheet selection and confirmation so it's obvious. That wouldn't require much additional horsepower and hopefully not much more space. Even a pre-print confirmation "Ready to print XYZ on SMOOTHPEI with 0.25mm nozzle using 0.2mm layer height, 200C/210C nozzle temp and 65/60C bed temp" in nice big focused letters. It could even display for a few seconds while the printer heats up so as not to disrupt existing workflows.

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

Posted by: @cwbullet

@Tim Can you explain why you would find the randomized print location dangerous?  

If not dangerous, I don't see how it can be convenient and reliable:

• Randomizing part placement belongs in the slicer so we get a visual confirmation (IMO). Prusa can put a nice GUI in front of it, and allow more fine-grain control than anything that could be done in 8 bit Marlin firmware (see my previous post). How granular can this get with a 4 line display and a knob on the printer? How much effort will it take to configure anything meaningful? (Perhaps an STL or bitmap could be uploaded as part of the job, but then you're back to doing it in the slicer, so no net gain.) $5 says if they implement anything like this, there will be a deluge of complaints to support that it's "too hard, we want a GUI".
• People seem to be struggling with remembering what sheet they've plunked down on the printer, and that's right in front of them. How likely are the same people to remember what randomization pattern is associated with those same sheets? Now you've got sheet AND randomization patterns to keep track of. Sounds (to me), like a lot of work that will be of marginal value to most users, and I can think of firmware features I'd rather see first.
• If the pattern is not somehow very obvious, the printer could easily be misconfigured and instead limit prints to a smaller area of the bed, actually increasing wear.

My take is that I want to see exactly what the print looks like when I preview it in the slicer. I don't want the printer to "decide" to rearrange things. I really do wish even the prime line would be shown. I was surprised that XYZ positioning in start gcode is taken into account (you can float parts), so most of the code is in PrusaSlicer now. I'm fine with GIGO, but I'll be upset if I get GO when sending good input.

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

 

I recall that in one of the GitHub discussions, one of the devs (@bubnikv I think) suggested providing a slicer feature that would optionally allow the user to install a bitmap to drive automatic placement in the slicer (where it makes the most sense, IMO). Solid colored areas would indicate "do not use/avoid" (e.g., I've got a tear in my PEI sheet at this location), less solid or other colors indicate "available for part placement". You could even use a gradient to prefer the center of the bed, but still allow use of the outer regions if necessary. I personally think this is very clean and effective, yet isolates the complications to the slicer where it's less likely to have disastrous effects -- or at least be immediately obvious in preview -- and provides a nice, user-friendly GUI interface to the whole procedure. Maybe even call up MS Paint with a pre-shaped template. I really don't see much benefit to "randomize positions" in the printer firmware, and I'm trying to imagine all the reconfiguration that would ber required if too many features are stuffed into firmware if you have to do a factory reset, esp. without a "backup firmware configuration" option. That's yet another nice-to-have babysitting feature that I'll turn off.

 

 

That would be a nice feature... But for me its not about protecting the blister I already have.. Its about stopping another from forming..

I would love to be able to mark an area on the bed not to use.. But I still think that having an object load into the bed in a random position would be helpful, to stop the same point being printed on over and over again.

So I would like both features to be honest.

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

@bobstro

The only scenario I can think of where randomization by the firmware could be useful is if you print many copies of one model that is less than say about the quarter the size of the sheet. In which case using one gcode file but having prints spread randomly across the print bed may help extend the lifetime of the sheet. But I think it's an edge case for a small number of high-throughput users. And those users probably would more likely than not just print a whole sheet full of copies of that model anyway. I totally concur with your viewpoint that I'd rather something like see this in the slicer than the firmware. Could be as simple as splitting the current Arrange function into Center and Random. Job's done.

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

Posted by: @fuchsr

[...] Could be as simple as splitting the current Arrange function into Center and Random. Job's done.

Just realized they could probably reuse some of the code for paint-on supports. Allow user to paint using "preferred", "available", and "avoid" colors or gradients. A nice, tidy slicer-based solution. Hell, you could even let the users select among algorithms (e.g., "rotate if needed", "90 degree rotation only"). Added plus is that this is another power user feature to differentiate PrusaSlicer from the competition and will benefit ALL users, not just Prusa owners.

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

Question on the 32 bit firmware... will the MK3s be upgradable to run this?

The suggestions Prusa captured in the original post are all excellent to see captured!

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

The thing about randomizing print position on the bed is that this is mostly useful for machines that print the same G-code over and over again (production farm). This wears the sheet down faster compared to more traditional use of printing all sorts of objects of different sizes and shapes.

Because the problem is with printing the same G-code over and over again, the randomizing can't really be offloaded to the slicer (because the random position would always be the same, if the same G-code is run). Of course, you could generate several G-codes and alternate between them, but at that point you A) don't need any new feature to be implemented, but B) you're back to a sort of cumbersome solution.

However, maybe there is a middle-ground, where the slicer could output a bounding box or a maximum deviation distance from the G-code center and the printer firmware could read and interpret these values.

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

@mikolas-zuza

Great point!  Thanks for the explanation.  

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

@jurassic73

MK3 will have an inexpensive addon (RPI zero) that will enable it to have wifi and a connection to PrusaConnect in the near future. This will allow it to gain some advanced functions (e.g. the networking, normally run by a 32bit fw) without the need for a major upgrade of the printer.

Once we release the next printer in the i3 series, there will for sure also be a proper upgrade for the MK3. The details about that will be available when those products are ready 🙂

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

@mikolas-zuza

Fantastic - thanks for the reply and information!

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

@mikolas-zuza

Thanks for the update!   Hopefully soon!

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

Posted by: @jurassic73

Question on the 32 bit firmware... will the MK3s be upgradable to run this?

The suggestions Prusa captured in the original post are all excellent to see captured!

I think you'd also have to change the display (and possibly some other hardware) to take advantage of the 32-bit F/W.

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

Posted by: @mikolas-zuza

[...] Because the problem is with printing the same G-code over and over again, the randomizing can't really be offloaded to the slicer (because the random position would always be the same, if the same G-code is run). Of course, you could generate several G-codes and alternate between them, but at that point you A) don't need any new feature to be implemented, but B) you're back to a sort of cumbersome solution.

How many print farms are running that aren't maximizing the area of the print bed filled? To be able to randomize the position in any meaningful way, you'd have to leave significant portions of your print bed area unused. Wouldn't it be easier to shift or rotate the PEI sheet regularly?

However, maybe there is a middle-ground, where the slicer could output a bounding box or a maximum deviation distance from the G-code center and the printer firmware could read and interpret these values.

Well, you guys get to support it! Not something I'm too interested in.

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

Posted by: @mikolas-zuza

Once we release the next printer in the i3 series, there will for sure also be a proper upgrade for the MK3. The details about that will be available when those products are ready 🙂

That said... One thing I think the 8-bit firmware could really benefit from would be 24 more bits.

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

Not a suggestion, but any time a company wants to extend the functionality of an ancient product, it generally means any new products are suffering delays, that release and shipment is quite a ways out.  Is this post that type of message? 

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

Regarding why a random anything is a problem in printing.   Parts of MY print bed is not heated as well as other parts of my heat bed. Perhaps your printer is better and has a 100% perfectly heated surface.  But if I tried to print something in the far left front, I can pretty much guarantee a rats nest. There are places on my print sheet I want to avoid for cosmetic reasons (that scratch that was there when Prusa shipped it to me that they said was not covered under warranty that makes half of one side of the sheet unusable). The other side where I got the nozzle too low trying to get layer one repeatable before I figured out the PINDA is trash and goes willy nilly with temperature changes (and that the temp comp calibration Prusa gives in firmware only makes it worse and lead to a major nozzle abrasion on my otherwise pristine side of the sheet).

Anyway - As long as the random is something I can turn off... but best if it is only a switch that's available for Print Farm mode.

I'd rather Prusa spend time fixing the interrupt corruption that causes filament sensor communication and activations to corrupt other things like power fail status.

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

@bobstro

Good points.  The randomization sounds good the make the bed last longer, but maybe it is not good in practice.  

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

@bobstro

I print a few things I sell on Etsy with small footprints.  On older sheets, I can see the wear in those spots since I continue to print from the same GCODE.  Having that shift around automagically would be great given the option.