Thanks for these patches, we'll take a look into it. One of our main devs runs Gentoo too.

@logan Then why is the title "printer resets while running gcode" ? A "Control Box Assembly Test Stand" isn't a printer.

@logan Are you seeing this on a printer or a test fixture?

@DaniAO I discussed it further with @matth and I think in this case it wasn't a false positive. When the sensor was disabled, it jammed not long after, so I don't think it was a sensor issue.

That said, we should also set up a "git clone" copy of this repo on devel.ao still. But hitting the git repo via the browser is even better to share as you'll always have the latest/greatest file.

@adam I understand not wanting or being able to do these as email attachments. I get that they may not have any idea what "git" is either. But you can give them full URLs to the (live) documents in the git archive and they can download it directly. For example, this is the top of the Brizo file tree:

Actually, @adam why do they need it on devel though? They could just pull from the tree of the git archive.

This should maybe be for Alexei? Or Kaleb?

@alexei Why not close this ticket though? The problem in this T5686 ticket is that Marlin restarts when taking too long in Quiver, but that is no longer an issue, it correctly says "probing failed". If we want to track whatever is going on in upstream Marlin's #11715, isn't that a separate issue?

If it is generating false positives with TPUs is it possible to disable it in the Cura profile? If not, we should document this for users that TPUs should have runout disabled.

@pfenrir Great, thank you. Development versions will probably land around here when ready.

Do we know the commit that fixed this?

P.84 Mentions Hexagon hotend, old.

Should have section on troubleshooting filament runout. Should mention can be disabled by setting it to "0".

P.63 "Printing With the Graphical LCD Controller" has TAZ 6 LCD.

Also some quotes that need to be changed to ` in "Backlash Fading Distance" section ”999999”.

Table on page 33 runs off edge of page.

P.21 "Per Model Settings" has some backwards quotes. In LaTeX initial quotes have to be a backtick (or two):

`

Strike "We usually use 6kg - 10kg of filament when developing these profile settings." It isn't relevant to the manual (but a nice anecdote). Not sure how accurate that is nowadays either. @matth and I alone have gone thru that much....

On p.12 we list Mattercontrol for alternate software. Is this free software? Is it still maintained?

Do we have all the regulatory statements included? I see FCC, Canada, and Australia on page vii-viii. Are there others? What about UL?

For me, the table of contents isn't being generated. I've done multiple passes, as LaTeX requires. I'm just getting a page headed "Contents" with nothing below it.

Versioning number on copyright page reads: "6.0-20190430". The "6.0" is from the TAZ 6. Prehaps it should be like "Pro-20190430".

MAXTEMP
The thermistor reading has gone above the maximum temperature set in
the firmware (300°C for the TAZ and Mini and most tool heads).

5.2 Changing nozzles

4.9 Bed Leveling Washers

Section doesn't mention Z belt.

4.3 Z-Axis Lead Screws
If Z-axis movement isn’t smooth you may want to wipe down the threaded
rods with a lithium-based grease

@karrad I'm seeing this in 3.6.7. See attached screenshot.

@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.