ahoeben

Perhaps if you tell us about your computer (OS, GPU), your Cura setup (what sort of printer, did you use the Custom FFF Printer or a predefined one?), and post your logs somewhere we can access then, we would be able to find out what is going on on your installation.

@Sanych, I can't help you if I can't read what your problem is.

M190 S25 only waits for the bed to *heat up* to 25 degrees. Since the bed temperature directly after printing will be higher than 25 degrees, effectively it will not wait at all. According to the Marlin documentation, it should be possible to wait for the bed to cool down by specifying the temperature with R instead of S: M190 R25 https://marlinfw.org/docs/gcode/M190.html Two caveats: * I don't know if the flavor/fork of Marlin in the S5 supports the R argument for M190 * It may take a very long time for the bed to reach 25 degrees, especially in the summer. There will be no way to "abort" the wait, other than aborting the whole print including the part(s) that come(s) after the cooldown.

I don't have access to a SnapMaker A350, so I cannot help you with the values to use, but I can help you with the what to meassure. The X min value is the horizontal distance between the left side of the printhead and the tip of the nozzle. The Y min value is the horizontal distance between the front of the printhead and the tip of the nozzle. The X max value is the horizontal distance between the right side of the printhead and the tip of the nozzle. The Y max value is the horizontal distance between the rear of the printhead and the tip of the nozzle. The gantry height is the vertical distance between the buildplate and the bottom of the horizontal extrusion the head moves over when the nozzle touches the buildplate. Each of these 5 values is only used when you print in "one at a time" mode. If you don't use that mode, the values you enter here are not critical.

"OpenGL 1.1" suggests that even though you may have tried to install a driver for your Radeon card, the one that is used by Windows is the "Microsoft VGA driver". This is the fallback driver that Windows uses if no driver is found to run a video card so it can at least display something. So either the driver you downloaded was not successfully installed, or something is preventing the driver from starting/running. Note that this affects the performance of your system greatly, because that touches the display is now done in software instead of using the hardware of the graphics card you have. Not just Cura, but everything including Explorer windows, your browser, etc.

If you print via OctoPrint, a view of the webcam that is configured in OctoPrint can be shown there.

To get the obvious out of the way: did you install recent drivers for your GPU?

Have you *tried* it though? Your large format printer should still support the M83 command: https://marlinfw.org/docs/gcode/M083.html

It would also be possible to write a postprocessing script that would rewrite the E-values and remove the G92 commands. The upshot of that solution is that it will work with future updates of Cura.

This is normal for USB printing. What picture do you expect?

Very few people have printers with 8mm nozzles. Perhaps you could ask 3d Wasp if they have a working Cura profile for their printer (or what other slicer they suggest you use). Or you could tell us what problems you run in to when you try to make a profile yourself, and perhaps we can help you. In theory it should be as easy as starting with a "Custom FFF Printer" and setting the Nozzle Diameter to 8 mm in the Machine Settings. Briefly looking at your other post on this subject, I can tell you that Cura normally expects to print in "loops". If you take a model and make a cross-section, Cura will - in its simplest form - trace the outline of that cross section. This means that if you make a model that is 8mm wide to be printed with an 8mm nozzle, Cura will still do two passes "around" the model.

You could try switching to relative extrusion instead of absolute extrusion (see the Special Modes category). This will effectively remove the extruder resets, but has precision issues of its own.

The red "overhang" indicating overhang where the model touches the buildplate is just a visualisation artefact/oversight. It does not affect slicing.

If they are large, and things are running ok now, feel free to throw away cura.log now. The file will be recreated, and be much smaller (until it is big again 😉 )

@GAD: logs? See Help -> Show configuration folder -> Cura.log

If you must raise something, riase an Exception instead of a SyntaxError. Because the error is not related to the syntax at all. I would advice against removing all gcode, because the user will not see that and an empty file will be saved but Layer View will still show the original sliced layers.

If the file is an STL, the file is not a project. You seem to have used File -> Export... instead of File -> Save...

Why raise a SyntaxError though? That's like using a hammer to stir your coffee. Wouldn't a simple "return" work?

What do the logs say?

You can use Extensions -> Cura Backups -> Manage backups to backup on one computer and restore on the other. But I guess you would like to have something that happens automatically? You could do that by using eg dropbox to sync the Cura configuration folder between the two computers. See Help -> Show configuration folder.

A fixed version of the Material Settings plugin is now available in the Marketplace.

Any suggestions? I am trying to disambiguate "window" between window representing the folder that the executable is in and the running application.

I'm sorry about that. It seems to have happened with a subset of printers, which is why it was not detected before. A fixed version of the SidebarGui plugin has been submitted to the Marketplace but is awaiting review. You can download the fixed version here: SidebarGUI plugin curapackage To install it, you first need to get Cura back to a running state by manually removing the plugin, as you did. I'm including those instructions in case someone else runs into a similar issue. Press the windows-key on your keyboard and type (exactly, including the % signs) the following, followed by enter: %APPDATA%\cura\4.4\plugins In the folder that opens, remove the folder named 'SidebarGUIPlugin' Now you can start Cura again. Once Cura has started, drop the .curapackage you downloaded above into the application window. Restart Cura, and the sidebar gui should be working again.

For the record, I did not mean to offend you. But you did not give us much to work with. Your clarification helps in getting your problem across, but there is still not much I can say about the cause of it. If you could share a Cura.log file (which can be found via Help -> Show configuration menu), there might be things in there that could give a hint about what causes the issue.

I'm not sure if I understand what you are asking, but you can zoom in (mouse-wheel or two-finger scrolling on the touchpad).