ahoeben

I'm in talks with a client who wants me to develop a slice-at-an-angle plugin. It will be an open sourced plugin for Cura. I can't divulge much detail at this point, but I would be surprised if it had not materialised in half a year.

Yes, this is very clear. I might have something for you in half a year or so. Maybe sooner.

You should use replacement patterns with curly brackets like so: M104 S{material_print_temperature_layer_0} ; sets hotend temperature for bed leveling (warm but not dripping) M140 S{material_bed_temperature_layer_0} ; sets bed temperature layer_0 for your material M109 R{material_print_temperature_layer_0} ; sets hotend temperature for bed leveling and wait until temperature reached M190 S{material_bed_temperature_layer_0} Cura looks for those replacement patterns (ie: the text + the curly brackets). If your start gcode includes those, Cura will not add its own preheat sequence.

Or better yet, create a pull request to have the files included in Cura so users like you don't have to keep manually installing the files when a new version of Cura is available.

In this thread is one place, but the official place is here: https://github.com/fieldOfView/Cura-ArcWelderPlugin/issues The particular bug has been mentioned before in this thread. The latest development snapshot should fix it. Download the file and drop it on the Cura buildplate as if you were opening a 3d model.

Windows is just being difficult. In order to use OpenGL, an application needs to ask the system if it is possible to do so. If the system says "no, it is not possible", there is nothing the application can do about that. To put it in another way: if you ask your mother for a piece of pie, and your mother says "no, we don't have pie", you are not going to have pie. Now, if your mother already gave you pie before, and you did not yet eat the pie, you can still have your pie, even if your mother thinks there is no pie in the house.

The plugin doesn't do anything automatically. You have to select the model after it is loaded, and then to to Extensions -> Barbarian plugin -> Convert to metric

The Ultimaker 2 family of printers know (and use by default) a gcode dialect named "Ultigcode". The idea is that the user selects the material on the printer instead of in the slicer, so a single gcode file could be printed with different materials. Effectively the start gcode and heating the bed and extruder are inserted on the fly by the printer firmware. The printer has to know if the current gcode file is using this Ultigcode dialect or normal Marlin, because it needs to know whether it needs to insert its start sequence. And it does so by looking at (only) the very first line of gcode, which in the case of UltiGcode must be a comment line stating that the file is an ultigcode file. ArcWelder put diagnostic comments in front of that; in the new version I am putting the preamble comments made by the slice back in front of your comments. Printing Ultigcode over USB has never worked and will never work; there is no way for the printer to know when you start a print vs just issuing separate gcode commands, so the printer would not know when to insert its start gcode. In other words, Ultigcode works for SD-card printing only. And the issue that ArcWelder is trying to solve is not very prevalent in sd-card printing in the first place. I would not soil your code with this very limited usecase. PS: newer Ultimaker printers don't use UltiGcode anymore. Instead they use "Griffin" gcode. Yay. But at least it seems to be less picky about detecting Griffin vs Marlin.

I don't know about your printer or the BL touch. If you are really committed to trying to fix this in the gcode instead of fixing your printer, then you will have to edit the plugin. The minimum value that is accepted by the plugin is defined here: https://github.com/fieldOfView/Cura-ZOffsetPlugin/blob/3.5/ZOffsetPlugin.py#L29

They meant to say "You can mirror your model along the YZ, XZ and ZY planes", ie the planes perpendicular to the positive X, Y and Z axes.

God will provide. This is the type of thing where as a programmer you can't really be sure how long it will take to fix until you fixed it.

Ok, then just don't use the "print as support" option for these types of supports.

The problem with your meshmixer supports is that by default Cura "projects" the top of support meshes to the buildplate. Try adding the "Drop Down Support Mesh" setting to the meshmixer supports (in the Per Model Settings) and unchecking it.

You realise you did not answer the question, right? But given the firmware versions you mentioned above, I can assume you mean an Ultimaker S5.

This sounds like somewhere in your workflow there is an inches to mm transition. The STL format does not specify a unit, so Cura (along with many other applications) assumes the coordinates in the STL file are in mm. It seems SOLID EDGE may have exported them in inches instead. See if there is a preference in SOLID EDGE to export in mm instead of in inches.

To clarify, since the OP in this post has a Creality CR10 S5, do you mean an Ultimaker S5 or another S5? Looking at your image, the plugin is only going to make any difference for models with curvy details. Your stutters seem to happen on a straight line, which the plugin will not be able to help you with.

You could give the ArcWelder plugin a go. It is created specifically to reduce the amount of gcode needed to draw a curve. There's a version of it in the Marketplace, but it may not work on all systems. I'm currently testing a new version before it gets published to the Marketplace. Check it out here:

This is indicative - to me - that your gpu driver is the problem. Either you don't have a properly installed driver for your gpu, or the driver specifically excludes support for OpenGL. I would not think the latter is likely.

The plugin takes the currency from Cura (as set in the General preferences). If the currency specified in the csv file and in Cura does not match, the plugin will tell you so and (at this point) won't import the values. I have considered adding currency conversion in a future version, but sofar other projects have been more important.

Version 1.1 of the ArcWelder tool was released. Here's a new development snapshot that includes the new binaries. The new binaries should fix the plugin not working on some windows systems, as well as on OS X. It also fixes compatibility with the UM2 family of printers using UltiGcode (by moving the orginal gcode header back to the top of the file after processing). Please let me know if this version processes the gcode for you, especially if previous versions would not. .

The problem is that when Cura asks your system if it supports at least OpenGL 2.0 (after first asking if OpenGL 4.1 is supported), your system says "no". Are you perhaps trying to start Cura over an RDP ("Remote Desktop") connection? If so, that is known to interfere with your system reporting about its OpenGL capabilities.

As far as I can remember, it has never been a feature of Ultimaker Cura. Perhaps you used another version such as Lulzbot Cura before?

If you increase the Line Width, what happens is that the printer extrudes more material than with the smaller line width. The additional material gets flattened out by the "shoulders" of the bottom of the nozzle tip (ie: the flat part of the bottom of the nozzle tip to the side of the nozzle hole). If you increase the Line Width too much, there some material may "curl up" beyond the shoulder and stick to the nozzle for a bit. Material that is kept at extrusion temperature for too long may carbonize ("burn"). If it does, and then gets pulled off the nozzle, you get the burnt mark.

Thanks, but the amazing part of the work is done by @FormerLurker; my plugin is just the glue between Cura and his ArcWelder application.

@macmaddog if you are still interested in getting the plugin working, can you test this development snapshot? Download the file, and drop it onto the buildplate in Cura as if you were opening a 3d model. This latest version contains fix for the ArcWelder executable not being able to run to the plugin does not initialise its setting on some Windows installations. Previously I incorrectly assumed you were using a mac, because of your username :-).