Page MenuHomeAleph Objects Inc

Back to having goobers on prints
Closed, ResolvedPublic

Description

We're back to getting large goobers in our prints left from E2. Its seems to be in the same spot or near it everytime. We're seeing this on different printers and it seems to have started yesterday. These machines have .116 firmware if anyone is wondering. Nothing has changed with the .gcode. Any thoughts?! Its slowing us down even more having to reprint because of this.


Event Timeline

robert created this task.May 8 2019, 7:09 AM
robert created this object with edit policy "LulzBot Hardware Products (Project)".
robert updated the task description. (Show Details)
robert added subscribers: DaniAO, karrad, bowman, wolffchadd.
Steven added a comment.May 8 2019, 7:25 AM

@robert can you please confirm the full name of the gcode file you used to print this?

DaniAO added a comment.May 8 2019, 7:32 AM

Confirmed with @robert that they are using vernier_V1.0_PLA.gcode

Requested that they take one printer that is on .116 that was showing and flash back to .114

robert added a comment.May 8 2019, 7:33 AM

vernier_v1.0_PLA.gcode
So one of the machines that doing it consistently is still on .114.

robert added a comment.May 8 2019, 7:33 AM

Paulette has 2 machines that are doing it and ones on .114 and ones .116

tutley added a comment.May 8 2019, 7:36 AM

@robert @paulette is the idler tension set high enough? with the feed tube actually attaching to the idler there might be an issue when the tool head tries to retract, and the filament is actually slipping on the hob

robert added a comment.May 8 2019, 7:39 AM

@tutley Theyre set to halfway.

tutley added a comment.May 8 2019, 7:41 AM

ok hmm. does the drag of the filament through the filament sensor and feed tube feel any worse than a machine that is not exhibiting this problem?

Steven added a comment.May 8 2019, 7:54 AM

The only change between Marlin .110 and .116 are LCD changes so I do not think that is the issue. The timing of the firmware release and this issue appears to be coincidental.

aleph@XXXXXXX:~/Projects/marlin$ git diff v2.0.0.110 v2.0.0.116
diff --git a/Marlin/Conditionals_LulzBot.h b/Marlin/Conditionals_LulzBot.h
index 7d5db866f..1c5b51ac5 100644
--- a/Marlin/Conditionals_LulzBot.h
+++ b/Marlin/Conditionals_LulzBot.h
@@ -74,7 +74,7 @@
  *
  */
 
-#define LULZBOT_FW_VERSION ".110" // Change this with each update
+#define LULZBOT_FW_VERSION ".116" // Change this with each update
 
 #if ( \
     !defined(LULZBOT_Gladiola_Mini) && \
diff --git a/Marlin/src/lcd/extensible_ui/lib/ftdi_eve_lib/basic/resolutions.h b/Marlin/src/lcd/extensible_ui/lib/ftdi_eve_lib/basic/resolutions.h
index 6ffa9fef2..d25af5831 100644
--- a/Marlin/src/lcd/extensible_ui/lib/ftdi_eve_lib/basic/resolutions.h
+++ b/Marlin/src/lcd/extensible_ui/lib/ftdi_eve_lib/basic/resolutions.h
@@ -22,6 +22,30 @@
 
 #pragma once
 
