Daid

The "allow your own temperature start code" has been in there for quite a while. From the 12.08 release I think. Anyhow, for the testers. I've uploaded an 3th test version for windows (Mac version will follow, but my Mac is in use right now for something else) I've fixed: * Zig-zag bug (during infill it sometimes was oddly moving back and forward only printing in 1 direction) * Single wall didn't produce infill bug * Extremely verbose GCode reduced. This improved print quality on my tests. But I'm not 100% sure all issues here are fixed. * Added infill overlap setting (for flexble PLA this is very important, as well as tweaking that final bit to get your top perfect) * Removed the crash on bad layer height (when editing the layer height the engine crashed) * Allow loading of GCode files for direct GCode printing or viewing (press the load button, in the bottom right of the file box select the gcode option) * Show moves on the currently viewing GCode layer (helped me catch the zig-zag problem) * Fixed 0% infill problem I've also added my experimental dual-extrusion nozzle offset calibration routine. It's not perfect yet and still requires some manual tweaking afterwards. But I want to make some steps to make dual-extrusion easier from a software point of view.

It's something that the Ubuntu maintainers broke in the numpy or PyOpenGL packages.

Order 301, that's an pretty old one :-) about the same time-frame as my own printer. I think all the information you have there is proper. I hope the netfabb license can be transfered (not sure how that works)

That's up to you. It's not my printer and not my money. Just wanted to point out that to have your version "up-to-date" it needs some extras.

One small thing. It looks like it's a Rev3 machine without a V2 hotend, feeder upgrade or Ulticontroller. So your comparison with the assembled machine doesn't match what you are selling, as those are included in new kits or the assembled machines.

Most of it was short-belt slack. I was also missing a screw in the slider blocks, causing some play on the X/Y rods. And I added some tensioners on the long belts, as well as securing my hotend better. Simply put, everything was a bit lose :-)

Right now I would benefit from someone finding the time to find out what is wrong with the spawn of satan machine that I'm trying to use for my tests. But that's not something you can do from your place. It would be interesting to know how much retraction is needed in dual extrusion prints when you are swapping nozzles. Did you do any experiments with that? I've tried a few different amounts and I'm currently using 36mm because that's the whole length from tip of the nozzle to top of the brass. But I just did a few random tests without a proper conclusion.

The latest known stable firmware comes with the latest Cura. I highly recommend installing the firmware from there even if you use netfabb.

I resolved most issues in my machine, except for these bearings. I noticed that printing at 50mm/s makes the bearing issue go away (I think it's the bowden tube keeps some pressure on the head removing the effect) I've also checked a lot of other machines for this defect. I couldn't find any others anymore. I do have a new set of bearings, but I haven't installed them yet. But my infill is touching the walls just fine now, so you'll most likely have a different issue. Maybe an extrusion issue. Posting photos of your print will help, as we can see a lot from those with our experienced eyes.

Yes, it's something I want to add. As I think it would help. But the dual-extrusion I machine I have access too is giving none-stop problems right now. So I haven't got around to make it and test it yet. There is also the Cura Beta which is causing some issues for people, which is currently a higher priority.

We stopped listing batches a long time ago. You have a Rev4 machine, which matches with the current build instructions: http://wiki.ultimaker.com/Mechanics_build_guide

Oh, I've also done some updates for Dual extrusion. One of the new things I've also added is a calibration wizard for nozzle offsets.

Not sure yet. I still have a quality bug to squash, which is pretty important. Feature wise it's missing a few minor things compared to 13.04, but most of those are not extremely difficult to add. But I hope pretty soon. I think we can live with a release which is missing a few minor things from 13.04 for a lot of other improvements.

Advertised with Cura screenshot. Hip :-)

The GCode save option is also available from the file menu btw ;-) And you can add custom temperature code. If you add: "M190 S{print_bed_temperature}" To the start code, then Cura won't put the bed inheating above the start code. And if you put an: "M109 S{print_temperature}" In your start code, then Cura won't put the nozzle heating above the start code.

Sounds like a working fix from Petrus. Note that I'm not planning to release any SF based Cura anymore, as my new engine is making leaps of progress. And that has dual-extrusion support build in instead of hacked on top.

