Daid

Are you using plugins jweaver?

The latest RC from: http://software.ultimaker.com/Cura_closed_beta/ Contains the fixes I did for the BFB style printers.

Uhm, PU can look at single layers, while the current mainline can not. PU changes the left dialog when you switch to layer view. (Note that this is just quickly hacked together for debugging of other stuff)

Which part of Cura do you want in 64bit any why?

Plugins currently still have 2 problems. The above problem. As well as applying plugins on large GCode files will crash Cura.

In the future. Yes. I've updated the RC to RC8. Not much has changed, but that should fix the MacOS support. Still need to do some final UM2 firmware thingies before it's really ready.

pip has a different power module then the one Cura is using.

Be sure to use a angled bit to finish the edges of Dibond. The aluminum is sharp at 90 degree angles. Our first 10 prototypes where just straight cuts with no deburring. We bled a lot because of those machines.

The min and max fan speed work together with the minimal layer time. When the minimal layer time is not yet reached then the minimal fan speed is used. (The idea being that smaller layers need more cooling and thus more fan speed)

Power is pulled from: https://github.com/GreatFruitOmsk/Power

My standpoint on this area is that every full-metal-hotend for 3mm filament will jam with PLA. So far nobody has proved me wrong on this one. Other then that, cheers I hope this will help people who really want their dual-extrusion machine. (Note I also added dual-extrusion UM2 firmware in the next Cura release. So that should help some people who want to experiment with it. But it's not officially supported)

Yes, like I said, it's a workaround, not a 100% proper solution. But it works for now.

Well, I do want to solve the thin sections problem one day. But I have no clue how yet.

Click 1: "Machine menu" Click 2: "Select the machine with profile you want" That's just 2 clicks. And I think any other solution will also have 2 clicks (or else the GUI will explode)

Well, time.h isn't strictly needed, as it's just used for reporting how long certain processes took. Most of the code is quite simple plain C++ with use of std::vector (which is also very standard and supported by all compilers). So you might just have to strip out some parts that you do not need.

Or, if you switch a lot, you could add 2 machines profiles, one for each material configuration. As a workaround.

Most likely there are some extra internal faces in the model, causing cura to be confused about what is inside and outside the model.

sys/time.h is also provided by the mingw compiler, which provides some easy to supply posix/linux compatible headers where possible. Which makes cross platform developing a lot easier.

Let me think about that for a while. No.

It used to only work with direct drive, and went crazy when used on bowden tubes. But with all the changes in the code, it might even be broken now. (Direct information from ErikVdZalm, who implemented this feature) As for the above proposal with pressure buildup&release has been in my head for a while. As it could also be very useful for multi-extrusion. But there are quite some cases to consider. As you do not want to do this on every print line (example, infill lines are printed with small moves in between. You don't want to release pressure between those lines) As for the change of start position, I think this will make the prints worse, as the scar will be on the side of the print instead of the corner.

Note that this might damage your motor, as you are running it outside of specs. Which is also why the menu's don't allow for anything above 1300mA. Note that in our own tests we did not get any improvements with more motor power. (Disclaimer, bla bla. If you damage your motors due to messing with this it won't fall under warranty, bla bla, you'll understand)

Performance increase? Raster slicing is actually slow right, as you have to process a lot of points... (compare a 200mm cube in Cura with Craftware slicing time and you'll understand the difference) Anyhow, don't fear, I have no plans to switch to raster. The support code is using a raster right now, and I hate that, it's what causing most of the problems with the support structure generation. (And yes, I'm back. 2 weeks of no Ultimaker. No 3D printing. I really needed that. Pretty much worked none-stop for the last 2 years. Even if I had vacation, I did awnser mail&forums before. This time I really took time off, which was great)

Because the whole design of the CuraEngine is based on enclosed 2D shapes which might need to be filled or not, and outline printed around them. Single walls simply don't fit in that structure&method.

It's in util/profile.py (something with defaultProfilePath or something like that)

You're doing nothing wrong. Cura is doing the wrong thing here. It's quite bad with "small" support things.