Did you have a look at Firmware?  

RE: Did you have a look at Firmware?

Posted by: @nikolai-r

This tweet is about MK3. Different platform 🙂

RE: Did you have a look at Firmware?

Whatever the reason for disabling the M500 function (except PID and Live Adjust Z), but one thing is certain, this change is not in the interest of many users. In any case, it would be a helpful option to could be able to make optimizations in the sense of open source.

RE: Did you have a look at Firmware?

Posted by: @karl-herbert

Whatever the reason for disabling the M500 function (except PID and Live Adjust Z), but one thing is certain, this change is not in the interest of many users. In any case, it would be a helpful option to could be able to make optimizations in the sense of open source.

So long as I can embed overrides in my startup gcode, I'm less concerned. What I worry about is having features implemented in the nice shiny new 32 bit board firmware that can ONLY be adjusted from the front panel on the printer.

RE: Did you have a look at Firmware?

Posted by: @bobstro

So long as I can embed overrides in my startup gcode, I'm less concerned.

If you have only one printer, yes. You can do it this way. But if you have multiple printers with slightly different hardware configuration (i.e. many people are swapping motor to 0.9 degree) then it becomes an issue. You have to slice for specific printer and can’t use just one gcode for all.

RE: Did you have a look at Firmware?

@nikolai-r

I agree with you, this is also my opinion! The firmware has to be adapted to each individual hardware as well as the tuning for each engine has to be adjusted individually. Of course you can use external solutions, but this can be an additional source of error if you forget to change the esteps in the printer profile. If you use several slicers and printers like I do, this can easily happen.
But as it is, I have to live with it. There's always a way.

RE: Did you have a look at Firmware?

Posted by: @nikolai-r

If you have only one printer, yes. You can do it this way. But if you have multiple printers with slightly different hardware configuration (i.e. many people are swapping motor to 0.9 degree) then it becomes an issue. You have to slice for specific printer and can’t use just one gcode for all.

Good points. I agree that saving EEPROM on the printer itself makes sense. I would also like to see PrusaSlicer support the idea of Printer Settings (as done now) affecting all printers of a certain type, and individual printer customization profiles for multiple printers of the same type. In my case, I'd like different nozzle configurations that modify otherwise-identical printer profiles. In your case, you'd like more printer-specific customization. I think the Prusa community is growing beyond 1 printer for a household.

RE: Did you have a look at Firmware?

Posted by: @nikolai-r

Posted by: @bobstro

So long as I can embed overrides in my startup gcode, I'm less concerned.

If you have only one printer, yes. You can do it this way. But if you have multiple printers with slightly different hardware configuration (i.e. many people are swapping motor to 0.9 degree) then it becomes an issue. You have to slice for specific printer and can’t use just one gcode for all.

Nevertheless you have to slice separately for mini and mk3 anyhow due to different print area size. 😉 Now seriuosly I believe Prusa is listening to community voices and we as forums administrators want to have happy users. The aim is to provide the best firmware for prusa printers and good support.

RE: Did you have a look at Firmware?

Posted by: @zoltan

Nevertheless you have to slice separately for mini and mk3 anyhow due to different print area size. 😉

Actually printbed size is not an issue (in case the object fits on the plate). I wouldn't also print direct drive gcode on the bowden style printer because of different retractions.

Most common scenario now in the MK2/MK3 world is to have multiple similar printers. Some of them got the extruder replaced for other materials or maybe x/y motors replaced for better accuracy. Right now you can slice one gcode and push it to your printer farm (of similar printers). That's possible because some essential functions like movement is controlled by the printer. It just doesn't make sense to embed this configuration in the actual print file. It's part of the printer configuration and not print instruction.

It worries me that such essential functions are just being removed without offering a working solution. For example they could make it adjustable in the menu. Or maybe fix the save function (for whatever reason it's broken in buddy firmware, in marlin 2.0 it's still working fine). Instead it's just being marked as not an issue. Leaving a bad taste in the community.

RE: Did you have a look at Firmware?

Posted by: @nikolai-r

It worries me that such essential functions are just being removed without offering a working solution. For example they could make it adjustable in the menu. Or maybe fix the save function (for whatever reason it's broken in buddy firmware, in marlin 2.0 it's still working fine). Instead it's just being marked as not an issue. Leaving a bad taste in the community.

Being able to set or calibrate things like PID, extruder e-steps, stepper motor resolutions etc. from menu and store it on printer has its advantages and would no doubt be very convenient. But I can see how it could be confusing for some people, when troubleshooting failing prints you have to check both places - starter g-code or profile in slicer, as well as printer itself. I guess that's why they try to push all changes to one place, in this case gcode.

