ahoeben

Perhaps the material diameters are different between the extruders? See the Machine Settings on the Printers pane of the Preferences, and check the material diameters for each extruder tab.

You are starting from a printer definition that does not define any extruders. Try adding a new printer, and start with a Custom FDM Printer. You'll have a choice of up to 8 extruders.

Depending on the value of the "Relative Extrusion" under "Special Modes", CuraEngine will either put an M82 or M83 before your start gcode. There's no way to tell it not to. If the M82 is bothering you, you can use a postprocessing script to remove the initial M82. The code, should you be interested, is here: https://github.com/Ultimaker/CuraEngine/blob/3.5/src/gcodeExport.cpp#L511

See Cura.log in Help -> Show Configuration folder.

Can UM3 users order and use the S5 knurled sleeve once their stock knurled sleeve has worn out?

If you print the same gcode again, does it fail in the same place? If so, please upload the gcode somewhere so we can have a look. It could be that the gcode gets damaged while writing. Do you neatly "eject" the cards, or just remove them from the reader when writing is done?

From experience of actually doing things like this (for BlackBelt Cura and my plugins), it will be plenty stable, but it will break between versions of Cura (so the plugin will probably have to be updated for each version).

Note that the checksum thing only happens when printing over USB. No checksum is involved in getting gcode data from the sdcard into the printer. @maxdd, how do you print? From sdcard or over USB? If the former, try a different card. If the latter, try printing from sdcard.

If your Lenovo has both integrated graphics and an nvidia card, you could try forcing it to run on the nvidia card. The described issue is Intel-specific.

This has been fixed for the final 3.5 Then they should be upgraded automatically by Cura. Strange that that does not work.

This is indeed not something that is possible with just configuration files. A Python plugin can detect changes to one variant, and then apply the same variant to the other extruders. That Python plugin would connect to each of the extruder stack containersChanged signal, and for each extruder stack check if the variant container equals the emitted container and if not it would change it.

The plugin triggers a bug in Cura that causes it to crash because of a custom printer definition file that needs updating: ultimaker2_duet3d_dual_0.4. Where did you install that file? In the configuration folder, or in your Cura application folder (in program files)?

Perhaps you have the latest drivers that Dell offers for the laptop, but Intel has newer drivers for your GPU. Details can be found here: https://github.com/ultimaker/cura/issues/2068

It has been there since Cura 2.6

Go to the Printers pane of the Preferences, and press the Machine Settings dialog. That has an option to set the number of extruders, and there are tabs per extruder to set (among other things) the offsets for each nozzle.

On the Materials pane of the preferences. Or, if you want to have a setting in the sidebar, you need to install the Printer Settings plugin from the Toolbox, restart Cura, and look for the material diameter setting under the new "Printer Settings" category (which also has a nozzle size setting, wohoo!) As @smartavionics points out there is also a material diameter in the Machine Settings dialog, but what is set there is overridden by the selected material. Machine Settings < Material < Profile < Sidebar (with Printer Settings)

It was moved to the same category as the Nozzle Diameter, so it is no longer available in the sidebar. At least not unless you install the Printer Settings plugin from the Toolbox.

That is because material_standby_temperature is set per extruder, so instead of the global stack you need to look at one of the extruder stacks. For example, this gets the standby temperature set for the first extruder: first_extruder_stack = ExtruderManager.getInstance().getActiveExtruderStacks()[0] material_standby_temperature = first_extruder_stack.getProperty("material_standby_temperature", "value")

De upgrade kit is al twee jaar niet meer leverbaar. De officiele upgrade kit bestond uit veel meer dan alleen een PCB heated bed en een stukkie glas. Je kocht er het hele aluminium bed en een stepper met leadscrew van de UM2 bij, plus nog electronica en een nieuwe voeding. Je "kreeg" er zelfs een 14mm hout-boor bij om een gat in de behuizing te boren voor de stekker. En een prit-stift. Vergeet de prit-stift niet. Op zich kan je via de officiele dealers (MakerPoint) alle onderdelen van een UMO+ los bestellen (moet je ze wel voor bellen/mailen, want niet alles staat op de website), en dan zou je de kit nog grotendeels bijelkaar kunnen schrapen. Je zult dan ook je electronica moeten vervangen door een UM2 bord want de losse print om het Heated Bed aan te sturen zal niet meer te koop zijn. Dan moet je wel ook weer lastig gaan doen met de temperatuur sensor in je hotend. Hoewel, het is natuurlijk wel allemaal open source... https://github.com/Ultimaker/HeatedBedUpgrade . Ze hebben zelfs een technische tekening gemaakt van het tubetje smeer dat je erbij kreeg. Maar goed, lang verhaal kort: lastig. Wellicht is zelf bouwen een optie? https://www.youtube.com/watch?v=SUb1pAB8O2k

For future reference, you can find all setting names here: http://files.fieldofview.com/cura/Replacement_Patterns.html Just remove the { and } in the first column.

What do you mean by "variable"? A python variable? There is not global python variable for the layer height in Cura. There is a setting called "layer_height". To get its value, you would call the method getPropertyValue on the "global stack". global_stack = Application.getInstance().getGlobalContainerStack() layer_height = global_stack.getProperty("layer_height", "value")

This would be more something for @thopiekar

Note that after submitting, the plugin goes through a testing process to make sure it does not crash Cura in any obvious way and to make sure it doesn't do anything malicious, which takes additional time. I currently have 4 plugins waiting for be approved, and I'm sure the plugin-testers are swamped with reviews.

Note that due to some changes in the background, all plugins needed to be updated. Not all plugins are available yet. Once they are available, you can update them through the Toolbox.

I guess it is broken then... I checked with a different gcode viewer in case it is a visualisation issue in Cura, but you are right: even when the Infill layer thickness is set to a multiple of the layer height, an infill pattern is created on every layer. Your best bet is if @bagel-orb or @smartavionics have a look at it.