Yes, I’ve had my Kickstarter U1 since early February and am now setting it up (only 5 months, that’s good, for me!).
I note the improvements in the Quick Start Guide available on-line compared with the printed issue I have, even with the amendment sheets.
Something I don’t understand: why is the instruction about raising the bed to remove transit tape from the levelling wheels (page 80) not until after the first test print??
Dragon printing now. Not a single hitch so far, all very impressive.
(I’ve skipped connecting a network)
That’s very observant of you. I remember I didn’t remove the transit tape during my first unboxing of U1 
. I’m also curious now and let me check if I can find more details.
I have served some time in tech pubs (the technical publishing department in a defence electronics establishment). The quality of your manuals and guides is superb (the current revision, anyway – the quality of the printing in my Kickstarter quick start guide is impressive, but the content a bit less so, showing a one-person lift out of the box is decidedly inadvisable, and missing indications on photos).
When I checked under the bed, there wasn’t actually any transit tape on the levelling wheels.
The first print finished fine, so I decided to see whether that was a fluke and set off another one when I went to bed. This morning I found it had stopped with about an hour to go with a “swapping anomaly” (I guess a pogo pin fault). Press play, and it resumed OK – I’ll check the print quality and report later.
Something a little weird: when the filaments were priming, I got some red poop out of the head loaded with white! No such occurrence with the other heads. I guess that particular head had been selected for a sample test in production. I loved the way one just feeds in the filament and it loads and assigns colour (RFID), and prints each part of the model in the correct colour automatically.
Further information: The best time to do this would be after the initial calibration. The bed is left “up” so it is easy to get to the underside. After a print, the bed is left “down” and would have to be raised.
Okaaaay…
I decided to run a repeat print, to see whether the perfect-print-first-time was a fluke. It wasn’t! Second time around I had to resume the print twice because of “swapper errors” (I suppose the pogo pins failed to make contact). Everything looked OK, and when resumed the print continued, and in fairness I can’t see the join (but then the dragon design will hide a lot of imperfections).
I know the pogo pins are serviceable items, but I’m thinking this is not acceptable after less than 5 hours print time. Curiously, although I can’t confirm, both failures seemed to be associated with head 2, which is the one that looked pre-used:
…or perhaps my particular unit was short of a head assembly off the production line (maybe faulty) and had another switched in from somewhere.
I expected the system logs would show when a fault had been detected and the details of it (eg which head), so I pushed them to USB for inspection – only to find they are encrypted! I’m not pleased about that, but I shall start another thread if it’s not under discussion already.
Add to that the missing transit tape…
Sounds like a returned item or ex-demo to me.
No, I can’t agree. The instructions say there might be tape under the bed (not that there will), and the packaging looked pristine. Yes, OK, they might have stripped it down and repackaged from scratch, but I haven’t found anything else untoward. Not even the print hours (which could be clocked of course).
I’ve hit the first big snag.
Has anyone else tried to print the dragon after updating firmware?
As delivered, and as per the first test print, my firmware was 0.9.3. I have just updated it to 1.5.1 and run a heated bed calibration (I thought somebody said the notes say you have to do that, but I can’t find any such note in the release notes or wiki, what it actually says is it should not be necessary to re-run heated bed levelling).
Anyway, try to print the dragon again and I get this:
[print_task_config] nozzle diameter mismatch:f_0 != e_0.4
Error Code: 0003-0531-0000-0014
So it seems to me that the firmware update incorporating the ability to assign nozzle diameters has broken the built-in dragon print file, and the firmware update didn’t replace it with a compatible one!
How stupid is that? Yes I have checked, the nozzle diameters are set to 0.4mm in the printer configuration. Maybe the G-Code interpreter is being too picky that print files contain nozzle diameters rather than assume 0.4mm unless otherwise specified.
At the very least, it ought to be possible for the user to override this kind of error on the control panel.
I have submitted a support ticket.
That wasn’t as straightforward as it could have been, either!
The support ticket wants your serial number and verification code. The wording implies both can be obtained from the control panel, but I still had to ferret out the rear product label to get the verification code. Well, I have a photo now so next time…
There’s a list of categories with no “none of the above” option. There should always be a none-of-the-above, in case whoever thought up the list missed something. In my case, “you’ve voided your dragon model in your firmware updates” doesn’t fit any of the categories so I called it “maintenance”.
When did it happen? During initial set-up? Not really, but it is during my commissioning process so…
And yet, looking at the print file in Fluidd / Moonraker, the summary says:
…so it’s found something in the GCode which defines the nozzle diameter (although I can’t see where*). Which begs the question why trying to print it throws up an exception.
* The Fluidd interface (available after I updated the firmware) let me download the dragon file to inspect it.
Oh that’s interesting. I downgraded to firmware 1.4.1 and no such difficulty – the print has started.
I got a reply from Support: in summary (and reading between the lines) they say the stats for a print file don’t get re-scanned automatically (in 1.5, I presume). They say the error report was caused by printing the file first time using pre-1.4 firmware (which it was) and then updating to 1.5 and trying to print again.
They say this will be fixed.
They also say (and this is the real news, to me anyway) that a long press on the item in the file list re-scans it, and should make it work. I’m no longer in a position to test this. On 1.4.1, a long press on the item says “scanning Gcode” (on release) just the same as a short tap.
The saga with Head2 continues.
I’ve run two more dragon prints* since “downgrading” to 1.4.1 fixed my problem, both completed, but both times with an error message that there had been a swapper error (I presume 1.4.1 retries and gets over it better than 0.9.3 did).
The message says to click here to see an error count, but nothing happened when I did. The only option I had was to click OK, and I can find no diagnostics to help me confirm the issues are all with Head2. This is most annoying. Yes, I could just clean all the pogo pins, or just the pogo pins for Head2 and see whether the problem goes away, but I prefer evidence-based actions. Hypotheses can never be proved, only disproved.
I think my next step is to submit a support ticket requesting a report from the (encrypted) log file, but that should not be necessary.
* I have youngsters in my extended family who will love these, I’m sure, so I need a few, but I find it rather irritating that for every 22g dragon I get a 21g wipe tower! I would like to print several at a time (with just one wipe tower), but unless the .3mf is available somewhere there doesn’t seem to be a way.
May I suggest the Quick Start Guide includes a quick-reference assembly (installation) checklist? It could be something like this:
By the way, it makes no sense to interleave instructions for installing the filament feeders with the 4mm filament tubes. Fit both feeders in one go, and then all the 4mm tubes.
I take it back.
Same error report post-print (actually reads “Toolhead Swapping Anomaly”), but I tried harder to click through this time and got to a report showing Head2 with a count of 2 (zero the rest). I won’t raise a support ticket for this… just yet.
