Marco_TvM

As @WesleyE mentioned, there is a chance of buffer underruns happening when lots of small gcode is being generated. If this happens, it would be interesting to see the numbers. For this, you can use the URL HTTP://<printer_ip>/api/v1/debug/marlin/errors which shows you a number of statistics of the serial protocol used by Marlin. If the planner_buffer_empty increases dramatically, this indeed means a buffer underrun.

With an integrated Scotty AI?

Thanks a lot for the logs @Polarice ... I've seen something strange happening in your case that warrants further investigation! For those who want to see for themselves (and maybe have similar messages): see boot-5.log... Edited: Can you do the following: 1. Reboot the printer 2. Then upgrade the firmware? It looks like your /tmp (tmpfs) is full which causes problems. Rebooting the printer clears it completely.

Thanks a lot for the logs @Polarice ... I've seen something strange happening in your case that warrants further investigation! For those who want to see for themselves (and maybe have similar messages): see boot-5.log...

Hello Kees (sounds Dutch?), The problem here I think is that when you keep only doing the step one as you describe (rotating the wheel) to move the bed and then loosening up the screws all the time, you will end up with all screws indeed being unscrewed. Or at least, that might happen. May I suggest the following. Only do manual leveling when it's really necessary. Try to rely on the automatic procedure after doing it (maybe once a month or so). Before doing the manual leveling... tighten the screws completely so the springs are really compressed. This goes for all 3 of them (2 front left and right and the one in the middle at the back) Then loosen up all screws like a complete 1/2 or 1 full rotation Perform the normal manual leveling as described in https://ultimaker.com/en/resources/23127-build-plate-leveling Hope this helps you with doing the manual leveling.

The material profiles are not stored on the eeprom of the Print Core. The new profiles come from Cura, the default ones are stored on the printer. @gr5 also made some script to create profiles for print cores, see A Print Core is being identified by a number of fields stored within it's eeprom for the type, manufacturer, nozzle size and a few more. The format of this has not been specified, as far as I'm aware of, but maybe @SandervG can shed some more light on this? You can also look at where @gr5 seems to be 'hacking' a bit to program cores. This might help you with your own third party print cores, but use it at your own responsibility. For the time being, I think it's the responsibility of the third party print core builder to have the eeprom programmed correctly.

I think you need to contact the third party supplier. The Print Cores have to be programmed with a nozzle size, in your case 0.4. If they are Print Cores without an EEPROM, they can not be identified by the printer. For now, there are no plans to make this something configurable on the printer, as in selecting a custom printcore with settings. I'm not sure, but I think Cura would allow to override this?

The printer cannot distinguish between Generic and color generic... because the menu structure to make that would be quite cumbersome to work with... Hence PC (Generic) and only NFC detected PC (White/other_colors). Because that doesn't match with Cura's selected profiles for slicing, you have to agree to override. I think this is a question for Cura and not the firmware section. So maybe @Msuurmond is able to answer this.

Maybe I'm missing something, but these do not seem like the normal log files to me. How did you make/get them?

This may be there in the next testing release, with luck, at the end of the week.

Thanks, checking ...

No it would not. I do see your point, but fixing this is not yet on our board of things to do soon(tm).

Ok, some more info. Not entirely by design, but because of Marlin... Marlin only supports one speed for flow speed for all possible extruders. There is an issue on the backlog to fix this, but it's not a priority right now.

This is by design, so not a bug. I think @Daid might shed some light as to why. If you want to use different speeds tho, you can use the settings in Cura to make it so.

What happens when you try to download the new stable firmware? It would be good to see the messages on the screen and preferably have the log. Even after it seems to be stuck, using the System -> Maintenance -> Diagnostics -> Dump logs to USB might give some insights in what might be going wrong.

That is fine, no rush.

@cjs : I think @Indy31 summed it up quite nicely. Custom materials should stay on the printer after a firmware update. However, a factory reset will remove them. As for the latter, about submitting material profiles to be shipped with the firmware, the firmware only uses the fdm_materials repo. Cura is more in control because they use the profile to create better gcode. Hence, I'll put this request forward to the Cura PO.

Check the connection with System -> Network -> Connection status. This will provide the information to check whether or not the printer has gotten a valid IP address, how it's connected and it's associated MAC address.

It would help to get the logs when this happens, using System -> Maintenance -> Diagnostics -> Dump logs to USB and send them either by using something like WeTransfer or attach them. That way we can see which firmware is being used (missing in the report) and the state of the printer logic being used.

Check out the WEB API to add materials: http://<printer-ip>/docs/api/#/Materials This will allow you to add material profiles (files) you have created, outside of Cura.

If you can explain what kinds of problems you're having, there are a lot of people here that might help you with your issues.

Food for thought... But I doubt we'd have the processing power to implement voice recognition.

I'm so tempted to make this work...

I will take the idea up with the PO (product owner).

When I know more etc. I will keep things posted here.