- User Since
- May 30 2017, 1:22 PM (107 w, 6 d)
Just to add, I have another machine that was red-tagged for this issue with mutliple tool-heads repeating the same issues. One solution can be to adjust the auto calibration E2 nozzle to probe farther to the left during its initial probe, since we consistently appear to be too fart to the right when encountering this problem.
Fri, Jun 21
Just to add my two cents here, I think it can be beneficial to operate some sort of contract manufacturing; however, I think we may be competing with ourselves at a key point in the companies growth. A customer may see more value in getting the printed part rather than investing the time and money into operating a PRO or purchasing a HS or HS+ tool-head, in order to print some more expensive and finicky materials. Additionally, we have the benefit of being predominately FDM machines which is generally a lower cost to operate compared to SLA and DLP, but once we start to price out the service for parts our 'cheap-to-operate' perk becomes less valued as customers on the fence will use the pricing here to gauge how expensive it will be to own a LulzBot.
Thu, Jun 20
This version is much easier to use with the thumbscrews.
Wed, Jun 19
That one seems to work, thanks!
In T7678 right? I pulled but it still had the artifact when I loaded it up in cura.
Sounds good, thanks!
@west The right side face is missing for v1.3.
Tue, Jun 18
The OHAI kit also tracks all edits to a project complete with a time stamp and user name, for what it is worth.
Confirmed the issue on L pod in cluster which appears to be the only remaining black gladiola machines left in the room. The artifact does not show on printers equipped with aero-struder hot-ends. Current recommendations would be to swap tool-heads to aeros. This will be easier for all slices as many have their cooling speeds set specifically to the blowers instead of the 20 mm fan.
Fri, Jun 14
I adjusted the wiping temperature for the production prints that are converted for workhorse. I must have forgotten to set it when first converting. Let me know if there is an improvement with probes after this.
Tue, Jun 11
@MichaelM I personally did not have any problems with the actuator cover. Was not aware we had two different BOM's for the same part with only the actuator cover removed. @DaniAO @tutley @west would there be any problems getting rid of one of these BOM's. Alternatively, if a step by step of preferred build method can be written up or a meeting can be scheduled to build them so I can write a step by step that will help save a lot of time and frustration on making OHAI content.
@logan @MichaelM I added the actuator cover to when we install the actuators since I figured it would aid in protecting the ribbon cables and helped the work flow, same with the idler clamps. Is it causing issues with assembly for these units?
https://ohai.lulzbot.com/project/dual-extruder-assembly/quiver/ step 8 has been updated to reflect the change requested here.
Mon, Jun 10
@marcio if you power cycle a gcode with different M425 values than the default, it keeps the values from the gcode instead of returning to system defaults. At least that was what we were getting from our tests.
Fri, Jun 7
Revamped the OHAI and included this step. Let me know if there is anything that needs more elaboration
Thu, Jun 6
@TyTh if it is possible, please record the calibration data from auto-calibration after installing the parts. This will help us determine if this will give a better tolerance for calibration. Thanks.
Just for clarification, PP-GP0326 should be the top cable bracket which looks like this:
Wed, Jun 5
@logan sweet, thanks. I agree, the part change with phrasing/photo update for the ohai will be helpful.
@tutley so this won't be an OHAI change, correct? Since we are changing the part so it can only be installed one way.
Closing this as resolved for the moment as clarifications on procedures have been implemented. Will re-open if this is found to be ineffective in the amount of machines that need re-tensioned on the x ends.
https://ohai.lulzbot.com/project/dual-extruder-assembly/quiver/ step 19 has a new picture at the front to help avoid improper assembly
https://ohai.lulzbot.com/project/thermal-insert-instructions/quiver/ step 24 has a little more clarity.
Tue, Jun 4
@karrad I believe there might be confusion. I did not make this ticket originally, that was authored by @samantha. On March 25th I attempted to re-create the issue which gave me a different error. I have not had the chance to re-attempt since then. Have you been able to re-create the issue?
@karrad I am aware that the image I shared is demonstrating an x axis shift. If you would like to look at the helpdesk ticket associated with RMA 13250 that might help bring things up to speed if there is issues with my credibility.
Mon, Jun 3
@DaniAO the reviewer was using 3.6.8 standard polylite PLA and getting both curling and this
@DaniAO This is standard polylite profile. 3.6.10
One thing we noticed is the fan doesn't turn on to max speed until about layer 10.
This is strange behavior as the layer height is set to 0.25 for standard, with a first layer height of 0.4 and regular fan speed to turn on at 0.4
Fri, May 31
@DaniAO sure thing.
Thu, May 30
I believe we just need to make a change order for this. The latest slice was pushed to the testing branch of the production print folders and was within acceptable fallout and cosmetic standards.
Tue, May 28
I took some screen shots of why I think this part will need a model change. Due to the original print orientation no longer available we are now printing on a chamfered edge. I tested some prints by removing this feature in blender and found a much higher success rate when printing. I believe this is due to the first layer being the same size as the rest of the part there is not as much influence from the second layer to lift away from the bed as it cools/shrinks.
I reduced the fan speed of these slices. This seemed to be the primary culprit for the failure.
@tutley I will see if I can add it to the queue for someone making the trip.
@tutley @west both @franklin and I have machines that exhibit the higher than normal backlash value even after broaching the axis. The value did drop initially: 56 down to 45. They appear to be plateauing at this value though. Would you like to go over these machines yourself?
May 24 2019
May 23 2019
May 22 2019
@Steven Occasionally we run into a machine or two that aren't correctly spaced in the Y axis which is typically a quick fix. We are probably fine to close this out.
I will make a change order as soon as I finish brushing up on the wiki. I know the slice is already done and in both the master repository and production print folders, so it should be a fairly quick confirmation one.
Production print folders have been updated to have the correct model. I believe we are treating this as a roll in change since it was just missed from beta to production tag.
Test prints have been successful and verified to work.
May 21 2019
Slice change, the model is already in the master repository, so we are only missing production gcode for that stl.
@paulette The QA sheet for Finals has a step which might be too vague if we are seeing it slip through: The belts are aligned on the idler bearings and properly tensioned.
@paulette approximately how many machines are you seeing make their way to calibration with loose Z belts?
May 20 2019
@david.hall if the part is coming out dimensionally accurate in one axis but not the other then we have to evaluate which axis is failing based off of the orientation of the print. From your earlier comments, I am gathering that it is fitting fine from the top of the part to the bottom (Y axis) but not fitting in the left to right (X axis). Using some calipers, can we verify the distance across 10 prints worth of parts (30 individual pieces)? Worst case scenario we can use these data points to determine if machines in cluster are out of calibration.
T5889 was created for this reason. I have no idea why it isn't installed on current production machines as it is on the BOM. PP-GP0437 is the printed part used to help keep these harnesses in the correct position.
I renamed the problem gcode in the file tree, prefaced the file with DO_NOT_USE while we work on it.