Fork Sand, Inc. is a Free Software, Open Source Hardware company developing secure computing devices that guard users' privacy.
- User Since
- Mar 19 2018, 2:20 PM (86 w, 1 d)
Oct 11 2019
I downgraded back to 149 and it works as intended. Has the target temps and is heating like normal.
I tried 173 and got the same result.
About screen times out back to the main screen, perfect!
I had made a similar ticket for kangaroo paw T10241 and it was added in shortly after.
Sep 30 2019
Looks like this was added in 169, thanks!
Sep 27 2019
Confirmed fixed in 167, thanks!
Sep 26 2019
Sep 24 2019
This seems to be fixed in 18.104.22.168.
This seems to be fixed in v22.214.171.124
Sep 13 2019
Sep 10 2019
Aug 30 2019
Aug 27 2019
I haven't been able to reproduce this in .149, so may be already resolved.
Aug 12 2019
So far, yes
@west There was some slack, and all I did was move it over a bit. There's nothing to keep it from slacking back though
Aug 7 2019
It's happened once before, probably from moving the printer. However, this occurred during printing during the past 24 hours or so. I popped it back in and is currently printing fine.
Jul 25 2019
@karrad I did do that. With T0/E1 active, setting the esteps worked. Then I would do:
Jul 24 2019
Jul 18 2019
I repeated it several times July 17th, then of course it doesn't repeat when I brought it in today. While it was repeating for nozzle 1, it may have been occurring for nozzle 2 as well. In T8648, I mentioned how I was repeatedly getting "Extruder x Filament Error" messages prior to the heat runaway. At every error, I would confirm it wasn't stripping out and indeed extruding correctly, yet would still give the error when resumed. When I would disable the runout sensor and resume the print, it would complete the print without extruding from that nozzle for the rest of the print.
Jul 17 2019
I made it in freecad, with a height to make it need 2 layers. In cura, I load it in twice and have each nozzle print each one. Been using it since alpha to determine z-offset height.
Jul 15 2019
Updated to .144
Jul 11 2019
Jul 10 2019
As of fw 126.96.36.199, this appears to be fixed. Instead of restarting, it switches back to extruder 1 and returns to the home screen.
Jul 3 2019
Jun 17 2019
It has different nozzle and bed temp than the 910, but everything else is duplicated. The few prints I've done with it have gone really well.
Jun 14 2019
I'm just using the standard TAZ Pro profile. Let me know if you need anything else.
May 29 2019
Appears to be working as intended for me. Can close for now.
@tutley Yes. They looks like they're in the center. They were set by the factory and I haven't touched them since we got the machine.
May 28 2019
So I'm still getting runout errors. I'm now using a production model that Jeff picked up.
May 23 2019
May 15 2019
Is the "Reheat finished" dialog box confirmation necessary? I would prefer if it just immediately resumed printing.
May 9 2019
The idler tension would not be intentional. That would be my bad, probably from when I had to dismantle the tool head in order to remove filament that had broken off and couldn't be extruded out. That may explain my true positives with extruder 1, but obviously not the false positives with extruder 2.
May 8 2019
Both heating failures occured before returning to the print. The second one occurred while I was extruding after cutting the filament. It went like:
May 2 2019
I was looking at the manual from here, updated 4/23. (I don't have access to sharej.)
Apr 30 2019
Step 6.1 on page 33
Okay, I get what you're saying. In that case there just needs to be some documentation to notify the user why they can't have both nozzles print at different layer heights.
Apr 23 2019
I think I have different desired results then. I'd like each extruder to display their own separate layer height settings, not have both display an average.
I can't seem to replicate that 0.1mm default. What I did:
Apr 22 2019
After chopping off 200mm, I've had no issues ever since.
Apr 18 2019
So @anolen witnessed the issue and was able to identify the problem and apply a fix. She'll be able to describe it better than I can, but from what I understand my errors came from a faulty wire for nozzle 2 in the tool head. I will test to confirm the fix, and then move on to testing big reels.
Apr 16 2019
I will come down tomorrow. I replicated a false positive with the pictured setup, and now I've replaced the 3kg black PLA with a 1kg green PLA. I'd like to see if it will be replicated again. (I haven't shortened the tubes yet either.)
@anolen Yes, at 235. Sorry for the confusion but the false positives have been with the 3kg reel of black polymaker PLA.
@tutley I confirmed that the wheels in the sensor spin and the pin states change when I move the filament in the sensor. On the tool head the idlers are centered for both nozzles as well.
Printer: KT 7, beta
Filament: noz 1: polydissolve, clear
noz 2: polylite pla, black
Runout detection distance: 14mm
Profile: values for standard from http://devel.lulzbot.com/filament/Testing_Docs_Master/Quiver-Setting-Guide/
Apr 2 2019
This hasn't been an issue for a while, whether it's printing from cura or usb stick. Can close for now.
Mar 29 2019
Mar 25 2019
It seems to happen most often when the toolhead is on the right when it is z homed. If it were to home the x to the left before homing the z, I believe that would help prevent the issue. Perhaps not completely, but it would help
Mar 20 2019
I've been getting a lot of filament runout errors lately, and I know it's because of the filament reels. I have a different machine (a current beta) and am still running into this error. Each time it's because a reel is caught or conflicting with something; the filament is super taught and would be stripping in the tool head if I resumed it. Each time I fixed the error by unreeling some filament to create some slack.
I was thinking of a printed part that would attach to a top extrusion through which the tubes would be fed through. Similar to zip ties, just with a fixed location. I can try some ties for now.
Mar 19 2019
Cura version 3.6.5
Mar 8 2019
I've been having good, consistent results with them.
Mar 6 2019
Currently on .93
Feb 28 2019
Print didn't fail, just had other possibly unrelated issues. This is just something I noticed, and for every print I do I make sure I'm diligent enough to check each extruder setting.
Feb 27 2019
Maybe it's just personal preference, but when I load in filament, I prefer to use the "change filament" menu to preheat the nozzle and have it auto-extrude until I'm satisfied with the extrusion. It's also easier to preheat to the desired temperature with a single button press.
Feb 25 2019
I installed the corners and did a test print with them. Then I put in my older modified corners and did the same print.
With the new corners, I still see a noticeable difference in the bead height depending on where it's printed. In these pics, the inner skirt is with the older corners and the outer is with the newer corners.
Feb 22 2019
Also need to mention the redundancy of the belt tension checks. Page 1 has the tester measure then tensions, then for each axis the tension is checked again, then the second to last check is another check of all tensions.
Feb 21 2019
Firmware .91, Cura 3.6.4
Feb 20 2019
It is 0%, which I believe is set when it is factory reseted.
I've had this problem come back. I update to .91, so I factory reset and ran a few calibrations. Ran it over 10 times and have gotten results that are all over the place. Looking back on my notes, .88 produced good calibrations, so it's either the current firmware or my machine. I'm also still using the toolhead I installed on Feb 1st, which I believe was never used prior.
Feb 12 2019
I tested it three times, and that seems to fix the issue.
Oh good. I was waiting for my current print to finish before using that command. I've tested it with several difference gcodes and got similar bad results. I first noticed it after printing:
Feb 8 2019
First I ran a calibration and didn't change them at all before doing this test.
Feb 5 2019
@Steven Kent has it, I'm currently using the newer one that I installed last Friday.
Feb 4 2019
I should also note that the first calibration after a factory reset is always bad. I do a factory reset after each firmware update, and every time, the first calibration is always way off compared to the calibrations I do afterward.
Feb 1 2019
Well I removed the toolhead and put in a new one, and I've gotten far more consistent results. I'll be doing some more testing but so far my issues seem to be related to that particular toolhead.
Jan 31 2019
I can bring it back to mountain on Friday for the day if needed
I updated to .81 and ran those commands. My output:
I had my machine upgraded with the endstop switches. With .79 I ran several calibrations and got very consistent results.
Jan 29 2019
Seems fine to me. I powered off, moved the toolhead to different positions, then powered on. Each time the toolhead just moved up to the top most position.
Jan 22 2019
@marcio It was 72 -> 77, but it's probably the lack of z-endstop switches.
Jan 21 2019
For my machine, firmware 77 made it a lot worse. I've run the calibration more than 10 times in a row and have been getting very inconsistent results for the z offset. My min and max values so far have been -0.29 and 1.32, and even if I dismiss the extreme outliers I still have a very wide range of results, which then would require more testing to find the ideal z offset.
Jan 18 2019
Jan 15 2019
I ran the calibration test 20 times in a row and recorded my results.
I'd also like to add that Jeff and I have gotten very different results from running the calibration test multiple times. While the x and y offsets are fairly consistent, the z offset has a much bigger range. One calibration put the z offset at 0.24 and produced some poor prints, while another calibration put it at -0.01 and produced far better prints. Running the calibration multiple times in row, making sure the nozzles are clean each time, produces a wide range of z offset measurements.
Jan 14 2019
This occurs when plugged in via usb cable: