User Details
- User Since
- Jun 9 2015, 11:00 AM (235 w, 2 d)
Fri, Nov 15
Oct 2 2019
Ok, we can close this when our shipping version has SSL 1.1.
Sep 30 2019
Sep 26 2019
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.
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.
Sep 23 2019
See also T9817
See also T1511
FWIW, network link is only for links to filament, if I'm not mistaken.
Sep 13 2019
Sep 12 2019
@karrad We just changed nozzle size. We did it in standard profile only.
Sep 10 2019
These worked great, unmodified except changing nozzle size.
Sep 6 2019
Perhaps when new build system gets set up we can add Ubuntu and AppImage targets.
Aug 29 2019
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?
Aug 5 2019
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?
Jul 25 2019
Jul 23 2019
Be sure not to post customers' pictures, unless we have their permission or it is under a free license. Just use internal examples.
Jul 17 2019
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.
Jul 11 2019
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.
Jul 8 2019
Isn't it just because we have the heatbed at 70C which is really high for PLA?
Jun 21 2019
Thanks for these patches, we'll take a look into it. One of our main devs runs Gentoo too.
Jun 14 2019
@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?
May 29 2019
May 28 2019
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?
May 22 2019
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.
May 10 2019
@pfenrir Great, thank you. Development versions will probably land around here when ready.
May 1 2019
Do we know the commit that fixed this?
Apr 30 2019
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.
Apr 23 2019
@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.
Apr 22 2019
Screenshot shows bits per second (baud) at 128000, should be 250000 I think.
Apr 16 2019
@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.
Apr 9 2019
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.
Apr 4 2019
Mar 30 2019
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.
Mar 25 2019
Mar 22 2019
It is probably due to 32 bit build, instead of 64 bit build (?).
Mar 15 2019
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.
Mar 6 2019
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.
Feb 26 2019
Feb 25 2019
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: