ahoeben

"Compatibility mode" is limited to what it can do. If compatibility mode could do everything, it would be the only mode.

The mesh needs to have normals.

Either downgrade to version 4.6, or wait patiently for version 4.9. It has been fixed, but the fix has not yet been published in an official release.

It is somehow comforting to know that PrusaSlicer is also not without its issues.

@PricklyPear could try disabling the ArcWelder setting in Cura to save a gcode file, and then manually launch the ArcWelder command from a terminal and copy/paste the output here: /Users/iMac2011/Library/Application Support/cura/4.8/plugins/ArcWelderPlugin/ArcWelderPlugin/bin/osx/ArcWelder --log-level=DEBUG -m=1000000 -t=0.01 -r=0.05 -s=1.0 -a=12 path/to/file.gcode Obviously, the path/to/file.gcode part should be replaced by a (relative or absolute) path to the saved gcode file.

The processing does not happen until just before the gcode is saved to disk or printed. The plugin does not affect the actual slicing (which is also why the effect of the plugin will not be visible in the layerview). The ArcWelder command returning an exit status of -11 means it encountered a "Segmentation vault" ("it crashed"). Hmm, I have no idea why it would crash. Let's see if pinging @FormerLurker works.

@davispw and @PricklyPear, here is a new development snapshot for you to try. I don't think it directly fixes your problem, but at least it should show more details about what is going wrong in the logs (so if you try it, a new Cura.log is appreciated). @macmaddog, I really cannot help you without your log files. You can find cura.log via the Help -> Show configuration folder... menu-item.

Look up! The model was somehow placed high above the buildplate. This is a known bug in Cura, which has not yet been fixed for future versions as far as I know. Use Command+A to select all objects, and then use the move tool panel to reset the Z to 0.

To clarify: my response above was about creating an M1 native version, in reaction to the remark that Apple boats that updating applications should be easy. To keep Cura working with newer versions of OSes and drivers is an ongoing battle.

That is unfortunately fairly unlikely. Cura uses a lot of components that are not written or maintained by Ultimaker. A GUI framework called Qt, a language called Python. These are very bug projects, and it will take time before these run natively. But even then there is the problem that upgrading to newer versions of these dependencies mean that Cura will no longer work on older OS X versions. Native support for M1 is slated for Qt 6.1. Version 6.0 of that framework requires OS X 10.15 or newer. Cura currently uses Qt 5.10, which supports OS X 10.11 and newer. Updating to a version of Qt that is native to M1 (once that is available) means dropping support for all Macs that still run 10.11 - 10.14. OS X 10.14 is only 2.5 year old.

Hmm, strange. Can you please post a link to your Cura.log file?

If you are not getting a decent print out of a new Ender, I would suggest finding a Creality or Ender specific usergroup somewhere. I don't have a Creality printer, so I don't know the specifics of why M117 would not work on your printer.

The Start Optimiser plugin available in the Marketplace has an option to do exactly this.

Hmm, strange. Can you post a link to your Cura.log file?

I'll let you know when I make one, but that may not be until next year...

Some settings in Cura are a child of another setting; in the settings view they are "indented". As a general rule, if a setting has a child, only that child gets used by CuraEngine. The values for "Line Width" and "Wall Line Width" are not actually used by CuraEngine. Instead it only looks at "Outer Wall Line Width", "Inner Wall(s) Line Width", "Top/Bottom Line Width", "Infill Line Width" and "Skirt/Brim Line Width". The Line Width setting is there as a convenience to setting/affecting all the line widths in one go; by default the children of the Line Width setting use a formula based on the Line Width value (most of them just copying the Line Width value). Unless ofcourse you or the profile you use has put a non-formula value in one of the child settings. Then what you put in the Line Width will no longer affect the value of that setting.

That is not infill. You may want to check out this topic:

I'm adding more logging to the plugin, so it will be easier to diagnose the reason why the plugin is not working. Can I ask you to test a development snapshot?

Thanks for reporting. Fixed here: https://github.com/fieldOfView/Cura-ArcWelderPlugin/commit/2edee70f07aa493737bd5dff2ab5567ec167fd33

Something along the line of "Remove overhanging features" might better indicate that the model is being modified.

On top of the settings, there is a search field. Do you see the settings if you type "Arc" there?

If your printhead is 4.65mm above the buildplate when it is done leveling, you should add a homing command after leveling so the printhead is at Z = 0.

Looking at both your gcode and the project file, I am still not quite sure what your problem is. Have you tried printing without a raft?

Unless you share a project file or at the very least a gcode file, we can't know what is going on.

In all the cases that have been reported to me so far, it turned out that the network connection between Cura and the OctoPrint instance was failing. A version of the plugin that does not throw the error is awaiting approval for the Marketplace, but if the network connection has indeed failed it will not be able to send prints to OctoPrint either. In case your network connection is not the problem, do you use any sort of OctoPrint plugin to turn the power of your printer on/off?