- User Since
- Aug 11 2017, 3:36 PM (92 w, 2 d)
Fri, May 17
@logan I have already placed an order in for a JST crimper, it should be here on Thursday.
@youngmrcarlson try to in the nozzle offset menu, set the z to 0.07. Thats been an average. In production, when they get a number thats way off looking they try to set it to what the average has been and that has been helping.
I have recorded the circle dimensions for the first 4 prints ive done with the latest gcode.
Its kind of hard to see the gaps with translucent filament. If possible could we refrain from using clear or translucent colors?
The gcode @kent made is fast and has no bloops or goobers or ooz or whatever you wish to call it.
Im trying the gcode @kent just pushed.
Thu, May 16
@kent do you have an idea on how to get rid of the alleged bloop?
Done a couple prints with this new gcode. Its looking very good to me. @DaniAO have you had a chance to print this one yet?
Tue, May 14
@DaniAO I know you have been doing some testing with these gcodes. Are you seeing the same thing in your prints as me? Maybe I'm having an isolated issue specific to my machine but I don't think there is.
After trying a few prints with each adjustment @oliver has made, Im still seeing the E1 nozzle printing to squished.
@bowman Should we keep just a little just in case we do not have extra assemblies to swap out?
@oliver what kind of processes did you have in mind? Just curious.
I am also wondering, should we keep a small stock of things like boards and cables and fans etc? For instance if a control box has a bad LCD, the printer would get red tagged. If we had a stock of those assemblies we could swap it out and get the printer back into calibration. On the flip side if we didn't have them here we would have to make an M/O then wait for it to be processed, then built, then shipped over to mountain. This could take a few days depending on the work load and a printer would just be sitting waiting for parts.
Mon, May 13
With the v8 gcode, once I got both of my z-offsets to be the same, I started to notice that the E1 was printing very squished once the actual objects was being printed.
Ive done 2 test prints with @oliver gcode. So far I haven't seen any oozing. I am going to do a couple more prints to make sure its consistent but its looking good so far.
@kent I am still getting some ooz with the v8 model you made.
Thu, May 9
I have ran this print twice and I got ooze in the same spot on both prints.
@kent what version of cura did you slice it in?
Wed, May 8
@robert is it possible the square is getting a bit dirty?
@paulette are you seeing this on many machines?
He didn't add an octopus.
Mon, May 6
The frame squaring fixture has been completed and tested in production. There have been no issues. I will be closing this ticket.
Fri, May 3
We are going to try .114 firmware to see if this helps with the screen.
Thu, May 2
@oliver did we not see this in first articles?
we are starting to see a lot of lcds like this. @mjpelletier any ideas what could be causing this?
Apr 12 2019
Closing ticket since we have not had any other reports. We can re-open this ticket if the issue shows back up.
Apr 10 2019
Apr 4 2019
Closing this ticket since nothing has really happen with it.
@MichaelM I ordered some M5 drill bits that will fit that screw head. I will close this ticket for now. If the new bits dont work well we can re-open this ticket. PR11079 for reference if you want to see what I got.
Jigs were made and given to production.
Apr 3 2019
Is it pushed to cura so I can just do a re-slice?
Cool thanks @tutley just wanted an update on this.
Apr 2 2019
Inserts samples have been completed. Will give them to @MichaelM
Apr 1 2019
@logan I re-sliced the piano print in a newer version of cura that has some profile updates.Try this new gcode and see if it makes a difference.
Mar 28 2019
Mar 27 2019
Mar 26 2019
Ohai-kit has been updated with the new parts and part numbers. Closing for now, re-open if new changes are needed.
Mar 25 2019
Closing this ticket since we have made the instructions, they just need to be fine tuned.
Notes have been addressed.
Part numbers have been added.
Mar 22 2019
I did a recent pull of the repo and it does say to add thread lock to machined idlers, but it doesnt say anything about pullies. Also what type of thread lock are we using on the idlers? The qc sheet does not specify.
When I tried other usb sticks I did not get this issue. I am pretty sure it was just due to a corrupt usb.
Packaging part numbers :
SH-PA0060: TazPro, Top Endcap Foam, 1.7 lb. Density Polyethylene Foam, Black
Mar 21 2019
Mar 20 2019
Mar 19 2019
Ohai-kit has been created and ready for review.
I just followed the steps in the current ohai and had no problems.
@oliver did someone ask for this or just something you think we should do?
Mar 18 2019
I will create an ohai-kit that shows how to do the glass technique.
Ok then, I updated the ohai-kit to say 2in lbs.
Do you see any issue with the screw sticking out a little?
@west any thoughts?
@franklin which ohai does this need to mentioned in?
This ohai looks good.
Looks good logan. Double space.
There are no pics of attaching the extruder cap. Is this going to be done at calibration?
Step 20 does not show using the green spacer to set the distance from the control box.
And we can prolly remove the cable clips since they are supposed to be getting on when the frame is being built.
@logan any particular reason we are putting on the tool head after the control box?
Mar 15 2019
Since @paulette is not here today I went ahead and tried all the above options. I tried two different brand new usb cables and the restart still occurred. I tried the cables in all the different usb ports that were built into the cpu so I don't think its the hub. I also grabbed a different printer, quiver 13, and still the restart happened. I also took the printer to a few other work stations, Bustard, Sapsucker, and Thrush. I was not able to re-create the restart on any of those workstations. I was however able to re-create the restart on Mallard when I went to use that work station. I do not feel there is anything wrong with the printer but I do think there is an issue with the Mallard and Cahow computers. I'm not sure what it could be but in my opinion after checking different cables, computers and printers, those two work stations have some kind of bug or short or just worn out.
Quiver 16 still wipes a little to the left but it is better.
On quiver 14, the left side wipes nice and good, on the right side though it still wipes to the left.
@anolen Ive been able to test this on one machine so far and it appears to be wiping more centered. The wipes for the calibration cube are still wiping to the left but that may be more of a general firmware thing than gcode.
Mar 12 2019
I was able re-creat this issue on both Quiver 8 and 10 once I updated to .100 firmware. I was not able to do this with the older .91 firmware.
Mar 6 2019
@matth is there any chance you could jabber me a vid of it? I may be able to help.
Mar 5 2019
Just did another round of drop testing.
@karrad I can not reproduce this on 188.8.131.52. When I move in small incraments, the lvd will pause until the z-axis catches up then I can continue to move the axis.
@karrad I would get around 100-150 mm before it would restart. I am going to try that new firmware this morning.
Mar 4 2019
Feb 28 2019
So I have found the wipe location for the calibration cube and the start gcode are wiping in different locations. This could explain why we are getting different wipes during different tests.