RE: Did you have a look at Firmware?

Posted by: @crawlerin

Being able to set or calibrate things like PID, extruder e-steps, stepper motor resolutions etc. from menu and store it on printer has its advantages and would no doubt be very convenient.

It is convenient in the marlin firmware. Everything is implemented and you can activate the functions you want. It's not like PR need to reinvent the wheel.

The only direction I can see in the mini development is to make the printer more consumer friendly. Developers/Engineers are not really welcome. Introducing hardware lock without developer program, changing firmware functions at will. No straight communication about directions. Just ignoring many github merge requests without a comment. This is not a good environment for free contribution.

RE: Did you have a look at Firmware?

I bought the Prusa so that I can deal with the technology in detail, both with the mechanics and with the firmware and accordingly I can intervene and make changes myself. But I think that the majority of the customers just want to print, nothing else. Prusa will be oriented towards the majority of customers and will not pay much attention to the arguments of some developers.
As long as the firmware remains open, I'm in, otherwise I'd decide for another project.

I repeat myself: The firmware should be individually adapted to the hardware, so that also a uniform gcode e.g. from Mini to Mini can be exchanged and used universally.

Of course you can leave everything as it is, then there are no problems and all the developers around the accessories and extensions look into space.

I think there are many different opinions on this topic and everyone is right for himself.

RE: Did you have a look at Firmware?

you are programmers, so tou certainly know what effort takes to maintain any FW variants, I agree, Marlin can do everything, but takes warranty for nothing.

I agree with  @crawlerin's 

" But I can see how it could be confusing for some people, when troubleshooting failing prints you have to check both places - starter g-code or profile in slicer, as well as printer itself. I guess that's why they try to push all changes to one place, in this case gcode."

and @karl-herbert's statements:

But I think that the majority of the customers just want to print, nothing else. Prusa will be oriented towards the majority of customers and will not pay much attention to the arguments of some developers.

end of statement.

mine statement follows "

Powerfull weapons (special functionality ) in unexperienced hands can generate large damages. When I read articles from some programmers they post their firmware on net, the first sentence after (or sometimes even before) the download link is to deny any bit of warranty in case of any damage.

RE: Did you have a look at Firmware?

let me turn it around, what would you allow to external people to do with your software while keeping your full warranty?

RE: Did you have a look at Firmware?

@zoltan:

PS  is not ideal example where gcode can be found easily and logically placed ;).

In regards to warranty: Again, everybody understood why PR introduced that in a board. But the lack of communication on that topic (was brought to light by a user) and lack of any alternatives for the devs is just disappointing. Mini was released almost one year ago. Still we have no dev. program in place right now.

I fully understand PR is growing. Their dev. team is getting bigger and they pursuing their own internal goals. I'm not blaming PR for that. Only telling why I lost interest on official FW contributions and what PR can do better in order to get more community people get involved in dev., if they want to.

RE: Did you have a look at Firmware?

@nikolai-r

thanks for response, so what would you think, how to cooperate?

RE: Did you have a look at Firmware?

I provided already couple items in my previous posts. Here is a quick summary which are only relevant for Mini FW. I'm not including MK3 FW or PS to avoid any generic discussions.

1. Some kind of dev. program. We need an option to use our machines for development without loosing a warranty.
2. Better communication about the design decisions. For example if PR would like to put all configuration in gcode, it's fine. It will help to understand certain implementations.
3. Offer a platform to discuss the design decisions. Right now it requires a shit-storm in social media to get attention on certain items. I think there are better ways for communication.
4. Keep github tickets clean. There are many tickets in open/unanswered state. Mark them for example as "help needed" if not a priority for PR.

RE: Did you have a look at Firmware?

@nikolai-r

👍 looks cool

Did you have a chance to look at this? https://prusa3d.github.io/Prusa-Firmware-Buddy-Doc/  apart of doxygen compilation there is an buddy firmware architecture overview. It is open, probably nothing new for yourself.

RE: Did you have a look at Firmware?

@zoltan

Thanks for the link. Haven't seen this document yet. Looks like the dev's are not following their own goals 😉

Marlin version 2. is used for interpretation of G-codes and managing prints as well as other functions (movement, heating, extrusion, etc). Development team has a goal to keep Marlin as much as possible without any modifications.

RE: Did you have a look at Firmware?

@nikolai-r

To the history regarding the Mini firmware:
I hope Prusa pays attention to the software developers. Why shouldn't professionals work with professionals?!
The mechanics are a different matter again. Everybody can decide for himself what to improve or make worse on the printer.