- User Since
- Apr 3 2017, 8:53 AM (116 w, 9 h)
@anolen: Can you close this as resolved then?
Fri, Jun 21
@adam: Check the whether the coordinate system is good. Take the toolhead to X293 Y-16 and lower it to the washer. It should be *exactly* on the center of the right front washer. If it does not fall in the exact center, then the coordinate system is off (either due to a mechanical problem, or something else)
Thu, Jun 20
Wed, Jun 19
My thought process behind the not even allowing calibration to run if the filament sensors detect filament
Well, we are currently limited to three lines of text. That's quite a lot more... I can try fudging it to support more lines, but I don't most people will even read that, to be honest. TL;DR.
There is a dialog box that shows up before calibration starts. That text can be customized since it's not standard Marlin.
Tue, Jun 18
For the record too, I removed/reattached the blower shroud for testing so I could see where the nozzle was landing. The most important spec is that the nozzle at X-14 and Y-14 needs to fall *exactly* on the center of the front left washer. This is the common reference point I have been using for all TAZ beds.
I looked at @samantha's machine and several adjustments needed to be made:
The default offset in the FW is 43. If those numbers are typical, it would seem that the default would be a bit short. Maybe bump it up to 45?
Mon, Jun 17
Okay. I guess I'll start by doing measurements on those machines then. AFAIK, the original value in the FW was from the Alphas. It's entirely possible that choice is no longer appropriate for production machines.
@karrad: Well, if it only happens on a machine, then it is that machine which is borked, not the FW. If we want to make another machine a reference, bring it to me and I will do the proper measurements. I won't just fudge it this way or that. There's a specific measurement I am looking for and I need a printer to make it.
@karrad: When you do the calibration, the printer relies on the nozzle spacing default in the FW. If this is significantly different than the actual spacing in a machine, then you may get problems with the auto-calibration. It may be off on either Y or X, as appears to be happening. It would be useful to know the mean distance between nozzles as they are coming out of production, so we can adjust the default value in the FW. We could also increase the margin of error (i.e. how far it starts from the edge of the cube), but this will slow down the calibration process.
Fri, Jun 14
If you would like us to do further troubleshooting, the bring the whole thing over to R&D. Otherwise, if you are satisfied with the workaround you made, go with that.
Okay, I re-ran the test with the nozzles heated and made sure the extrusion was happening. It was. It made it through the entire gcode you posted above with no problems.
Ahhh. Interesting. Then it must have skipped the test. Let me try that again.
Well, at least we ruled off that possibility. Have you tried that GCODE on any other RedGum printers? I would like to see if you can reproduce my findings, where it runs fine on an actual RedGum.
FWIW, .116 is very old. There have been several tickets closed since that release, T7168, T7178, T7329, T7535, T7840, T7789. I think we are overdue for a new RC. It could become the RC for Redgum and Quiver.
BTW, the non-conforming printer now has .133. If this goes back, it either needs to be restored to the older FW, or it will need to sit around until the new release candidate is approved.
@DaniAO: This FW has received virtually no testing. I think it needs to become a release candidate and we need to test it for a few weeks.
I'll do whatever is decided upon. I was just stating the trade-offs.
Thu, Jun 13
Good news. Turning down the brightness prior to initiating the flash does hide the flickering.
From a user's perspective, it would make sense to have a fast loading speed, but a limited extrusion speed to not strip out the filament, but the printer has no way to know when the filament has "bottomed out" inside the hotend. So the speeds need to be the lowest of the two, which is the extrusion speed. That becomes the limiting factor.
Well, that wasn't the issue, because it works on a regular RedGum. The issue is probably electrical interference, but by changing the distance and feedrate you probably changed the characteristic of the noise enough to avoid the problem. Still, this workaround will likely result in more chassis failing to pass inspection.
Tested this on an actual Redgum and no issues found. Rebooting printers are usually caused by lack of shielding or grounding, I recommend adding grounds to all the motors in the test rig to minimize the possibility of problems.
Because the wipe sequence issued by Cura is indistinguishable from regular GCODE, Marlin has no understanding of whether the printer is wiping, or whether the filament is retracted or not. We could add a fixed extrusion at print cancellation, but 99% of the times this will be during a print, so the user will end up having to clean up a huge glob of over extruded filament. Either way, the user needs to inspect the printer after a print cancel or failure and ready the printer for a restart. This will consist of either cleaning up over-extrusion, or pushing the filament back in. I don't think there is any way around this unless there is a sensor in the toolhead that can tell when the filament is fully inserted vs. retracted.
Wed, Jun 12
Also, did you do a factory reset, just in case?
That's strange. I just flashed .128 to my machine and I am able to start a print from the USB just fine. There doesn't seem to be any changes between .127 and .128 that I would expect to impact USB.
@alexei: The display board is essentially it's own microcontroller with a separate framebuffer. If "flashing" the AVR involves a soft-reset, that would leave the I/O lines active, then supposedly the display controller could continue showing the previous framebuffer. The problem occurs if the AVR resets and tri-states the I/O pins. This will cause the reset line to the microcontroller to either float, or get pulled down. This will stop the display controller, leaving the LCD now becomes susceptible to noise (which is probably what causes the "fade" effect).
Tell people their printer is flashing. Literally. It's a feature.
One quick test. Turn the brightness as low as it goes in the LCD panel prior to flashing FW. Then try flashing. If the brightness remains low and obscures the display flickering, we could possibly work something in to have Cura turn the brightness way down before flashing FW. But if the brightness turns up on its own, then we are SOL.
It may not be a pass according to our standards, but it does not mean the LCD is defective, the LCD is simply being put into a state it was not designed to operate under and it may behave differently depending on manufacturing variances. If we had identified this issue earlier in Quiver development, we might have been able to come up with a hardware workaround. Right now, our choices are limited to finding a software only fix. If we know for sure that flashing from the terminal behaves differently than flashing from Cura, then that is a lead to follow, but only if it consistently works better in one vs the other.
If flashing from the terminal and flashing from Cura behaves differently, then perhaps this is something @alexei could comment on.
This is actually a tricky problem to solve. When the printer is being flashed, there is no software running on it, so there is nothing to send valid signals to the screen. Different screens seem to behave differently in that situation. A lot of displays stay black, but some seem to flash in weird ways.
Tue, Jun 11
@logan: It looks like the workaround I put in for M226 was only enabled for Quiver. I have enabled it for all printers in .131
Mon, Jun 10
Could you look in the console and see if it says anything about "Saving to EEPROM?"
I do not believe "M425" saves the values. However, if you click on the "Measure Automatically" button on the LCD, it will save the values. This is because it runs the following script:
Thu, Jun 6
Mon, Jun 3
@Orias: The problem currently is that only the first line can be specific to a type of error, and it can only be 16 characters.
I don't know whether PRINTER HALTED really adds any info. Maybe:
Fri, May 31
If so, then "Probing failed during auto-leveling" (35 char) for TAZ Pro will help the user.
I feel that was a convoluted answer. Here are the constraints, as bullets:
Here is the standard dialog box for machine halted errors:
Thu, May 30
So they would be asked to ensure the nozzles are clean when the heaters fail to heat or when there is an USB read error? There is only one dialog box for all the errors.
Wed, May 29
It works on my machine, but I don't know if anyone else has tested it. @matth?
I don't know.