- User Since
- Mar 29 2018, 11:19 AM (64 w, 6 d)
Yes, we write it down but I don't think we've seen the issue in a little while. That doesn't mean it won't happen again.
While @zachah was able to fix some this way, I have one right now that was adjusted this way and E2 still misses the top of the calibration cube, so there might be another underlying issue.
Mon, Jun 24
James is going to bring it shortly.
yes, and when you rack it the other way where the right side is higher, it will do it's little jig and level itself. The left side makes a seriously loud cracking noise, not normal at all. It also will not lower itself off the switch after it is done, like it will when completing auto-level normally.
Possibly, but we could not see anything getting in the way. It only does it when the x-axis is out of level and the left is higher than the right. In all other cases it homes and triggers properly.
Thu, Jun 20
Yes, it triggers the switch, but instead of softly bouncing up and down to level that side it makes a hard, loud clicking and then stops without coming back down off the switch button. We checked to see if the motor or motor mount was hitting the Z idler anywhere and it wasn't.
@west, yes, we loosened it down to 45N.
@kent I don't know as I don't know what is causing the issue. So far this is the first one we've seen on the line and wanted it documented since it was such a weird issue and a solution wasn't obvious or immediately found, and also to see if anyone else had suggestions to fix and possibly prevent it going forward.
@zachah and @MikeR came onto the line to help diagnose and these were the things we thought might be causing the issue based on observation and prior experience with a similar issue on the part of the Merpeople. Yes, there were other printers to be calibrated and we probably should not have spent so much time on the line, but as we already had it half apart we thought we'd try it real quick.
Tue, Jun 18
i have another one that is exhibiting this issue, I have red-tagged it and put it in the pile to go back to Rockies.
Mon, Jun 17
i don't think that what happened with the plastic is the same issue as the ones from this morning, as those were fixed right away without changing any plastic parts, while this one, the bright spot persisted until we found the plastic bloom.
This has happened several times on the production floor as well.
Wed, Jun 12
@DaniAO the flickering screen after flashing firmware with Cura is any machine we've tried so far. (at least 4)
When flashing through Cura, the screen does this weird fade out, where it looks like static on your TV and increases density over the whole screen. When flashing through the terminal, the screen is black during the flashing process. Could this "fuzz" be affecting the way the screen is displaying and causing some sort of residual static/flashing?
Tue, Jun 11
Thu, Jun 6
I have also seen an increase in issues with backlash today, it is definitely slowing things down for me as well. We are broaching them on the machine, as is Rasy, but we are still seeing problems.
Mon, Jun 3
We are still seeing this issue in calibration. Any update?
Tue, May 28
May 22 2019
We sent 6 or 8 back to toolheads on Monday with this problem, probably saw a couple more in the week prior.
May 21 2019
@EricNugent Not very many, I think many get caught when someone is going over the Frame Checksheet, but it should still be a process that a station should be responsible for. If it's on the checksheet, it should have been set/checked prior to that at some point.
There are still no steps added to the OHAI in regards to setting the Z-belt tension. This is a step that should be completed before it gets to calibration. Also, it should be communicated verbally to the assemblers when the change is made, so it is not accidentally skipped over.
@wolffchadd @kent @EricNugent @logan @DaniAO @robert
May 20 2019
May 16 2019
May 14 2019
It might be worth mentioning that the person doing the QA checksheets should not be the same person who built that assembly.
Will the fixes be done by calibration or MERpeople?
Thanks for bringing that up @MikeR , that was going to be our next question.
May 13 2019
Well Greg and Paul have found 8 sticks so far that gave that same USB read error since Friday. They are in a bin here if anyone wants to look at them. Greg mentioned that the failures are happening during burn-in, so i'm wondering if this is a different issue?
Is this just a copying error, corrupted somehow? Because we use the same USB master to flash all the USB sticks, and only use ones that say "pass" on the copier.
May 8 2019
@MikeR No, it's pretty sporadic. But still something we thought worth looking into.
So we're still seeing this issue. I had one today that would not read the USB stick on boot up, but it read a different USB on boot up. The one that will not read on boot up will read if you remove it and re-insert it while the machine is on. I put a red tag on the USB stick that did not read on boot up.
That looks good, but I was wondering if adding an octopus would increase the time it takes to print, which in turn might make it longer to get printers completed.
The drag seems normal, compared to others.
May 2 2019
Here is another image that shows how small some of the back buttons get on some menu options.
Apr 30 2019
@tutley worked on this and found that a ribbon cable in the control box was not fully plugged in. He ran the print a couple times, and then I did, with no further failures. This may have solved the issue. I don't think it's been seen on any other machines yet.
Apr 29 2019
Another question regarding the Filament sensor sheets: We received a stack of checksheets filled out and a bag of filament sensors. While the sheets aren't crumpled, there is no way to match the sheet to the sensor that was checked by a certain person or date. That is like saying it doesn't even matter, just take a random sheet! A procedure needs made for these also.
yeah, I totally agree, but that would be preferable to the wrinkly sheets. I think paper clips would also leave undesirable marks on them as well. Does anyone else have ideas?
tagging @bowman @wolffchadd @DaniAO @robert
These toolheads came labeled as @oliver mentioned, but the papers were crumpled at the bottom of the boxes. Maybe if when an order is brought over, all papers come in a stack in a bag or sleeve of some sort? Assemblers could then match the numbers on the toolhead to the corresponding sheet? Or something along those lines?
Apr 26 2019
Yes, it works great.
Apr 25 2019
Apr 24 2019
Another question about these is a lot of them have a lip all the way around where the brim has been broken off. Is this acceptable visually?
Apr 23 2019
Apr 22 2019
@logan Talking with Levi in packaging, we thought it would be easiest for all of us to make sure the screws for the tube clamps were loosened before sending to be packed, that way they don't have to worry about trying to move the X Axis. This is what we've been doing for the Betas that have been packed so far. Maybe just add that step to the calibration OHAI?
Apr 10 2019
Apr 9 2019
Hi Pot tested by and date
Apr 8 2019
Ran 7 different quiver machines so far with the new vernier with backlash gcode. Only 2 have passed specs of 9.8-10.2 on the circle (0022 and 0029), the rest are not passing. there are 3 more that still need testing.
Apr 4 2019
I am running into this issue also. The tube is very curly, and gets caught whenever it goes to the top, regardless of left or right position.
One thought I had is do the tubes need to be so long? I know we don't want to cause any binding due to them being too short, but the excess slack seems to give it room to curl.
We are currently flashing to .106 and the sounds are defaulting to Silence for all three options.
Per Adam, we are flashing to .106, and we are using the latest vernier gcode supplied by Logan (v0.7). So far we have noticed a huge improvement on wiping locations on both the nozzle calibration and the vernier print. I have one printer (QB0022) that the left nozzle hits the wiper mount plastic on the right but during the print with the new start gcode wiped on the pads.
Apr 3 2019
Correct, but I know Bob was saying that we should just be checking things at calibration, the less to adjust the better, so having the stations that build the assemblies check their work before passing it on would be extremely helpful.
I tried the original firmware versions from when I first encountered this issue (.100 and .101) and could not get it to repeat, so it seems to not have been a firmware issue.
This is the gcode that we are using. It may also be worth noting again that this gcode still wipes in different spots than the automatic nozzle calibration. We are not getting good wipes with that, either.
Apr 2 2019
i have tried 3 different quivers today total and have not had an issue at all. I'm thinking that it was just a weird bug that fixed itself when the computer had its weekly reboot.
You are correct. There needs to be a section added to Y-bed assembly OHAI then, we could not find it. Up to now it has been coming to calibration with no screws installed.
Apr 1 2019
Oh I see, I assumed that was for final assembly.
I guess I didn't name the part correctly, it's on the cable chain, where the heat bed connectors come out of the cable chain. After speaking with Levi, he says this part does not get removed and will be fine to keep the zip-tie on.
Is the control box internal section at the end of the calibration QA sheet supposed to be there? Are we opening the CB to check these items?
Mar 28 2019
Mar 26 2019
I have not had the time to get much further testing. I tried QB0015 this morning with no issues, and have had no issues with any Taz6 at all.
I will update again as soon as I can get more information.
Mar 18 2019
in calibration we prefer to have the sounds, and we like the set-up @eBeardslee recommended. It makes it easier to stay on top of calibrations to hear the sounds.
I have tried 3 different Taz 6 this morning and have not had a problem yet.
@logan The M5x10 bolts on Y and Z idlers.
it is/was there, very first sentence of step 1
The reason I asked is we have seen a couple come through with different sounds, so it was either changed at some point in pre-sub or not set as a default the same as other versions.
Mar 14 2019
@MikeR was unable to replicate at his station. We brought it back to mine (Cahow) and was able to replicate the problem. It only happens when the USB Cable is connected to Cahow. We tried it on Robert's station (Cardinal) and were not able to replicate. While in the middle of running the nozzle auto calibration, we unplugged the USB cable and plugged it into Cahow and it died. I did not have this issue until today, after the Wednesday updates. Could this be related?
It may be worth noting that it will turn off without any contact between the machine and myself, so it's not like I'm shocking it. I also noticed the touch screen seems to hang up right before restarting, so for instance if I'm attempting to home the Z axis, the Z button appears to stay "depressed" until it restarts.
QB0016 is exhibiting similar behavior. It did it when homing all axes, and when trying to calibrate nozzles. It did let me start burn-in, but when i cancelled the print, it restarted.
Step 12: you never state to remove the feed tubes to load filament, but state to push them back in.
Mar 5 2019
Mar 4 2019
QB14 is exhibiting the same issue.