berndjm

I had already mentioned the problem here for the 3.4 beta, unfortunately so far without result ... As far as I know, this problem starts with the 3.4 version, where they changed the plugins download handling.

Nun, "der untere Bereich" und "der obere Teil" "deines Objektes" ist halt nicht wirklich aussagekräftig um dir einen gezielten Rat geben zu können, ein Screenshot könnte da schon etwas Licht ins Dunkel bringen. Generell hast du 3 Möglichkeiten den Support zu beeinflussen: - das "Support Placement" ob nur vom Druckbett aus oder überall - den Support Überhang-Winkel - seit 3.3 den Support-Blocker, ein definierbarer Bereich in dem kein Support erstellt werden soll Nebenbei bemerkt: in einem überwiegend Englisch-sprachigem Forum die Frage auch auf Englisch zu stellen erhöht die Chancen auf eine Antwort drastisch ? ==== Well, "the lower part" and "the upper part" of "your object" is just not really meaningful to be able to give you specific advice, a screenshot could bring some light into the darkness. Generally you have 3 possibilities to influence the support: - the "Support Placement" whether only from the print bed or anywhere - the support overhang angle - since 3.3 the support blocker, a definable area in which no support is to be created Incidentally, asking English in a predominantly English-speaking forum also raises the chances of an answer drastically ?

Phew, I'm afraid this is far beyond my knowledge horizon. Even if I can use a tool like wireshark or tcpdump, the output lines far exceed my understanding. I have not the slightest idea what I should pay attention to. ?

Yes of course there is an internet connection. And no VPN, no other fancy stuff. Even in 3.3.1 installing plugins works without any problems.

Ah, ok, you're using the AppImages. I was a bit missleading that you wrote ? Just of curiosity: is the Ubuntu installation you mentioned on the same pc as your LinuxMint installation? If it is, the problem couldn't be the grafic card. There must be some missing opengl related files in your Mint installation which - for whatever reason are present - in the Ubuntu installation ...

Unfortunately with the AppImage (Linux Mint 18.3) this doesn't work ?

May some missing opengl related components (e.g. python-opengl ...) But to be honest, since they have Cura for linux as an AppImage I save myself the annoyance of outdated or uninstalled versions of any required software components. Just start the AppImage and be happy ;-)) As a "bonus" you can have all the version parallel together without any fear about overwriting something ... (just for the records: LinuxMint Cinnamon 18.3))

On linux the script should work located in /home/[YOUR_USERNAME]/.local/share/cura/3.3/scripts

Just played around with the support blocker feature and think I understand now why people may have problems using it. Indeed the handling is not very intuitive. Why I must a.) first select a model to activate the blocker tool, than b.) select the blocker tool, than c.) click on the model where the blocker should appear? Any chance that the (IMHO unnecessary) step a.) could be avoided?

o.k. these messages seems to be "normal" - get the same here (Linux Mint 18.3) but it runs as expected. Only out of curiosity what Linux do you use? Also have a look in your homefolder for the hidden folder .local/share/cura there should be the files stderr.log and stdout.log and a folder 3.3 with a file cura.log inside. Maybe in these files is a hint what's going wrong ...

You could try to start the AppImage in a terminal to see if there are any error-messages. Open a terminal and move to the folder where your AppImage resists, then type ./Cura-3.3.1.AppImage

@chuckmacgee: You're right. In my test-case I didn't realize that the Z1 is a problem, because on 0.2 layer height pause at layer 5 = Z1 ?

Hi Siggi, can you please check if this also happens if you use a height instead layer-no. ? For me it seems, that this (new) feature to use layer-no's is still a bit buggy. See also here.

You have enabled the so called "Compatibility Mode". Check this under "Preferences" "General" "Viewport behavior" ...

If using the Pause at Height Plugin with layer-numbers instead of height there is an unexpected move to x 0 y 0 before resuming the print. gcode with pause at height: gcode with pause at layer:

Thanks so far, this helps a little bit. But it seems I have to configure some things from scratch :-( RuntimeError: QualityChangesGroup[<4 - Adaptive & Support>, available = False] tries to overwrite the existing node_for_global QualityNode[fdmextruder_4 - adaptive & support] with QualityNode[k8200_4 - adaptive & support]

Yes I have two variants for my printers for different nozzles, what exactly must be updated? [general] name = 0.4 version = 2 definition = K8200 [metadata] author = BerndJM type = variant setting_version = 2 [values] machine_nozzle_size = 0.4

The 3.3.0-BETA AppImage chrashes on start :-( System information: Error traceback: Traceback (most recent call last): File "<frozen importlib._bootstrap>", line 969, in _find_and_load File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 664, in _load_unlocked File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible File "/build/env/3.3/inst/lib/python3.5/site-packages/cx_Freeze/initscripts/__startup__.py", line 12, in <module> File "<frozen importlib._bootstrap>", line 969, in _find_and_load File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 664, in _load_unlocked File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible File "/build/env/3.3/inst/lib/python3.5/site-packages/cx_Freeze/initscripts/Console.py", line 21, in <module> File "<frozen importlib._bootstrap>", line 969, in _find_and_load File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 664, in _load_unlocked File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible File "/build/3.3/build/inst/bin/cura", line 141, in <module> File "/build/3.3/build/inst/lib/python3.5/site-packages/cura/CuraApplication.py", line 649, in run File "/build/3.3/build/inst/lib/python3.5/site-packages/cura/Machines/VariantManager.py", line 76, in initialize KeyError: 'hardware_type' Any hints, where to look for this "KeyError: hardware_type" ?!?

So, little sleeping and thinking about a problem sometimes helps ;-) The script gets confused in the second run (for the higher located pause) from the "G1 Z" lines inserted in the first run. Reverse the order for the Pause at height (from highest to lowest) solves this issue. A little less intuitiv, but it helps ;-)) Maybe this is just another argument for a "Pause at layers" @tinkergnome ;-))

Im using Cura 3.2.1 Appimage. Just noticed, if I try to use the "Pause at height" more than once it doesn'T work correctly Above is an exerpt from the generated g-code. There should be a pause at 0.8mm and the other one at 1.6mm As you can see, the code for the second pause is inserted immediate before the code for the first pause. Additional the 2nd pause records a false current height (should be 1.6)

As far as I remember the user (= you) that runs a software which should communicate with usb-ports must belong to the group "dialout" to use the ports. Give it a try, just open a terminal an type in sudo adduser xxx dialout where "xxx" is your username.

I think it's not so easy to detect the "real outside" and at the same time handle cases where the currently behavior makes sense. See this simplified use-case: Here it could be helpful to have the brim also inside the object. I think to have a adjustable threshold (is this the right word?) for the outside detection would be nice ... but how to handle than the two parts close together like in your 2nd screenshot?

Indeed Cura makes the brim "outside" but it didn't recognice correctly what is "inside". There are quasi "insides inside insides", tried to visualize this here: If you set the brimline-count to 1 or 2 it becomes better visible how cura thinks, for example the "O" Because there is part 1 inside part 2 there "must" be A the outline for part 2 and B the outline for part 1

In some cases it's unnecessary in other cases it absolutely makes sense to handle the pause via layer-numbers. For example: I often make two-colored nameplates (with one extruder). The base-plate is 0.8mm high, the letters in another color are 0.4mm. Now I know, the pause had to happen at the end of 0.8mm (the 4th layer in my case). But if you have a unknown model (let's take this for example, which could be a nice multicolor print with one extruder) it is much easier to scroll through the layer view and say: "o.k. at layer x is the first color change on layer y the next", and so on...