+/***
+ * The FT8xx has odd registers that don't correspond to timing values in
+ * display datasheets. This macro computes the register values using the
+ * formulas given in the document:
+ *
+ *     Bridgetek Application Note
+ *     AN_336 FT8xx
+ *     Selecting an LCD Display
+ *     Version 2.1
+ *     Issue Date: 2017-11-14
+ *
+ */
+#define COMPUTE_REGS_FROM_DATASHEET \
+    constexpr uint16_t Hoffset              = thfp + thb - 1; \
+    constexpr uint16_t Hcycle               = th; \
+    constexpr uint16_t Hsync0               = thfp - 1 ; \
+    constexpr uint16_t Hsync1               = thfp + thpw - 1; \
+    constexpr uint16_t Voffset              = tvfp + tvb - 1; \
+    constexpr uint16_t Vcycle               = tv; \
+    constexpr uint16_t Vsync0               = tvfp - 1; \
+    constexpr uint16_t Vsync1               = tvfp + tvpw - 1; \
+    static_assert(thfp + thb + Hsize == th, "Mismatch in display th"); \
+    static_assert(tvfp + tvb + Vsize == tv, "Mismatch in display tv");
+
 #if defined(LCD_320x240)
   namespace FTDI {
     constexpr uint8_t Pclk                 =    8;
@@ -70,18 +94,22 @@
 
 #elif defined(LCD_800x480)
   namespace FTDI {
-    constexpr uint8_t  Pclk                 =    4;
+    constexpr uint8_t  Pclk                 =    3;
     constexpr uint8_t  Pclkpol              =    1;
     constexpr uint16_t Hsize                =  800;
     constexpr uint16_t Vsize                =  480;
-    constexpr uint16_t Vsync0               =    0;
-    constexpr uint16_t Vsync1               =    2;
-    constexpr uint16_t Voffset              =   13;
-    constexpr uint16_t Vcycle               =  525;
-    constexpr uint16_t Hsync0               =    0;
-    constexpr uint16_t Hsync1               =   20;
-    constexpr uint16_t Hoffset              =   64;
-    constexpr uint16_t Hcycle               =  952;
+
+    constexpr uint16_t th                   = 1056; // One horizontal line
+    constexpr uint16_t thfp                 =  210; // HS Front porch
+    constexpr uint16_t thb                  =   46; // HS Back porch (blanking)
+    constexpr uint16_t thpw                 =   23; // HS pulse width
+
+    constexpr uint16_t tv                   =  525; // Vertical period time
+    constexpr uint16_t tvfp                 =   22; // VS Front porch
+    constexpr uint16_t tvb                  =   23; // VS Back porch (blanking)
+    constexpr uint16_t tvpw                 =   10; // VS pulse width
+
+    COMPUTE_REGS_FROM_DATASHEET
 
     constexpr uint32_t default_transform_a  =  0x0000D8B9;
     constexpr uint32_t default_transform_b  =  0x00000124;
tutley added a subscriber: anolen.May 8 2019, 8:08 AM

tagging @anolen
@robert @paulette have you confirmed cooling fans, thermistors, etc function properly on the toolhead? is this somehow related to environment (machines exhibiting this when in a certain location)? have you tried using a different reel of filament?

The drag seems normal, compared to others.

I watched one and the nozzle had some ooze hanging off the tip before it switched nozzles. It didn't really seem to get as long as the ones that have the goober, and it didn't leave one this time. No changes from the print before. We have noticed ever since we switched to the E3D nozzles there has been more ooze, not sure if it's related.

robert added a comment.May 8 2019, 8:14 AM

@tutley Cooling fans seem to be working fine, temps are reading normal, heatsink fans are working. Machines are on both sides of the calibration area and each side uses their own filament from different reels most of the time.

tutley added a comment.May 8 2019, 8:20 AM

@paulette the ooze you have noticed since the switch to E3D is likely because we are needing to print at slightly higher temps due to the hardened steel nozzles. this should be fixable with retraction distance/speed settings

marcio added a comment.May 8 2019, 8:36 AM

The only change between Marlin .110 and .116 are LCD changes so I do not think that is the issue. The timing of the firmware release and this issue appears to be coincidental.

I concur. The LCD timing parameters don't affect the CPU at all. They are simply uploaded to the graphics chip at startup and have no effect on the CPU (which handles the print) from that point on.

logan removed a subscriber: logan.May 8 2019, 8:37 AM
kent reopened this task as Open.May 14 2019, 10:55 AM

On second thought, this is a different issue than the calibration print or it's workmanship standard.

DaniAO added subscribers: pfenrir, gregh.EditedMay 22 2019, 7:52 AM

@robert @paulette @gregh since the updated print, are you seeing this still?

No more goobers. Sometimes it strings the ooze from the nozzle across the print, but its far more manageable than it was before and if it does ooze at least its not 40 mins for a reprint.

DaniAO closed this task as Resolved.May 22 2019, 8:21 AM
DaniAO claimed this task.

Okay so going to close this one out and we can always reopen again if it's becomes a problem.

Thanks!