There are a lot of safety features in place. But they are not 100% fail safe right now. The biggest issue is when you disconnect the 3 wire connector. This sometimes gives an error, and it sometimes doesn't. On a reboot of the machine it always gives an error. (It's something I want to improve, as I have some ideas on how to catch this case better) As for the "fire hazard", while it can cost you a PEEK part, a printer bed, and a lot of bad smell. The printer won't go up in flames. This was actually tested. If you have a temperature sensor not in the heater block, the printer will try to heat up but stop with a "heating failed" error, as it doesn't see the printer warming up while it should. It also detects odd temperature readings and act on that. The main issue left, a 3 wire disconnect, keeps the temperature reading at about the same level as the disconnect. And thus makes it hard to detect the case.

In Cura you can use every configuration setting in the start code :wink: there are just not any settings that only effect the start code. Maybe that's what KISSlicer is doing? Cura is doing more stuff at the initial layers then what it's allowing you to configure, for example not just the first layer is slowed, but the first 4 layers are slowed down. I know how the KISSlicer top/bottom algorithm works. And it is prone to small errors. I'm using the same kind of algorithm for support material, where slight inaccuracies are not as important. The SD card code was quite complex to figure out. Especially on windows there are all kind of odd cases where card readers can show up as drivers without a card inserted. It also identifies USB drives as SD cards, nothing I can do about that really. But it works great on my laptop, and that's all that counts right? :smile: The SD copy button also turns into an USB printing button if you have a printer connected. And you can right-click on it to always access the "save as" option or the usb printing option (if detection of the printer fails for some reason)

Fluxline also reported that the selecting works for him now. So I hope that's fully fixed now. Right now I still have: * Raft not working * Extremely detailed models are not printed as well as with old Cura (small cylinder with 80 segments prints worse with new code) * Expert settings dialog is sometimes not opening on MacOS * Support structures are missing advanced configuration settings And a huge list of feature requests :-)

Actually, my new slicer manages to stress out Marlin by generating an extremely detailed path. It causes stops on USB printing, but even slowdowns on SD printing. So more CPU power and more memory wouldn't hurt. Marlin is pretty much pushing the AVR to its limits.

If you are having extrusion problems, you might want to check the material feeder. This part: http://www.flickr.com/photos/ultimaker/8635151612/ We had a few machines here at UM which had occasional extrusion problems. I did some full diagnostics, and I found that on 1 machine the bearing in the wheel was not properly centered causing the wheel to be pushed sidewards. But the other issue gave move problems, the long bolt that you see there, with the lock nut, it was screwed on tightly, so the side plates (not seen in the above photo) where clamped on the side of the feeder, making it unable to move. This is quite easy to check, if you lock/unlock the filament feeder (by lowering/raising the lever) you should be able to see the clamp move. But the clamp and the spring part should move a different amount, if they move the same amount then the spring part isn't working.

For the testeds, I just uploaded a new version for windows at the same location. I hope this fixes the selection bug that Fluxline and a few others where having.

Yes, I haven't updated the "latest version" file online yet. Due to some people are having issues with runnint Cura 13.04 on MacOS 10.6

But they don't have to be a multiple of the nozzle size or the layer height. A 0.4mm nozzle can extrude 0.3 to 0.8mm lines. Cura figures out which line width to use. And the top/bottom gets rounded up to a multiple of the layer heights. And the top/bottom thickness is very simple. You need about 0.6mm of layers to get a good solid infill, almost independent on the layer height. So 3 layers on 0.2mm layer heights fills it up, or 6 layers on 0.1mm layers. In that aspect the current setting makes total sense. I also like that these settings are measurable, and independent of each other. They also say something about the end result and not about the process. They are a well thought out idea.

The limit switch is accurate up to 2 micron in repeatability. Yes, that accurate. It the bed that is changing shape on most machines (but not all of them) depending on the printer this can cause up to 0.5mm difference in tilt. But a tilted platform needs re-calibration not just a different Z start height. Manually setting an origin on a CNC mill is done to mark the position on the material that you are milling. With a 3D printer you don't have material, so no need for an origin point on it. The normal start code that everyone uses also overrides the origin point, as well as homing resets the origin point. Just because you used it doesn't make it a good idea. Nor makes me stupid for removing it. And it's commented out in the firmware, you can always put it back in yourself. So far you're the first to bitch about it, and before that I've seen multiple questions from people asking what the option did (which could only be explained as "it does nothing in a normal setup")