- User Since
- Mar 29 2018, 11:19 AM (76 w, 4 d)
Wed, Sep 11
@logan We are still seeing this issue at calibration, with a large increase in the last few days. If the suggestion to reduce the torque spec is OK, can we have that implemented in OHAI and at finals?
Mon, Sep 9
On Thursday, had an [EL-HR0179] X harness with a bad crimp on the spade connector for the switch, it would not work and the connector pulled off easily. We had to re-crimp.
Wed, Aug 28
@david.hall I meant the actual wire tester that tests each individual wire, the CableScan tester.
Aug 12 2019
not sure if this is a bug worth mentioning, but I had one today where when I hit Auto Home, the whole screen went blank except for the Auto Home button up in the corner. It still Auto Homed correctly, and went back to normal afterwards, and retrying it I got the Please Wait screen.
We've been cleaning the nozzles with alcohol prior to running auto cal. Do you think this isn't enough?
Aug 6 2019
I tried this and it still doesn't move it enough to capture all the wires in the zip tie.
Talking with @kent today, we may need to have the drawing revised to specify where the heat shrink needs to be in relation to the connector.
Aug 5 2019
It seems to be almost all of them. It is measuring about 30-35mm from the heat shrink to the connector. Red tagging these for rework would stop production, as we have so few Control Box Chassis right now. It is possible to put the zip tie on the other side of the connector for now, if the main reason for it is to keep the wires from dragging while the Y axis is in motion. Would that be an acceptable work around until these get fixed before they are sent to us?
Jul 30 2019
Jul 25 2019
please also make changes to the Finals and Calibration OHAI to reflect the new distance between clips.
Jun 25 2019
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.
Jun 24 2019
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.
Jun 20 2019
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.
Jun 18 2019
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.
Jun 17 2019
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.
Jun 12 2019
@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?
Jun 11 2019
Jun 6 2019
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.
Jun 3 2019
We are still seeing this issue in calibration. Any update?
May 28 2019
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.