ultimaker / curaengine Goto Github PK

It appears that when forcing the minimal layer time, only the extrusion speed is adjusted, while the travel speed is left as is.

It think it would make sense to throttle the travel speed at the same time, since there is really no advantage in traveling around quickly while having to slow down much more than needed (and worrying about hitting the minimum speed) when extruding because of that.

The "fix" looks like an easy one.

I have looked at the way the bridging direction works and I think this should be done differently:

Imagine a hollow cube (or a rectangular tube) with a rectangual cut-out on one of its sides.

A layer within this cut-out would look like somwhat like a (ectangular)"C". The first layer on top of the cut-out would then be a (rectangular) "O".

Now, as far as I understand it, the bridging direction algo looks at the last layer being a "C" and finds that it's only one "part". So, the bridging direction is set to -1, leading to "normal" alternating infill directions.
If you have the cut-out on both sides, the bridging direction is correct. because the algo sees two parts below and finds that their centers of gravity are in the direction of each other that I would expect to be the bridging direction.

Generally, I think having the bridging direction as member of a layer "part" is not so good. Imagine having a cut out on the right side and another one on the top side. Which direction should be used on that "O" shaped "part"?

I have looked into the code only shortly, but Looking at the output, I see (and indeed it's clear) that the engine is able to detect the area where there has to be a solid infill. So what about this idea: Remove this "bridge direction" member of the whole layer part. Instead, after having calculated the bottom infill area, make an intersection of this area with the whole layer below. In the example above (with one cut-out on the right side) the result would be two rectangular polygons (because of the overlap of the bridging area). Now take the centers of gravity of them, and you have your direction.
On the same part, there may be the above mentioned cut-out on the top side. Here you do the same, and you have again the correct angle.

As I said, I havent looked very closely at the code. Maybe there is something that I am missing which makes this impossible.
Starting somewhere in February (this month I am very busy) I would be happy to take a closer look at it and maybe try to implement this (it doesn't seem to be very complicated to me). But I just wanted to ask you what you think about it first.

Support structure would be stronger if the lines were connected as in skeinforge.
Alternating support lines are connected together in a serpentine fashion. I think this gives more side to side stability.

The E coordinates should be reset occasionally so as not to grow too large and cause precision problems. Suppose the firmware parses the E coordinates into a single-precision float, and the extruder has 800 steps/mm. When the E coordinate is above 21 meters (2^24*(1mm/800)), the firmware will effectively round it to 2 steps (or 4, 8, etc. as the numbers grow larger).

;Generated with Cura_SteamEngine 13.12
M140 S70.000000
M109 T0 S200.000000

i can't figure a way to change that, since i prefere M190 to set the bed target temperature, so the extruder isn't already hot while waiting for the heat bed.

would be good to change that, or at least give a way to customize it.

Just a typo in one of the config settings.

(moved from https://github.com/daid/Cura/issues/550)

When slicing http://www.thingiverse.com/thing:8896 at half size with 3 perimeters Cura 13.06.05 does not comb when moving between the tiny bits of infill on the legs. See the jumps between the legs in the attached image.

(could be a dup of #6, but I can't tell from the descriptions)

I've started adding my fork to my Jenkins install and found that two of the unittests output different gcode when built on my raspberry pi that's running raspbian wheezy. I'm not really sure where to begin looking, so any pointers would be very welcome.

You can see the output of the build commands here [1] and I can provide the full gcode if you like.

[1] http://ci.guifications.org/job/CuraEngine-raspbian-wheezy-armhf/2/console

Hey there,

CuraEngine is awesome. I've been looking at the various config settings available, but I'm unable to work out where the nozzle size is defined.

I figure, if anywhere, it's gonna be in these two settings:

config.extrusionWidth = 350; //(0.35mm) Is this nozzle size, or wall thickness?
config.sparseInfillLineDistance = 100 * config.extrusionWidth / 20; //(20% infill)

Cheers!

The Link to the kleinbottle_Dizingof is broken. "make klein" and "make testmodels" fails.
"make help" also states the wrong target(robot instead of klein) for slicing the klein bottle.

Support material is too close to cylindrical objects. In some cases it looks like the support lines are actually touching the cylinder. It would be good to have a support distance from object setting and also a distance between support lines setting.

The functions "printf" and "exit" do not belong to the list of async-signal-safe functions.
I guess that a different program design will be needed for your function "signal_FPE".

Sometimes, this happens :

This results in a weak point in the part, and can sometimes create blobs on the outside of the part when unadhered threads get flipped over by the nozzle on subsequent passes. It can sometimes wreck the print altogether.

Perhaps infill pattern should be computed in absolute coordinates? It looks like infill is using coordinates relative to the layer centroid, or something like that.

I down the [Stretchy.stl] from http://www.thingiverse.com/thing:13505
open with Cura...Then the question come:

and the SD card print is failed.So I see the layer in Cura.

Only the first layer is right,then other layer is many point.......

This is a part normally printed on makerbots that will not slice correctly.

http://www.thingiverse.com/thing:13505

Seems like a good object to keep around as a test.

Hello!

I have a question about time calculation during retraction. There are two blocks of code in GCodeExport class

1. Retraction itself GCodeExport.cpp:227

fprintf(f, "G1 F%i E%0.5lf\n", retractionSpeed * 60, extrusionAmount - retractionAmount);
estimateCalculator.plan(TimeEstimateCalculator::Position(double(currentPosition.x) / 1000.0, (currentPosition.y) / 1000.0, double(currentPosition.z) / 1000.0, extrusionAmount - retractionAmount), currentSpeed);
currentSpeed = retractionSpeed;

2. Return after retraction GCodeExport.cpp:189

fprintf(f, "G1 F%i E%0.5lf\n", retractionSpeed * 60, extrusionAmount);
currentSpeed = retractionSpeed;
estimateCalculator.plan(TimeEstimateCalculator::Position(double(p.X) / 1000.0, (p.Y) / 1000.0, double(zPos) / 1000.0, extrusionAmount), currentSpeed);

Both moves are made with speed retractionSpeed. But during retraction the time estimated is calculated with the speed of previous move (actual move of the printhead).
Is it right usage? And does function estimateCalculator.plan() take current position with previous speed? Or is it a bug and both estimateCalculator.plan() should be called with retractionSpeed?

Since the refactor, compiling on debian complains a lot about
utils/polygon.h:78:22: warning: unused parameter ‘unionAll’ [-Wunused-parameter]
and then fails with

g++ -I. -c -Wall -Wextra -O3 -fomit-frame-pointer utils/gettime.cpp -o utils/gettime.o
In file included from utils/gettime.cpp:2:0:
utils/gettime.h: In function ‘double getTime()’:
utils/gettime.h:17:23: error: ‘NULL’ was not declared in this scope
make: *** [utils/gettime.o] Error 1

I don't understand Python and only know C++ program development in Windows.Now i want to change or improve the Cura,what i think is turning CuraEngine into a File handler that can turn the ".stl" file into ".gcode" file.The software that i use is Visual Studio 2012.
Do you think it is practicable?and is it very difficult?Thank you!

Solid and sparse fill lines should connect at the end of every other line. Right now you have a small travel between alternating lines. You should have those travels be an extrusion like in skeinforge. This way you have better bonding to the walls.

If i set the initial layer thickness smaller than the layer height. The first Layer is empty and the print starts with the second layer (layer height + initial layer thickness).

Versions:
Cura: On branch SteamEngine
SteamEngine: On branch master

Let me know if you need additional information. Thanks.

It would be awesome if the print time could be negative (it already made a while ago what you're going to want to print?).
Print time: -2147483648

For example for the hat (found here):
https://www.youmagine.com/designs/wedding-cake-topper

This negative number could be fixed, or is this bug is an awesome 'foresight' feature? :)

Full output:

Loading groom_hat.stl from disk...
Loaded from disk in 0.023s
Analyzing and optimizing model...
  Face counts: 1596 -> 1596 100.0%
  Vertex counts: 4788 -> 800 16.7%
Optimize model 0.004s
Slicing model...
Layer count: 100
Processed all layers in   0.0s
Sliced model in 0.022s
Generating layer parts...
Generated layer parts in 0.005s
Generated inset in 0.051s
Generated up/down skin in 0.079s
Wrote layers in  0.09s.
Wrote 502.3 kilobytes.
Total time elapsed  0.27s.
Print time: -2147483648
Filament: 88

Imagine I set:

initial layer speed: 40
speed: 50
outer shell speed: 20

The speed of the first layers ("initial speedup") will be bad for the outer shell speed because it will go from 40 to 20, I think this is an issue

I think the speed should be the minimum of the "main" speed and the smoothed one

Again, I can do the change and PR this

Printing with ABS Nophead's calibrating model cal.stl from his repo shows the same problem as other slicers do. Internal dimentions are smaller and nuts do not fit.
Nophead:
"I had a look at the source code and it appears to assume all extrusions are rectangular, so the outlines will come out thicker than it allows for, hence why holes are too small."

A few random travels outside the areas that it should. These were noted with the UtimakerHandle model.

Hello, Few days I try slice "http://www.thingiverse.com/thing:21076" "file: applejack.STL" and The support was no generate in back side of The Pony Hat. Can you review this trouble.?

CuraEngine git doesn't seem to do combing any more. When I switch back to the latest release tag, it works again. Could this be a setting on my side, or is it broken? (I switched back both Cura and CuraEngine, so it might also be Cura...)

I have looked at a few source files for your current software. I have noticed that some checks for return codes are missing.

Would you like to add more error handling for return values from functions like the following?

• fopen ⇒ loadModelSTL_ascii
• printf ⇒ print_usage

I am experiencing this problem with high-poly objects. They seem to exceed the maximum size set by the vector, causing half of the object to be loaded into memory, while the other half gets thrown into limbo.

Possible options would be either:
A. Expand memory of the vector
B. Better memory usage (dont use Vector but Array)
C. Create a x64-based version that can use more than 4Gb.

output.txt:

(<type 'exceptions.IndexError'>, IndexError('list index out of range',), <traceback object at 0x04AAC0A8>)
Cura_SteamEngine version 13.06.4
Loading # from disk...
Reading mesh from binary blob with 782664 vertexes
Loaded from disk in 0.109s
Analyzing and optimizing model...
Face counts: 260888 -> 260508 99.9%
Vertex counts: 782664 -> 130249 16.6%
Optimize model 1.063s
Slicing model...
Closing down

First of all:
Great work! Seriously.

Second:
by having just h files you dramatically slow down compilation, as always everything needs to be build. You cannot have .o files in between, which thanks to Makefile would not need recompilation.
From my knowledge, just declaring a function inline is sufficient as optimization, and should be respected.
Also: it makes the code much harder to read, which I just tried. Its quite difficult to get a general glimpse of what is going on, i.e. by looking at the class structure.
Also, the .h usually usually also contains documentation e.g. for doxygen.

I can only estimate how busy you are at the moment, and so am i, but I am willing to give it a shot in converting it to a normal c++ structure.

CuraEngine won't compile since the addition of the time estimate. It looks like it's just missing from the list of SOURCES, so if I add timeEstimate.cpp to the end of the SOURCES line in the Makefile, it works properly.

I expect that exception handling is usually supported by a C++ program. I wonder why your function "main" does not contain corresponding try and catch instructions so far.

How do you think about recommendations by Matthew Wilson in an article?

Would you like to adjust the implementation if you consider effects for uncaught/unhandled exceptions like they are described by Danny Kalev?

It were nice if Brim also included support structures. It is seemingly not the case in 13.06.4

A couple of names like "BRIDGE_H", "SKIN_H" and "SUPPORT_H" are too short to avoid name clashes.
I suggest to introduce a consistent and safer naming convention. Would you like to add your project name as a prefix?

When using spiralize the bottom layers are being put down in a mesh pattern. Its like cura is only laying down every second line.

It makes the spiralize setting useless for vases (where it should shine)..
Is there any reason behind this behaviour? Or is it a bug?

When creating a GCode for a 'sparce' object, support structure may be necessary.
In my opinion too much support is given (Cura 14.01 and before).
To clarify 3 images for a Spring Egg Holder (downloaded as stl file from MyMiniFactory)



As seen, at the top rings only a ring of support is present, which is (more than) enough. At the lower part, more support is printed than necessary and risky to remove.
I would suggest to include an option to bring in structural support which is printed under an angle from vertical, building up from either the buildplate when possible, or from structural items when necessay. Advantages are to have less loss of material, faster printing and easier removal of the support structure.

Hello, Cura Developer,
I appreciate CuraEngine, but I have a question about your License policy. You mentioned
CuraEngine is released under terms of the AGPLv3 License. But you mentioned "in general it boils down to: You need to share the source if you make an application with the CuraEngine." successively.
All kind of Open source License including GPL, AGPL..etc. can not infect Open Source policy without Dynamic or Static LIbrary Linkages. For example, when "A" application using executable program under AGPL via fork( )or system() function, "A" application do not have to open their source because it is separated software.
So it looks like another extraordinary license policy over AGPL.. Really can't I use CuraEngine.exe without source open?(We planned Graphical UI application using slice engine like CuraEngine or Slice3r..etc. It is not web solution.)

I'm not sure if this is a feature so if so just close this issue. (Also is there a forum for CuraEngine discussion, feels wrong to have discussion on the issue list)

When enforcing the minimal layer time option, all moves are tallied up and used to calculate the speed factor used for the layer. This speed factor also reduces the speed of "travel moves", that is moves that aren't extrusion moves. On my prints these moves can move the extruder so slowly that there's ooze dribbled along the way that creates seams and lines in my prints.

GCodePlanner::forceMinimalLayerTime() could just count up the travelTime and extrusionTime separately and generate a factor which only uses extrusionTime. GCodePlanner::writeGCode() could then only use the speedFactor on extrusion moves. It is easy to differentiate the two types of moves by their config->lineWidth.

If the current way it handles the slowdown is prefered that's fine. Else, I can submit a pull request for the change.

Hi,

I've tried to build the CuraEngine this morning and I'm receiving the following error:
utils/socket.cpp:15:23: fatal error: logOutput.h: No such file or directory

after removing the reference there and commenting out the log() call in socket.cpp I'm able to compile it again.

Not sure why logOutput was removed an how the issue is supposed to be resolved so I'm not filing a pull request.

Hello,
I guess you've already seen a Makerware raft, it adds a filled layer of plastic before printing the part:
http://www.mak3r.com/wp-content/uploads/2013/06/makerware2.jpg

Do you think this would be doable in CuraEngine?

Hello.
I'm try use of CURA for part with self made support cube.
Between support cube and model, present space in one layer height for easy remove support cube.
But CURA wrong detect this one layer space and generates bad shell and infill.

STL file may download there:
http://www.thingiverse.com/download:382510

See puctures

Still trying to print Yoda (https://www.youmagine.com/designs/volume-voronoi-yoda-by-dizingof)... this time at 0.1mm

Now CuraEngine hangs. It doesn't really crash, but it doesn't perform any CPU activity either. I attached the debugger and it seems that it hangs while writing progress info to STDERR.

To fix this, I changed slicer.h:493 from:

        if((getTime()-t)>2.0) fprintf(stderr, "\rProcessing layers... (%d percent)",percDone);

to:

        if((getTime()-t)>2.0)
        {
            fprintf(stderr, "\rProcessing layers... (%d percent)",percDone);
            t = getTime();
        }

I assume reducing the progress output was the initial intentian of this line anyway. Otherwise the 'if' makes no sense to me at all.

At least I'm finally ready to print.. (and still was too lazy to read how to contribute here..)

c++ -force_cpusubtype_ALL -mmacosx-version-min=10.6 -arch x86_64 -arch i386 bridge.o comb.o gcodeExport.o infill.o inset.o layerPart.o main.o optimizedModel.o pathOrderOptimizer.o polygonOptimizer.o raft.o settings.o skin.o skirt.o slicer.o support.o clipper/clipper.o modelFile/modelFile.o utils/gettime.o utils/logoutput.o -o CuraEngine
Undefined symbols for architecture x86_64:
"TimeEstimateCalculator::plan(TimeEstimateCalculator::Position, double)", referenced from:
GCodeExport::addMove(ClipperLib::IntPoint, int, int) in gcodeExport.o
GCodeExport::addRetraction() in gcodeExport.o
"TimeEstimateCalculator::reset()", referenced from:
GCodeExport::updateTotalPrintTime() in gcodeExport.o
GCodePlanner::writeGCode(bool, int) in gcodeExport.o
"TimeEstimateCalculator::calculate()", referenced from:
GCodeExport::updateTotalPrintTime() in gcodeExport.o
GCodePlanner::writeGCode(bool, int) in gcodeExport.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Hi guys,

Can't compile engine on 64 bits architecture with the latest Makefile. What changes I need to do ?

Many thanks

Edit: On 32 bits I get:

build//libclipper.a:file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
Makefile:66: recipe for target 'build/CuraEngine.exe' failed
make: *** [build/CuraEngine.exe] Error 1

before a travel move could use a minimum distance for this travel move.

Also, an seoncd thing on possible improvements would be cool to disable "nitpicking" moves: retract, go somewhere, inject extremely little material, retract, go somewhere else.
It takes sometimes a tremendous time.

The skirt is currently laid down around the build platform contact points of the model. The raft and support material end up printed over the skirt. A large model with small contact points ends up with very little skirt.

I have model stl with self made support lines with 0.4 mm width.
And cura slicer not slice this lines with nozzle size 0.4 mm

STL file
http://www.thingiverse.com/download:329889

Doing dual or triple extrusion the priming tower is too dense causing prints to fail and put strain on printer. The primeing tower is soon taller than the print itself which stops the priming from working due to the hotend being pressed hard against prime tower. When printing a layer with a single colour all 3 filaments are still priming, would be far better for just the filament in use to do a fine layer on tower to maintain it until required.

Printer is i3 with triple extruder. 3 filaments share a single hotend, swapping by massive retraction and then need to purge about 125mm3 to have clear hotend. can use smaller tower with larger prints though being so dense it gets knocked off plate. For a test just did 4mm high basic 3 colour print, priming tower is measuring 5.7mm high for 3 colours, Do acheive triple extrusion am first doing dual merge, then selecting that and doing another dual merge with 3rd colour part.

For the last commits I get the following error when making the bin:

src/gcodeExport.cpp: In member function ‘void cura::GCodeExport::replaceTagInStart(const char_, const char_)’:
src/gcodeExport.cpp:63:30: error: cannot convert ‘fpos_t {aka G_fpos_t}’ to ‘long int’ for argument ‘2’ to ‘int fseek(FILE, long int, int)’
src/gcodeExport.cpp:54:30: warning: ignoring return value of ‘size_t fread(void_, size_t, size_t, FILE_)’, declared with attribute warn_unused_result [-Wunused-result]
make: *_* [build/gcodeExport.o] Error 1

There should be an option to lower the bed temp to a new set point (or a delta of the original set point) after a number of layers, or perhaps even better, a z value in millimeters.

When I set this value it does not seem to have an effect on the number of loops. It could be me but the other settings are working (like skirtLineCount).
Regrettably I cannon currently compile the code with Visual Studio and don't have another tool installed.