ahoeben

A list of machines and firmware versions. And Cura does not generally know what firmware is being used by a printer. The ArcWelder plugin is a plugin that the user needs to install. Even when installed, there is a setting that needs to be enabled for the plugin to start doing its thing for each configured printer in Cura. Cura has many more settings that can screw up prints if they are enabled willy-nilly. I don't think Cura (and plugins) should warn on every single one of them.

It looks like that is a bottom layer, which does not have infill.

Do you have the “Spiralize outer contour” setting turned on? In that case there is no infill, no matter what pattern or density you select.

Just to confirm your logic, have you tried slicing and printing a calibration cube with your settings? Eg this one: https://www.thingiverse.com/thing:1278865

Generally speaking there is no way for the plugin to know if the firmware supports arc commands. Perhaps I have turned it on in my custom Ultimaker Marlin build.

Are you by chance using the ArcWelder plugin? It looks like the firmware for your printer is not properly configured to support it. Edit: yes, you are using the ArcWelder plugin. What you are seeing has nothing to do with slipping buildplates, or whatsoever. The ArcWelder plugin has changed multiple G0/G1 commands of the curved parts of the walls to G2/G3 arc commands. However your printer firmware (and Cura, when loading in the Gcode) does not know how to handle G2/G3 commands so it just ignores them, including the end coordinates of the curved walls. The next (linear) move is then made from the last printed linear point. So you get lines from the beginning of one straight part of the wall to the beginning of the other straight part of the wall, without going through what would normally be the end of the straight part of the wall. This makes the wall look rotated. The inner wall is printed in the other direction, so the "endpoints" of the straight parts of the wall are in the other direction. This makes the inner walls look rotated the other way. In reality there is no double or rotated printing; just ignored gcode commands. Long story short: your firmware does not know how to handle Arc commands. You enabled a plugin to specifically convert gcode to have Arc commands. Disable the option to do ArcWelder postprocessing and/or uninstall the plugin entirely. Alternatively you can update your firmware to a version that does support G2/G3 arc commands.

It could be the printer was tested in the factory, and the test-procedure left some material in the hotend. But in any case, it would make more sense to inform if you should worry about this from BIQU support, or a community of BIQU users.

That is not entirely accurate. With plugins you can print to other printers too, but this may not be well integrated into the "Add printer" dialog. You may first have to add the printer as a non-networked printer, and then do additional steps to configure it to print via the network through the appropriate plugin.

I can understand this is confusing, but these are two different types of backups. The regular cura backups that you can do from the Extensions menu are backups in the cloud. The backup that Cura offers to do when it crashes during startup is creating a local zip. That zip can be found one folder up from your configuration folder. Go to Help -> Show configuration folder... and in the explorer window that opens go one folder up. That folder contains one or more zip files, and the latest one contains all your previous configuration files. Restoring those (manually) to the configuration folder will get you back your preferences and profiles, but depending on what went wrong the first time, it may also put Cura into a crashing state again.

What Ultimaker printers have you looked at? Do you need multiple extrusion? What is the maximum size print you want to make?

Well, one thing you are doing wrong is reading the version number of Cura. There never was a Cura 2.10, so I am guessing you mean Cura 4.10.

Then don't do this. It may work on casual tests, but it can lead to clogs and the material buckling in the bowdentube or hotend. Your printer was not made to handle 1.75 mm material.

Have a look at the Automatic Slicing Toggle plugin: https://marketplace.ultimaker.com/app/cura/plugins/fieldofview/PauseBackendPlugin From the QML button you could do this: https://github.com/Ultimaker/Cura/blob/master/resources/qml/ActionPanel/SliceProcessWidget.qml#L40 Or from Python you could do Application.getInstance().getBackend().forceSlice() Having said that I still recommend you to implement this in a way that fits better with the normal Cura workflow (adjusting models and settings, slicing, previewing and then saving/printing), instead of going around it. What sort of standalone GUI are you talking about? Could it be integrated into Cura, as a stage? You could have a look at the Teton Smart Slice plugin.

Unless you have the means and time to debug Cura and your printer, you may be out of luck. Ultimaker does not actively develop the code for printing via USB, since current Ultimaker 3d printers do not support printing over USB. So if it does not work with your printer, Ultimaker are not going to put development time towards a solution, unless someone else does the problem finding and fixing work in such a way that it does not further cripple other printers. Your alternatives include printing via SD cards, using a program like Printrun to send the gcode that Cura created to the printer, or installing OctoPrint and the OctoPrint Connection plugin and have an integrated workflow in Cura.

What is wrong with the button that is already there? What do you want to do that can not be done in the same way that for example the Z Offset plugin acts on the gcode?

Do you have Chitubox installed on the same computer? If so, read this: https://support.ultimaker.com/hc/en-us/articles/4402996140946-Ultimaker-Cura-crashes-when-opening-any-file

That is not how a tool should work in Cura. The toolbuttons in the toolpanel on the left are meant to activate tools that manipulate the models on the buildplate. It would be more in line with how Cura works if you add a setting to enable your postprocessing code, like for example the Z Offset and Linear Advance plugins do: https://github.com/fieldOfView/Cura-ZOffsetPlugin https://github.com/fieldOfView/Cura-LinearAdvanceSettingPlugin Those plugins show you how to apply your postprocessing code when the user saves a gcode file (so the file that gets saved is processed).

The model is "broken". It contains missing or extraneous faces, which confuse Cura. The polkadot pattern shows where the model has issues (ie: a lot of issues!). In addition to the missing or extraneous faces, the normals are broken (but those should not affect the slicing much). Some of the normals are inverted (causing the red faces on top).

It sounds like the Microsoft Visual C++ Runtime libs are not (properly) installed. But they come with the Cura installer, so they should be.

Your take is perfectly valid. Cura only looks at these things one layer at a time. Any wall that is entirely inside an outside wall is considered a hole (and gets the Hole Horizontal Expansion treatment). The intrusions on the outside wall connect the outer wall to what was an inner wall in previous layers, making that "inner wall" part of the outer wall. So it is no longer considered a hole. One way to think about it is if the layer is surrounded by "2d" water. Outside walls will get wet, inside walls stay dry. Only inside walls are considered holes. A protrusion as discussed before would make the formerly "inner" wall wet. (However, realize that there can be another outside wall enclosed entirely inside the inside wall, and an inside wall inside that, etc; the "water" metaphor is not perfect).

No it is not. The bug that this thread is discussing caused the renamed printer to revert back after a restart. You have hit a particular case of "known behavior". In your case, you are trying to rename the printer to a name that is already taken up internally, so Cura adds the number (" #2"). You can rename the printer to anything other than the name without the "#2" postfix, and the rename should work.

The dark blue bits extend under the buildplate. They are effectively cut off when slicing.

That release from back in februari did not add or change anything for files sliced with Cura, so I never got round to making a new release with just that version update in it (because it would not change anything). Instead I waited until I had some more time to fix bugs/issues on the Cura integration side of it. At the same time I made sure to have the plugin use the same terminology and order of settings as the official documentation. It is not a big update.

Any bits in particular? All settings are now documented in the plugin readme, which can be found here: https://github.com/fieldOfView/Cura-ArcWelderPlugin#readme The documentation is mostly copied from the original ArcWelder project.

Add firmware compensation toggle setting Add allow dynamic precision setting Remove incorrect minimum/maximum values for resolution Align setting names and defaults with ArcWelderLib Update ArcWelder executables to 1.1.1 Add documentation to readme