misguided

Yes, you'll have to pay the customs cost. No way around it. Unless the Ultimaker guys start setting components so that you can arrange to laser cut the body yourself. That *might* bring the cost down, but probably not enough. I think import duty was around $250-300. Basically it's shipped by DHL (or it was in my case), they do the customs paperwork for you, then give you a call when it arrives in Australia and customs payment is due. You can pay via CC over the phone and it gets released that day (which means you'll probably be getting it the next day if you're in a capital city, not sure about regional areas).

It's been a while but there doesn't seem to be any definitive answer to this... so I figured that I should ask it again. Prints have strings, blah blah blah. [*:3ey6bo3e]Lower print temps help, but doesn't totally remove strings. [*:3ey6bo3e]Same with the fan. [*:3ey6bo3e]I've been told that printing order helps. So infill first (since it's the densest), then loops/walls, then perimeter... Personally I haven't noticed any difference with regard to stringing (in my case at least), but the outer surface finish seems worse (blobs and such). [*:3ey6bo3e]Faster travel speeds help, but don't fix the problem. [*:3ey6bo3e]Dimension's reversal doesn't seem to work consistently, for me it ends up blobbing on pushback. And the amount of blobbing seems to be related to how long it's been travelling for, so that means a fixed pushback value doesn't seem to work. Same for speeds, the extruder will often happily retract quickly, but pushback at that same speed will cause it to lose steps. [*:3ey6bo3e]Disabling the extruder stepper when not it use seems to help, but I find that on prints with many jumps and small segments/loops, it extrudes too little plastic. [*:3ey6bo3e]Never tried oozebane since that's supposed to be a DC extruder thing (or am I mistaken?). So, how's everyone dealing with strings these days?

Most aggregators are able to pick up the rss links from the page's metadata if you give it the site/page's url. All posts: feed.php" New topics only: feed.php?mode=topics There are also feeds for each section of the forum and also thread (look in the page source the relevant urls).

You can also subscribe to the forum rss feeds. There are 2, the new topics only, or all posts.

Thanks for the update Owen. Yeah, the values need a little bit of tweaking to work for prints. It's more likely to undershoot than overshoot... I still haven't figured out how to mathematically tweak the values to cause it overshoot slightly while remaining stable. You can modify the "C" extrusion speed bias (I think in Bernhard's branch, you need to modify and upload the firmware to change it). WIth my PID tuning firmware, M301 C0.17 will set the C bias (0.17 worked for me, but your mileage may vary). The higher it is, the harder it'll drive the heater based on your extruder speed. Having said that, my fork's temps might behave a little differently. I added an error bias (seems to help) and a filtering factor (I can't tell if this makes a difference).

Thanks Joel Is it exactlty that now or 10X that? Whoops sorry, forgot to mention. Use those values as is. I've added code in the firmware to just scale it up by 10 for the moment.

Thanks Owen, yes that M301 lline looks fine to use. Dave, that's the raw value and not the temps (so 414 is actually 202.15C). Yeah I should really change those outputs to say raw temp or something

For those who don't frequent the mailing list, I'm looking for people to try a PID auto tuning routine that I'm working on. The code is at: https://github.com/j-c/Marlin After uploading the firmware, you can start the routine by sending "M302 S190". 190 is the temperature that the firmware will attempt to use for tests. The code doesn't deal well with tests with low target temps (140-150). The resulting PID values might not be perfect, but it gives a pretty good starting point (and takes a lot less effort on the user's part than the ZN tuning method). What the routine does: 1) Firmware slowly increments the heater output and see what temps it hits. Repeat till specified temp. 2) Firmware waits for printer to cool down and stabilise. It assumes this is room temperature 3) Firmware then heats up printer with output determined in step 2 4) As the temps increase, the printer gathers the process dead time. As the temperature stabilises, the printer gathers process time and process gain. 5) Firmware calculates PID+A values and outputs them via serial. Note1: All tests are run with fan on (firmware should turn it on). Note2: If at any time, the temp hit 275 degrees, the firmware aborts the test, turns off the printer but leaves the fan running.... In theory this should work, but I've never been in a situation where this happened (nor did I particularly want to force it to happen). The "A" number is the heater output filter. It's not in standard Marlin, I just left it in there for testing. If anyone tries this, could you please report back with any problems that you encountered, and also: [*:2id0yiuh]The final PID values [*:2id0yiuh]Process gain [*:2id0yiuh]Process dead time [*:2id0yiuh]Process time [*:2id0yiuh]Temperature used and actual final temperature [*:2id0yiuh]If you have an insulated hot end (and what kind) or if your hot end is non-standard For me, the untouched numbers this give me temps that are stable when not printing, but a 6 degree drop when printing (this can be mitigated by setting the "C" extrusion speed multiplier or Kc in the firmware config). Thanks! Hopefully this works for others as well and I can continue on with this approach.

I've been working on a PID calibration routine in the firmware (getting close to getting something usable) and since you've mentioned that, I'm thinking if maybe this should be on the host side as well... Only extra thing that's required is for the host to be able to set the controller output (actual value of the analog output, not the target temperature) to determine the initial tuning constants. Not sure if we've got that on Marlin... setting the controller to open loop might do it, but then the way it's implemented at the moment requires you to reflash your firmware, calibrate, then flash back to PID enabled. Anyway, I'll continue on the PID calibration in firmware since I'm close to a first release.

wouldn't the wiki itself be a better place for this? http://wiki.ultimaker.com/Mechanics_build_guide There's already a set of instructions there that get updated.

Ah cool! Didn't notice the little exclamation mark

... Well I think this forum received a few spam posts prior to it going live though. Will there be any mechanism to flag posts as spam or moderators to help with cleaning out the crap?