nallath

Not yet. We're working on that.

I think this has to do with the weird way USB ports are handled in Windows. This is one of the reasons why we recommend to not print with USB.

Someone should add the printerbot metal 3D model to Cura

It's not that simple. Using multiple cores means using multiple threads which has a pretty big impact on the complexity of the software. Most of the slicing must be done in sequence, so it wouldn't even give you that much of a speed boost. It should use a full core though, so I can't explain the 8% CPU usage.

http://software.ultimaker.com/Cura_closed_beta/15.10/Cura-1.99.0-dev.20151117-Darwin.dmg <- Try this one.

I heard it will be able to breathe fire!

Nope, not quite like that. I don't think any of the python stuff is missing. The engine is created in C++ anyway.

Send a message to @SandervG. He can hook you up

There are two "latest" versions of Cura. You have the 15.04 and the 15.10 version (renamed to 1.99). The 15.04 version uses a very limited plugin system which only allows you to perform post processing on g-code. The 'new' Cura on the other hand has a very advanced plugin system that allows you to add new tools, do post processing, add new rendering types, new file types and even change the backend. Both work quite differently with regards to how to add plugins. That being said; What did you try? (and didn't work)

There is an update, you can find it in the link I posted (1.99)

We didn't change anything with 15.06.03 in a long time. This was a very buggy release, so I strongly recommend that you stop using this. Switch to the latest release if you want more stability. You can find it on http://software.ultimaker.com/Cura_closed_beta/15.10/?C=M;O=D

I'm not aware of any setting that could cause this. It could be an issue with how both printers handle G-codes differently from how Cura generates it.

So you should either change the function printerConnection.cancelPrint() to send the right g-codes before the connection is actually terminated, or you add the g-code sending before; if id == 140: #send g-code here self.frame._printerConnection.cancelPrint()

So saving as STL doesn't work either?

Do you have a firewall? Like I stated before, that's usually the software responsible for this.

This is probably caused due to spaces and tabs. Some text editors set tabs to two spaces, some to four. Python is quite particular in this regard.

That's pretty much impossible to say. It's pretty much random (not true random, but close enough).

Only how it travels from one island to the other. There is no real alternative to this (save spending enormous amounts of time / effort in re-inventing the wheel)

Slice it on a different operating system (yea, really. We use hash maps and those tend to give different results on different OSes)

The default for e is 1250 and for xy is 1300 I believe. All of them used to be 1300 (if i recall correctly)

That line of code actually sets the motor current above the defaults of even the X-Y axis. I believe we lowered them at some point due to heat issues.

That is what the code you need to write to get this to work should do.

Technically it should suffice to let abort do the same thing that it does now and once that is completed execute a certain g-code that does all of these operations. I have no idea how the customization of pronterface works, so I can't help you there.

This code is not allowed according to c++ spec, but our standard compiler (GCC) accepts this.

They are sometimes used interchangable But going dutch probably means this: