Ok, we can close this when our shipping version has SSL 1.1.

Attached is build patchlet to have curabuild use Qt 5.12.5 and PyQT 5.12.3.

@karrad btw, I can verify this exact build failure on another Buster system.

I put these on download:

"macOS 10.10 no longer supported"

It looks like QT5.10 is first to use current SSL:

Here's where the updated QT file source can be pulled from:

@karrad There is a pyqt512 branch which may build better on your workstation.

https://www.riverbankcomputing.com/software/pyqt/download5

The issue here is that we are building with an old libssl 1.0.0. We are doing that because we are building an old PyQt 5.8.1. We should update the underlying libraries so we can use a current libssl. Apparently libssl is used by the octoprint plugin.

See also T9817

See also T1511

FWIW, network link is only for links to filament, if I'm not mistaken.

@karrad We just changed nozzle size. We did it in standard profile only.

These worked great, unmodified except changing nozzle size.

Perhaps when new build system gets set up we can add Ubuntu and AppImage targets.

Am I following it correctly that all MacOS 10.15 end-user software will now require to be notarized? There is no way around this? Won't that break huge amounts of legacy Mac software or am I missing something?

This is still true in Debian Buster's FreeCAD version 0.18~pre1+dfsg1-5.

@bvivers It sounds like you have a different issue. I would suggest contacting support@lulzbot.com or opening a new ticket here with details.

@bvivers I think this issue just applies to the 3.6.x Cura, not the older one with the different interface. If you are having problems with BOTH, that may be a separate issue, perhaps with hardware. @bvivers Can you let us know specifically the versions you tested that aren't working? @Yahuba Do we know the range of versions this applies to?

Be sure not to post customers' pictures, unless we have their permission or it is under a free license. Just use internal examples.

Most probably won't, but to those that do, how does it manifest?

How will end users see this issue?

If you are unable to have these features with USB, then USB has to go.

Fix was in 7901c4a51f12.

The cause of this was found. It was a bug in Marlin development version for TAZ Pro 2.0.0.136 to 2.0.0.142. None of these versions were shipped for the Pro in Cura and no customers downloaded that firmware.

Isn't it just because we have the heatbed at 70C which is really high for PLA?

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?