- User Since
- Feb 4 2017, 5:27 PM (106 w, 1 d)
Tue, Feb 12
I have shortened the jig by 2mm, printed and tested it. There are 2 on the printer cart at my desk, they are green. My wipe sequence is now pretty well centered.
@draubach will be keeping an eye out for issues with the ES9380, none reported lately while cutting 16 AWG wire.
@karrad Nothing other than normal slicing procedure for a dual print using any profile/settings, if he's using quiver it is every print where both nozzles are used, with no exceptions.
Mon, Feb 11
Here's a log from today, more occurrences
I'll go ahead and rebuild and clear cache
@alexei good to know about auto FW flashing, thank you for relaying that information. If we're testing something, that is good information to relay ahead of time.
Also good to know that now we shouldn't press the erase button vs before when it was required, we were not informed of this.
@alexei well if we didn't, it didn't work, so....
I attempted to flash with the same steps listed above except replacing step 5 with "automatically upgrade firmware"
This resulted in 2 fails, unknown connection error reported both times.
I then attempted to flash by specifying custom FW similar to above, but after selecting the appropriate FW file, CuraLE immediately closed (crashed).
See above commit or T5492 branch to review
@kent I have this fixture designed and ready to be pushed for review. Do you want it on taz-olive master or on a branch?
@tutley You mean shorter, right? I will place the nozzle at the start of the wipe sequence, bump it over until it is centered, adjust the jig by that amount and try it out.
@tutley From my perspective that is the more efficient solution because changing the model for the jig is far less time consuming than modifying FW and start gcode. I'd be happy to implement this change if that is the decided route. Do you have a recommendation for a new measurement? I think it would be about the average difference between X-min positions of machines with alpha vs beta X bumps stops but I'm not sure how much that is.
@tutley Really I am trying to figure out if I need to change the Y-Axis alignment jigs, or if we need to reset @marcio and @karrad machines with the jigs (again), install the new bump stop and fix all of the FW/Start gcode.
@Steven please advise
Fri, Feb 8
@tutley So in theory, if I had the alpha x bump stop I'd be wiping center?
After setting it back with the jig it probes but is too far to the left in the wiper pad. So we should be seeing this on all of the alphas, no?
Here are some photos of those cubes. I know this would require further testing for profile implementation. The best answer may not be 100% on with no smoothing but maybe a compromise. I'm testing having it on just for the calibration prints, to see if I can get the 10mm cylinder more similar to the measurements we get for Mini 2.
@tutley Confirmed, it is and has been fully seated. Measures 40mm, I get 39.5 from right edge to X motor printed part mating surface when installed measuring with calipers.
I have 2 cubes in hand, 1 with backlash compensation off (default), 1 with backlash compensation on. Other than the circle being circular and the dimensions more accurate, I cannot tell the difference between the 2. Having X/Y backlash compensation for only the first few layers makes it useless other than ensuring your part will have an elephants foot effect.
Updated local build
Flashed quiver to 22.214.171.124, restored to factory defaults
cleaned nozzles and performed auto calibration
sliced a fresh cube gcode with polylite PLA high speed defaults
@karrad I will do that too
Since someone will suggest it anyway, I'll go ahead and clear cache, update my local build, flash to the latest quiver fw, redo auto calibration and retry.
@Steven I don't know what you mean, we were not provided with set drag tolerances as far as I am aware, nor has testing been requested to determine drag tolerances for Quiver AFAIK.
@marcio Sounds like we need X/Y backlash compensation through the whole print in order to get dimensionally accurate parts?
The command entered by CuraLE is M425 F1 at print start and the value for F decreases as it moves up in layers.
will that activate backlash compensation for X/Y? I thought that was for Z backlash only?
So after talking with @marcio and @tutley, the backlash compensation is off by default. So auto calibration measures it but will do nothing with it by default. Why is that? Shouldn't it be turned on by default?
After reinstalling the standard dual extruder I noticed that E2 is missing in the same manner; not even inside the wiper pad. E1 hits on the left of the pad, rubbing on the mount also.
I removed and reinstalled my Y axis to verify no measurements have changed, I have made no modifications to start gcode. I am running m.80.
I am missing the right front probe point, the nozzle is hardly aligned with the washer and the blower shroud hits the wiper pad mount.
@karrad I have a 20/10 cube-hole print from a TAZ6 with an AeroV1, but this TAZ6 has other work to do so I can't keep it tied up on this.
polylite PLA High Speed defaults, printer is running m.126.96.36.199
X outer: 20.24mm
Y outer: 20.15mm
X inner: 9.75mm
Y inner: 9.79mm
Widened the holes, got one printed in PLA and tested, I am happier with the fit now.
Thu, Feb 7
Getting a closer look at this today after printing one in PLA, I noticed some damage to the Y Corner printed parts from forcing them into the jig. I think it will be best to open those sections up a bit.
I will get the fixture modeled and assembled in FreeCAD
I've put in a request with @tomc to keep an eye out for the 9300 when he is in the storage containers, when he locates it, I'll pull it into MER to calibrate and program the needed lengths.
@bowman We are ordering the same exact table top that we did for quiver, correct? Just want to be sure before I begin designing this assembly
@kent all of the requested jigs are complete and residing in this T4716 branch. There may be more insert jigs requested later but as this branch is already so far from master this merge could be tricky and I don't want it to get worse. I am working on printing production quantities of all quiver jigs for deployment.
I also found that the gauge settings for the solid core programs were set incorrectly, they were set for 24, 10, or 18 AWG vs the 20 AWG actual. I'm not sure how this could accelerate blade wear but seemed worth considering so I went through and corrected them all.
I talked with @draubach and @guadalupe about working closely with who ever will be processing wire next, likely Monday. I'd like to try a few of the manuals suggestions for improving strip quality/repeatability. I'd like to take a closer look at, incise diameters used, pull off speed and acceleration, way-back, and check blade calibration.
My hope is that we can compensate for the blade wear in order to use these blades longer. However, I still think it is worth considering bringing the ES9300 back out from storage to be used only for cutting solid core wire to length. The reason for this is we still have several brand new sets of blades for it that are cheaper than those used for the 9380 and already paid for, so it could be used while saving the 9380's blades and retaining that accuracy.
@guadalupe was thinking the bench nearest the shipping door in Pilot could accommodate that unit without hindering work space too much, however she did voice concerns regarding having assemblers lift the machine out from under the bench.
Wed, Feb 6
@alexei What does that mean?
At least now I know it is a bug and nothing that I'm doing.
Again today, fresh build of 3.6.4 generated yesterday running from a freshly cleared cache
@marcio What steps are required to turn off backlash compensation? Do I need to comment something out of the start gcode or just zero out all of the backlash values or adjust a slicer setting or all 3?
Tue, Feb 5
I will try the above suggested tests first thing in the morning
A 20mm cube sliced in slic3r is the same FWIW, leads me to the assumption that it isn't slice settings either though they could be used to correct it in theory
I haven't tried yet. I'll try a 40mm cube first and see
To get the initial error just loading the wiggletest.stl from above and slicing it with any material/profile on quiver
No sir, not able to reproduce on 3.6.4.
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.
Agreed, nothing like the original report.
@jebba I didn't have "Show Travels" checked in the original report either. Which made it even more odd.
I think those are in the gcode and not displayed by error vs the original report had weird lines displayed without any corresponding moves present in the gcode
In this screenshot you can see a few odd travel lines but nothing like above
I cannot seem recreate this on fresh build of 3.6.4 for quiver or any other machine/tool head configurations I tried.
I set up a print with PLA on nozzle 1 and "No material" on nozzle 2. All of the no material settings I have are default ABS temps etc.....
Testing on 188.8.131.52
All adjustments made between prints to nozzle offset only.
Increasing the positive value of nozzle z offset pushed the 2nd nozzle closer and closer to the bed
@marcio Ah, when i tried flashing with the script pushed to the repo it wasn't working, it said "bossac: no such file or directory" or something similar
Mon, Feb 4
@oliver This looks good, torque specs in both places.
I'm working on calibration now
I just noticed that the last vernier gcode I pushed didn't have the 2 squares set up right; selection was wrong when exported.
I'm working on drafting instructions for calibration OHAI now; will get a new one pushed once verified.
Happened again today, have 3.6.3 build, no other versions opened since last rebuild and cache clear
Fri, Feb 1
@oliver I personally disagree on readability and would prefer keep consistent throughout OHAIs by keeping them normal in BOMs. Wiki has been updated regarding bolding part numbers in brackets for text bodies.
Implemented step 19 here: https://ohai.lulzbot.com/project/dual-extruder-assembly/quiver/
Oh and added the testing process to the end, step 24
Fixed step 10
All part numbers are bold in brackets excluding the BOM on step 1
Fixed all occurrences of duel
Fixed all steps to break up text walls and also bolded torque spec call outs and special notes.
Also removed some unnecessary sentences and corrected wording here and there.
Thu, Jan 31
Also the z backlash is double on the 2nd nozzle:
Dont list the parts of sub-assemblies in the BOM on step one, those assemblies will be part of "General Sub-assemblies"
@oliver This is missed in X-End left, I see X end right is incomplete.
There isn't any mention of even installing the z motor pulleys in X-End Left
Be sure to mention the torque spec also as @kent recently found tooling for torquing pulley set screws
Same for the X motor pulley
Once all of the above corrections are implemented into OCA, this ticket can be closed. An OCA export will replace the MBOM in the repo.
@marcio Agreed. I am not sure how far off that functionality is.
@karrad Is there a way to replace the shared-j link with a link to devel.lulzbot.com?
This was discussed with @bowman
We are moving forward through beta with the current configuration, if an imbalance arises it can be corrected at that point. AS-PR0136/130 are being left alone for the time being.
Wed, Jan 30
@kent there's what I've got for the box, there isn't any source there for the internal board itself