Daid

You can also export collada files from sketchup and load those into Cura. (And this has nothing to do with ini files. ini files contain settings, not the 3D model)

Python code. 32bit. StringIO.

This.

Cura's pause function for USB printing is broken. I have an intern which is going to look at it the upcomming weeks.

No risk to the hardware, just more chance it causes other equipment to stop working.

I'll talk it over with the youmagine guys to see what we can do.

It's intentional. Using PID on the bed causes a lot of EMF, which in turn causes issues with FCC and CE certification. It should be easy to test if it's a scheduling issue. By adjusting this: #define DEFAULT_bedKp 124.55 #define DEFAULT_bedKi 23.46 #define DEFAULT_bedKd 165.29 To: #define DEFAULT_bedKp 10000.0 #define DEFAULT_bedKi 0.0 #define DEFAULT_bedKd 0.0 You should get effectively the same result as the PID disabled for the bed. But then with the PID code running as well. (Does need a reset of the machine settings)

In the GCode is there anything in layer 0? It could be that there is a small "spike" at the bottom of your model, causing Cura to generate an empty layer (and thus no brim)

This can be the result of a bad SD card, or communication issues on the long flat cables going to the ulticontroller. The UM2 has some fixes for this, but those have not been backported to the UM Original yet, because I hadn't seen this problem on that machine so far.

Output GCode size was causing memory fragmentation limits to be reached on windows.

Is it red or purple? (It's broken all the same, and you should handle it with support, but I'm just curious, as red LEDs should not happen normally)

Digging up old topics to reply in isn't really the best way to get your problems solved. Especially if there are 2 other topics about the problem already. As I said in the other topics, if slicing stops, first check out the latest beta to see if that solves it: http://software.ultimaker.com/Cura_closed_beta/

Most likely a bug in the plugin. (But it could also be that the viewer is not handling M82/M83 correctly. What it is showing is a move with loads of extrusion. It's just a normal green line, but then super width compared to normal, meaning Cura is seeing a lot of extrusion during that move.

Most likely your bed leveling is off by 0.3mm then. You can easy check if Cura is doing the proper thing. If you generate GCode for a cube, open this gcode in a text editor (like wordpad) and look for the last layer, and the last Z move it does. For example, my 20x20x10mm test cube has the following GCode: G0 F9000 X105.739 Y121.295 G1 F3000 X106.202 Y121.758 E1969.46988 ;LAYER:97 G0 F9000 X105.600 Y121.900 Z10.000 ;TYPE:WALL-INNER G1 F3000 X105.600 Y103.100 E1970.22188 The G1 Z10.000 tells the nozzle to be 10.0mm above the bed. Which should result in a 10mm high cube, if Z0 is exactly touching the bed (as it should)

The latest beta contain fixes related to this problem, can you check if this solves it for you: http://software.ultimaker.com/Cura_closed_beta/

The motors are have specifications that allow up to 1300mA. That's why the firmware limits it at this range. Running it beyond this range is at your own risk. (Aka, don't complain at us when you need a new motor) Also, in tests we did, we didn't find more strength when going over 1250mA. So that's why the default it set to 1250mA. Also note that a significant factor for the UM2 feeder is actually the temperature of the feeder axis. By increasing the current to 1500mA you are putting more power and thus more heat into this axis and it will grind a lot easier.

Generating the GCode from a polygon is something that takes no time at all. Insets and up/down skins are the two most important things in the whole slicing. Insets are also known as "perimeters" and up/down skin is also called "top/bottom infill" in other tools.

No problem there. Whole situation is kinda annoying (also because the guy in charge of webservers is currently on vacation)

Might be that the normals of the holes are the wrong way around. Then Cura can decided to fill instead of keep a hole open. In the expert settings there are "fix horrible" settings, unchecking the "type A" one changes this behaviour.

Just a hunch, could you give the firmware of Cura 14.10_RC5 a spin? http://software.ultimaker.com/Cura_closed_beta/ I changed a few things in there, including the temperature measurement&control stability. Maybe you are experiencing a temperature fluctuation (which I see happening in some machines at the office at well, but is quite rare, and this newer firmware fixes it for the machines in the office)

Well, maybe the glu32.dll is the culpit. But the error is coming from glut32. Another cause could be the total lack of OpenGL drivers, but that usually gives other errors.

I have no experience in CUDA. So my comments on this might be totally wrong. But I do know the Cura code, as I wrote most of it. Most processes in Cura are serial, not parallel. For example, the translation to GCode has a dependency on the previous GCode piece, start positions and printing order is determined during the gcode export step. And while some stuff here could run in threads with in/output, it's not massively parallel that you need for CUDA as far as I know. What could potentially be done is looking 2 steps. First step is "generating insets" and the second one is "generating up/down skin". These steps are done per layer, and do not need the information from that step for any other layer. So they could be done parallel with each handler doing 1 layer at a time. However, I think the memory bandwidth to the GPU is quickly going to be the bottleneck instead of the actual processing. (And the support material generation code could most likely run on the GPU, but that code sucks big balls anyhow, as it is using the wrong method)

Uploaded a new RC5, same as before except for the missing dlls, and newer firmware builds (something else I was working on)

Slicing is broken, it's missing a few dlls that I need because of a change in compilers. Will update ASAP.

Which OS? (Note this is the first version where I used a different build process for the windows version, so that might be causing some issues right now. But it makes it easier for me to build versions)