Looks like we have another ticket on this: T2231. Notes from there:

Loading wiggletest.stl on 3.6.3 using Quiver with PLA 0.25mm default settings gives me 1 layer.

The main issue for this T5564 is that there are some extra travels generated? So it takes a bit longer on the first layer than it should? I'm trying to nail down what the issue is here.

"It would only display that way from slicing the stl, if I were to save, clear build plate and import the gcode I saved, the issue wouldn't appear. So when I would load in the saved gcode it would report 1 layer again."

T5471 appears to be a non-bug, as it is rendering actual travels that are in the gcode.

Ok, the first line on the left of the part is the wipe sequence for the left extruder. I'm not sure why it doesn't put in in the back left (probably because it hasn't homed Z yet ?), but that line is actual gcode. The small line to left of the part is right before it starts the print. So that is a legit gcode move as well.

I don't think this is a bug, I think it is rendering the correct travels and those travel lines are in the gcode.

You can also see these travels in the "Compatibilty Mode", so it isn't just in the new viewer. This is a screenshot of Q_wiggletest.gcode in compatibility mode with "Show Travels" checked.

@karrad The reason you didn't see moves is you didn't have "Show Travels" checked.

I don't see the lines when using wiggletest.stl, probably because we don't display the gcode start lines. See attached pic.

The travel line on the far right looks like the wiper pad. The one in the center is when the print is done. I'm not sure what the two shorter ones to the left of the part are.

Ah, if I do "Show Travels" I can see it.

When I do "Line Type" for Color Scheme, I don't get the lines, fwiw. See screenshot.

Logan has "line type" selected under "Color Scheme" not "Material Color".

@logan When I import a gcode file, the object is blue (cyan) and is just one color. Your screenshot has different colors for travel and infill, for example. It usually doesn't show this when importing a gcode file. @karrad what do you get?

Looks ok when I import the gcode, see screenshot.

Using the new layer viewer, I don't see the bug when importing the STL.

I do see an option that is off by default: "Force layer view compatibility mode (restart required)". On my workstation I can enable the new viewer by running this:

I get a different view from both of you. You have checkboxes for each extruder and mine says "Compatibilty mode" at the top of mine. Not sure what is up. This is with official 3.6.3 build. See attached screenshot.

I guess if there is a brake board on Mini2, why wouldn't one also be needed on Quiver? TBH, I'm not sure how it operates.

Maybe home Z before moving the nozzles? Or up in Z?

@derbartman "that is the wiper mount as downloaded from this web site", which website? Ours? The STL I'm looking at doesn't look like a wiper pad mount of ours, but I could be wrong.

I don't know if it is related, but I did notice this in your stderr-2nd-mid-print-wiper-base.log file:

Alloy 910 + Polydissolve would be good to have on the list, as it is our other strongest material (besides PC-Max).

Well, I'm not sure where to put it other than there for now. We do a lot more now in the git repos than we did when TAZ/Mini were started.

OnionIOT github mirrors have been set up for some of their repositories. They have over 100 and many aren't applicable. If you find one that is needed, let me know to clone it. So far cloned:

@adam What do you mean by Brizo repo? Like just a directory here, for example?

CMakeLists-repos.patch builds fine under Debian Stretch. Should work under Mac/Windows too.

This patch replaces all non-Aleph Objects downloads with URLs that point at our servers. Wherever possible, I used a git repo. In cases where that wasn't smooth to set up, I uploaded tarballs here:
https://download.lulzbot.com/Software/Cura2/build-resources/

For files that wouldn't "conveniently" use git, I have copied the files to our server:

Attached is a draft patch that built under Debian Stretch. All git mirrors point to code.ao mirrors. Some tarballs now point to code.ao git mirrors with matching git hashes.

@alexei I did two builds on stretch using the git-mirrors.patch and it works fine. This patch just re-points the git repos at our servers, not all files. I think it can be applied to master OK.