RE: What would you like to see in the 8-bit firmware?
This would require a change to all gcode standards and all printers. I think it is a good idea since it would mean that for any model, the user could print it with the modifications for their local conditions. It could be gcode variables that are set within the controller software. Select the model and select the custom filament setting.
The firmware would need to be able to store many filament config files to make it work though. A gcode variable pre-fill app may make the idea work.
I have issues printing with PLA due to high ambient temps so I am wiring with PETG mainly and ASA at present so many items that are PLA are out of the question.
RE: What would you like to see in the 8-bit firmware?
I like many of Bob's suggestions, particularly the automated nozzle change procedure (something as simple as having a fixed setting of 285 degrees to pick in the nozzle temperature Menü would be better than spinning the wheel a dozen times) and replacing the current first layer calibration method with a live z my way approach. The latter seems to be the standard answer to what feels like every other post in these forums (fora?)...
Sometimes it's a bit hard to decide if something should be a feature of the firmware or the slicer. For example, the OP's original idea of randomizing print positions strikes me as a slicer issue more then firmware. I don't want the firmware to futz around with the positions I carefully selected in the slicer. Or copying the cool down process for bed leveling. While I think it would be great to do that in firmware, I can already do that with startup Gcode in the slicer so why waste that space in firmware?
One more idea but again it seems this requires cooperation of slicer and firmware: there's 20+ pages of discussion of the "bulge" (or buldge [sic]) issue in these forums. If there only one thing the Prusa devs could work on, I would pick this one, and I strongly expect it requires both slicer and firmware improvements.
Hi guys
Bob's suggestions are indeed promising, particularly the automated nozzle change and live z my way approach. Deciding whether certain features should be in the firmware or slicer can be challenging. For instance, randomizing print positions may be more suitable for the slicer to handle, while bed leveling's cool-down process could be managed with startup Gcode. free fire name
RE: What would you like to see in the 8-bit firmware?
I like many of Bob's suggestions, particularly the automated nozzle change procedure (something as simple as having a fixed setting of 285 degrees to pick in the nozzle temperature Menü would be better than spinning the wheel a dozen times) and replacing the current first layer calibration method with a live z my way approach. The latter seems to be the standard answer to what feels like every other post in these forums (fora?)...
Sometimes it's a bit hard to decide if something should be a feature of the firmware or the slicer. For example, the OP's original idea of randomizing print positions strikes me as a slicer issue more then firmware. I don't want the firmware to futz around with the positions I carefully selected in the slicer. Or copying the cool down process for bed leveling. While I think it would be great to do that in firmware, I can already do that with startup Gcode in the slicer so why waste that space in firmware?
One more idea but again it seems this requires cooperation of slicer and firmware: there's 20+ pages of discussion of the "bulge" (or buldge [sic]) issue in these forums. If there only one thing the Prusa devs could work on, I would pick this one, and I strongly expect it requires both slicer and firmware improvements.
Hi guys
I agree with the points raised. Bob's suggestions for an automated nozzle change procedure and a live z calibration approach would indeed improve user experience. Deciding whether certain features belong in firmware or the slicer can be challenging, but it's essential to strike the right balance.
RE: What would you like to see in the 8-bit firmware?
Remembering the filament type loaded, like the Mini does. I'm so used to it now from the Minie that today I again pressed unload on the Mk3S and walked away, just to come back to nothing happening because I forgot to select the filament type. But I suspect at this point of the Mk3S's life cycle there's probably little desire/incentive to make more profound changes to the way it works.
Really?
RE:
So that you don't have to create separate gcodes for every filament but instead have one gcode and in the gcode you can pick whether you want your petg setting or your pla setting, it would be possible to add a few different filament presets to the gcode or printer.
Thanks😊
RE: What would you like to see in the 8-bit firmware?
I would appreciate a nozzle temperature offset, fo using hardened nozzles, so previous gcodes would work fine. That, or specify brass, steel, copper, tungsten, and have the firmware decide if you need a slight bump added after the gcode is read.
In other words, I install a Nozzle X, tell the printer a hardened nozzle is installed, and automatically all my gcodes bump the temp up by 5C to compensate for the lower thermal conductivity.
RE: What would you like to see in the 8-bit firmware?
Still waiting to see the ATmega32u2 source code for the mk3*
Prusa remains in violation of the software licensing terms until they do.
I'd like to see the source code for the USB-to-serial AtMega32U2 firmware for the mk3* as it was never released despite being "Open Source".
The GitHub repository:
https://github.com/prusa3d/rambo-32u2-usbserial
is incomplete, as it is missing all the Prusa changes (checked both branches).Evidence of the Prusa changes remains in Confluence:
https://cfl.prusa3d.com/display/PI3M3/UsbSerial+commands
and the command strings are still in the firmware.I started asking for the source code several years ago. Was promised it by Prusa staff numerous times. It never appeared. I was told to raise an issue on the repository, but that can't be done as the owner has disabled that.
SOMEBODY at Prusa still has the source code!
What feature/change would you like to see in the MK2.5/S & MK3/S/+ 8-bit firmware?
RE: What would you like to see in the 8-bit firmware?
I think that's what the "Ramming" part of the unload procedure is supposed to do but maybe the implementation could be different/better. MY gripe with the unload procedure is why it has to heat the bed in order to unload? If my overnight PETG print is long finished and the machine is cold. why should I have to wait 5 minutes for the bed to heat when all I want to do is unload the filament and return it to dry storage when I'm not anticipating more immediate printing?
Wasted time and electricity = wasted money.
RE: What would you like to see in the 8-bit firmware?
An automated nozzle change procedure. Unload filament, raise Z, heat to 285C, prompt through change procedure. Provide detailed GOOD instructions about the importance of nozzle spacing, how to test. Prompt through each step.
RE:
Input shaping would be nice, which also means marlin 2.1+
Not sure if possible but it would be nice to be able to cancel M109/M190.
Yes, it is. To reduce vibrations, oscillations or any unwanted effects in the system Input shaping is the best option. It also improves the system response and real-time control as well.
RE: What would you like to see in the 8-bit firmware?
since the latest PSlicer now support binary gcode and ARC g-commands.. what is the likelihood that the MK3S+ will support those? It might fix some bottlenecks in models that have many curves in them.
RE: What would you like to see in the 8-bit firmware?
Please enable the possibility to send the MMU3 registry codes via GCODE.
Sending something like M708 A0x22 X360 is a real pain. It requires to connect a PC, install putty, send messy command in a tempest of serial text events....
It would be so easy to have the possibility to send them via GCODE files.
And at least for the tube length and some others important settings, it would be great to have the possibility to set them directly from the LCD panel... 😍
RE: What would you like to see in the 8-bit firmware?
Please enable the possibility to send the MMU3 registry codes via GCODE.
Sending something like M708 A0x22 X360 is a real pain. It requires to connect a PC, install putty, send messy command in a tempest of serial text events....
It would be so easy to have the possibility to send them via GCODE files.
And at least for the tube length and some others important settings, it would be great to have the possibility to set them directly from the LCD panel... 😍
Hi, you point out that we have a Gcode `M708` to set the bowden length. As the resources on the 8-bit are tiny and precious we will not implement a LCD menu for this barely used feature.
You don't need to connect via PC or serial, you can create a SD gcode file containing two lines and start it from LCD screen.
1st line: set the bowden length with M708 A0x22
2nd line: M84 to avoid the message "File incomplete. Continue anyway?"
M708 A0x22 X360
M84
RE: What would you like to see in the 8-bit firmware?
since the latest PSlicer now support binary gcode and ARC g-commands.. what is the likelihood that the MK3S+ will support those? It might fix some bottlenecks in models that have many curves in them.
Arc support is already in MK3S 8-bit firmware since https://github.com/prusa3d/Prusa-Firmware/releases/tag/v3.12.0 more info see https://github.com/prusa3d/Prusa-Firmware/pull/2657
RE: What would you like to see in the 8-bit firmware?
An automated nozzle change procedure. Unload filament, raise Z, heat to 285C, prompt through change procedure. Provide detailed GOOD instructions about the importance of nozzle spacing, how to test. Prompt through each step.
Thanks for the suggestion, but the resources on 8-bit platform are tiny and precious and making it more detailed will be too costly. We have a menu Nozzle change since https://github.com/prusa3d/Prusa-Firmware/releases/tag/v3.12.0 The menu also has a link to prusa.io/nozzle-mk3s which explains thing in more detail.
RE: What would you like to see in the 8-bit firmware?
beep indication - printer heated up and ready for print
RE: What would you like to see in the 8-bit firmware?
Hey,
The one thing i would like to know about to create filament temperature preheat presets.
Regards,
Rajesh Pawar
RE: What would you like to see in the 8-bit firmware?
I don't know whether this is firmware, or the slicer, but I'm assuming firmware. I hope this is the right place.
At the start of each print, the nozzle goes to the front left of the plate for calibration and nozzle cleaning. It would be much less wear and tear on the plate if this position was varied, e.g. a random spot along the front (or any other) edge, or an offset from where the object will be printed.
That would spread the use across the plate.