4.0.5 Firmware for Original Prusa MINI  

RE: 4.0.5 Firmware for Original Prusa MINI

Posted by: @admin-7

Posted by: @stevensmith

I'm not sure I understand the logic behind this:

“When you start a remote print over OctoPrint, the printer becomes locked and a dialog is displayed on the screen. This is for safety reasons.”

What safety issues are there? I'm able to print via Octoprint on all my other printers and still have control over things at the printer. This includes my I3MK3. If octoprint is even connected to the Mini (even if it’s not printing) it is now locked. I can't start a print off the thumb drive if Octoprint is connected. This makes no sense! Prusa, please reconsider this approach! 

 

I would like to second this.  What possible safety reason could there be?  I would like clarification on this.  Right now it seems to just be pure anticosumer push to get people using PrusaConnect. Maybe it's an unaddressed bug but that should be clarified by Prusa

I think when you are using OctoPrint, the Mini itself can no longer be sure of what state it is in, since it is simply obeying G-Code commands. By misconfiguring settings on OctoPrint I managed to face plant my nozzle into my bed and the Mini firmware didn't attempt to stop it. That made me panic!!!

You can modify some things on the Mini which take effect on the next G-Code command, but this is limited to things that are definitely very safe to play with (things in the tune menu).

I'm sure they are just being careful about what things they let you do once OctoPrint is connected, and more will come in time. I'm sure whoever is maintaining the firmware will have a list of priorities, it would be really nice to see a roadmap though!

RE: 4.0.5 Firmware for Original Prusa MINI

Posted by: @robee

Posted by: @admin-7

Posted by: @stevensmith

I'm not sure I understand the logic behind this:

“When you start a remote print over OctoPrint, the printer becomes locked and a dialog is displayed on the screen. This is for safety reasons.”

What safety issues are there? I'm able to print via Octoprint on all my other printers and still have control over things at the printer. This includes my I3MK3. If octoprint is even connected to the Mini (even if it’s not printing) it is now locked. I can't start a print off the thumb drive if Octoprint is connected. This makes no sense! Prusa, please reconsider this approach! 

 

I would like to second this.  What possible safety reason could there be?  I would like clarification on this.  Right now it seems to just be pure anticosumer push to get people using PrusaConnect. Maybe it's an unaddressed bug but that should be clarified by Prusa

I think when you are using OctoPrint, the Mini itself can no longer be sure of what state it is in, since it is simply obeying G-Code commands. By misconfiguring settings on OctoPrint I managed to face plant my nozzle into my bed and the Mini firmware didn't attempt to stop it. That made me panic!!!

You can modify some things on the Mini which take effect on the next G-Code command, but this is limited to things that are definitely very safe to play with (things in the tune menu).

I'm sure they are just being careful about what things they let you do once OctoPrint is connected, and more will come in time. I'm sure whoever is maintaining the firmware will have a list of priorities, it would be really nice to see a roadmap though!

Honestly this sounds like a handwave.  Why isn't it a problem with literally every other printer? I can understand if a print is active but when I'm not printing I should not have to disconnect Octo.  Just like on the MK3, Mk2 and literally every single printer in existence except the mini.  This reeks of adding "features" to harm the competition and force people into PrusaConnect.

RE: 4.0.5 Firmware for Original Prusa MINI

I've been ignoring this thread cause I don't have a Mini but this statement

" This reeks of adding "features" to harm the competition and force people into PrusaConnect. "

is just too much.

I know we're supposed to be polite but what is this guy smoking?

Let me pose this question - For what conceivable reason would a manufacturer try to force you to use a piece of software that is free?

RE: 4.0.5 Firmware for Original Prusa MINI

@admin-7

I understand your frustration, but how many of those "literally every other printer" runs RTOS with Marlin being as a separate thread instead of Marlin or Marlin-like natively on hardware? Judging from the picture, this may simply be the case that components or processes running in firmware do not have access to read what's happening in other parts, i.e. Display and UI do not monitor what's going in through USB or what's happening inside Marlin (don't quote me on that, I am not a programmer, it's just my interpretation of that image and what they wrote in changelog).

RE: 4.0.5 Firmware for Original Prusa MINI

I am a programmer. I also contributed code to Marlin. It's nothing to do with Marlin running in a separate thread.

If there is a limitation when running Octoprint, it's a design decision by Prusa. There are certainly issues with having GCode coming from different sources, GCode is not designed for that. There is a single machine context, and it will easily get out of sync if receiving commands from different sources. Whether a blanket lockout is a reasonable approach or not is debatable, but it is a lot easier course of action which is probably why Prusa did it.

RE: 4.0.5 Firmware for Original Prusa MINI

@bobcousins

good explanation.

it makes sense for an early iteration product, like the Mini.  If a use-case comes up where it provides value, I suspect that a change will be made.  Preventing conflicting commands or similar issues seems reasonable, at least for now...

RE: 4.0.5 Firmware for Original Prusa MINI

@bobcousins

Thanks, that makes sense.

RE: 4.0.5 Firmware for Original Prusa MINI

@towlerg

They would force you into it to keep you in the ecosystem.  If you are used to using 1 single system you are much more likely to use more of that ecosystems products.  It's the classic walled garden approach.

@bobcousins
That's a good explanation and all I really needed.  Not a great a approach and I'm not convinced it isn't driven by the walled garden ideology but at least there is some kind of explanation.

RE: 4.0.5 Firmware for Original Prusa MINI

Hang on a sec ... I could have sworn originally in text about EEPROM implementation there was only Live-Z value mentioned as being stored in permanently. Now there's also PID tuning values mentioned. Ninja edit? Can someone clarify?

Any specific adjustment of those values should be part of the G-code. The only variables from Marlin allowed to be stored in the EEPROM are the Live Adjust Z and PID calibration. The EEPROM further contains Ethernet settings, the filament type and the information, whether the Wizard was successfully finished.

RE: 4.0.5 Firmware for Original Prusa MINI

Posted by: @stevensmith

I'm not sure I understand the logic behind this:

“When you start a remote print over OctoPrint, the printer becomes locked and a dialog is displayed on the screen. This is for safety reasons.”

What safety issues are there? I'm able to print via Octoprint on all my other printers and still have control over things at the printer. This includes my I3MK3. If octoprint is even connected to the Mini (even if it’s not printing) it is now locked. I can't start a print off the thumb drive if Octoprint is connected. This makes no sense! Prusa, please reconsider this approach! 

 

It is to prevent your controll of your printer from two ends in order to avoid contradictionary commends - you print from Octoprint and start e.g. MBL from local knob menu.  In next version you will be able access commands like you have on display when printing localy.

RE: 4.0.5 Firmware for Original Prusa MINI

New stable firmware 4.1.0 is out, more info here https://forum.prusa3d.com/forum/general-discussion-announcements-and-releases/4-1-0-firmware-for-original-prusa-mini-2/

RE: 4.0.5 Firmware for Original Prusa MINI

@matteo-cristini

Thanks for your post. My file was not working. Type must be "static" and not "Static"