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 (60 w, 6 d)
Wed, May 15
Is the "Reheat finished" dialog box confirmation necessary? I would prefer if it just immediately resumed printing.
Thu, May 9
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.
Wed, May 8
Both heating failures occured before returning to the print. The second one occurred while I was extruding after cutting the filament. It went like:
Thu, May 2
I was looking at the manual from here, updated 4/23. (I don't have access to sharej.)
Tue, Apr 30
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.
Tue, Apr 23
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:
Mon, Apr 22
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:
Reopening because issue is still present when printing via usb cable with Cura.
Jan 11 2019
I talked about it in T5135, and was solved for me with firmware version .67.
Tried the steps to reproduce and my machine, Quiver 1, retained the backlash values after power cycling. I'm running .67
Jan 9 2019
This seems to have been resolved with the current firmware update 220.127.116.11. I'll measure it more, but in my last print both extruders purged about 170mm.
Jan 7 2019
I added the start and end gcode and still have the same issue. I timed the nozzle 1 purge to be about 12 seconds and the nozzle 2 purge to be about 6 seconds. While both nozzles did purge some filament, I'm still not sure why nozzle 2 always seems to purge for half the time/amount that nozzle 1 does.
Jan 4 2019
Firmware version Marlin 18.104.22.168. Using Cura version 3.6.2 and 3.6.1.
This seems to be fixed in the current builds.
Dec 21 2018
@west Adding that line made no difference, unfortunately. After it cools the bed to 45C, all the temps are set to 0 and the LCD says it's ready.
Dec 20 2018
Here's the last few lines of it:
Dec 19 2018
Mine (quiver 1) is doing this too, at the start of a print.
How about letting the user set the increments in the interface settings?
I would just like to be able to set the z-offset for the extruder 2 when not printing. I don't like the idea of being able to change that only in mid-print.
Dec 14 2018
I tried adding the T0 or T1 and then setting them, but the LCD only displays the setting I put in for T0:
Dec 5 2018
@MikeR and I weren't torquing the set screws when assembling. If a smaller torque driver is going to be used in production then there should be no issue, we only had a slight issue using our drivers, as they would get a little stuck after going all the way in.
Nov 30 2018
We measure them to be 3mm in diameter
Nov 29 2018
Nov 19 2018
Enclosed, glue stick onto the PEI, Aero v2.
The recent prints I did were on a Mini 1 Aerostruder; should be the latest firmware as I flashed it last week. In the past I've has the warping issue with Taz 6 Aero and Taz 6 Moarstruder as well.
My latest printing I turned off the cooling fan and increased the bed temp to 110C; so far haven't had any warping in any of my prints.
Nov 13 2018
Nov 5 2018
Let me know if any adjustments need to be made.
Oct 24 2018
Okay, I see what you added. I didn't think those holes were necessary as I didn't know how far the screws/inserts were.
Oct 23 2018
I reproduced the model within freecad and used the measurements from there to reproduce the essential measurements. Maybe I didn't add the correct chamfer?
Oct 17 2018
Oct 15 2018
What about the Macro and Moar tags? Shouldn't it be:
Oct 11 2018
Oct 10 2018
Oct 5 2018
I see they're updated, but can we add the toolhead size next to them? 0.8mm, 1.2mm, etc