@karrad The default to 0.1mm is that something new or a separate issue?

@karrad It looks like you downloaded the thumbnail, not the full PNG. It should be just under 800x600 pixels.

@victor_larchenko @alexei Is there a commit for this? This bug is still in 3.6.6. We need to get a fix pushed, thanks.

@karrad See attached files for 2019 date.

Screenshot shows bits per second (baud) at 128000, should be 250000 I think.

@tutley Ya, it's going to Aleph Rockies. He was able to have it fail with 3kg black PLA and 1kg green PLA.

@tutley when @matth brings in the printer, set the filament spool holders to the "official" position. The top spool was used when we saw some issues with doing 2x 3kg reels right next to each other. But even moving one above we're still seeing issues with the one large reel, so moving up top didn't fully solve any issues.

@anolen We're trying some 1kg lulzbot green PLA with the polydissolve to see if the weight of the reel or color is somehow related. Also, @matth is using your Polydissolve profile from the spreadsheet. It looks like it is printing ok. We are adding "brim" when we enable support too.

@anolen The filament failing for @matth is 3kg Black Polymaker PLA mounted on the side of the printer. The 1kg Polydissolve mounted on top is printing fine.

FWIW, last time we looked at this, we determined it wasn't a bug, but the renders were correct.

I loaded X_skirt.stl into official build of 3.6.5 and it says it is two layers at 0.25mm layer height. It looks as it should to me when viewing each layer.

A ~20 hour dual color vase just finished, similar to the above, but larger. The walls of the vase are about 3mm and has a bit of infill, so thicker walls than the above ones. It turned out really well, so I think the key issue is if the part has no infill there can be gaps. This type of print may need a different profile altogether though, or some notes in the docs. It likely won't be a very common print type.

Note, for the profile, it was manually entered in from a spreadsheet provided by R&D.

I've seen these prints first hand. It seems there are really two issues. One is where color gets mixed a bit. We're seeing this more now than we had in previous prints. Perhaps Matt could upload other dice we have to compare.

It is probably due to 32 bit build, instead of 64 bit build (?).

Also, it appears the dpinst wasn't even ever used/called by Cura, even though it was installed.

It looks like this isn't needed. @alexei if dpinst has been 100% removed, please close this ticket.

Btw, I was just speculating it could be the weight of the reel, since it started happening when we put a new black 3kg Polymaker PLA reel on the machine. Could be 100x other things.

It may be, from T5768, that the only thing needed to be installed is a text file .inf and an (optional?) signed certificate from Ultimachine. The drivers used in Windows are the old skool modem drivers, which come with the OS. The text file .inf file identifies the device for the OS, and tells it to use the mdmcpq driver, which is part of the core Windows OS. So no external downloads or non-free binaries should be needed to enable this device. Using the Arduino drivers was just a long way to go about doing the same thing, effectively. But it isn't needed to be done that way, afaict.

It may be good to ping Ultimachine as well, to see what they know.

This is the driver in the Linux kernel:

From what I understand now, it looks like users can download the whole arduino package, just to get the drivers or they can get a copy from Ultimachine (either our servers or theirs). The Ultimachine file we distribute, doesn't actually contain any binaries or executables. It just has a config file and a certificate signed by Ultimachine using Thawte as a Certificate Authority (CA).

The only Windows versions that came up in the helpdesk tickets were Windows 7 and Windows 10. Is that all pretty much people run nowadays? No Vista, XP, NT, or whatever else? Did the other ones not come up because no one uses them, or they work by default?

Who is best to figure this out on Windows? ICS? @victor_larchenko ?

Going thru the helpdesk tickets, I see this:

I searched the helpdesk for this and got 2 hits, both in from 2017:

We should also drill down and figure out why this happens to some users and not others. I'd be surprised if it was identical for all versions of Windows. Can you see if in the TSR mail archive if in any of these tickets people mention their OS version?

If we get a call once a week about this, we should really improve the docs... It should be updated so it doesn't appear to be from the stone age. Also, it shouldn't have to be referenced at all, as this should appear in the main docs or somewhere.

@TyTh Do you know what version of windows they are running? Like is it everyone on version 8? Can this happen on all versions? In sum, why does this happen to some users, but not others?

Ticket about Arduino drivers and RYF: T5770.

See also: T5842

The other file included, which looks like a signature file to me, is referenced in the text file as:

The text file in the Ultimachine zip:

That OHAI documentation is so old it talks about the AO-101!

@eBeardslee Did you unclick it so it didn't download? I don't fully understand how drivers work in the windows world, and we're trying to figure this out for FSF RYF certification too.

Does TSR see this issue? @TyTh

Closing this, long since done.

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.