Does Cura always put an M107 at the end of a part?

[aviphysics 9]

I am writing a plugin to optimize the print order in multi-part prints where "one at a time" is selected.

I need to accurately identify the little bit of code that constitutes the transition between parts. I am thinking that I can use the M107 command to identify the transition, but I am not totally sure if I can rely on it to always be there.

Normally it looks something like this.

 

#end of part 1...
G1 X130.14 Y58.50 E466.02564
M107
G92 E0
G1 F2400 E-4.50000
G0 F9000 X130.14 Y58.50 Z38.80
G0 X115.20 Y95.00
;Layer count: 168
;LAYER:0
G0 X116.18 Y95.20 Z0.30
G0 X116.18 Y95.20
;TYPE:SKIRT
G1 F2400 E0.00000
#start of part 2...

 

[Dim3nsioneer 557]

The only case I could imagine where no M107 is written would be the case where the fan is on from the very first layer on. So this might be your test case.

[Daid 306]

https://github.com/Ultimaker/CuraEngine/blob/master/src/fffProcessor.h#L478

It will not add the M107 if the fan was off to begin with, so on a single layer part, or a print without fans enabled you will not get the M107.

 

[aviphysics 9]

What about 'G92 E0'?

 

[Dim3nsioneer 557]

Why don't you just take the comment with the layer no.?

 

[aviphysics 9]

Because I need to grab the transition between parts. There isn't any comment to indicate the start of the transition. It goes strait from the last layer to preparing for the next part, which includes the jog to the correct coords to start the new parts. It would certainly make my code a lot simpler if the end of the last layer of a part was clearly marked, as well as the jog to the start of the new part.

 

[IRobertI 520]

What is it that you're trying to optimize exactly?

 

[Dim3nsioneer 557]

Because I need to grab the transition between parts. There isn't any comment to indicate the start of the transition. It goes strait from the last layer to preparing for the next part, which includes the jog to the correct coords to start the new parts. It would certainly make my code a lot simpler if the end of the last layer of a part was clearly marked, as well as the jog to the start of the new part.

Maybe I missed something but the code in your original post shows that the LAYER-comment marks the G0 transit to the new position. The first print move is denoted by a G1 command.

 

[gr5 2,172]

G92 E0

Seems very safe. This shouldn't happen during a print. And the way Cura works it always goes back to 0mm of filament at the start of each piece.

 

[eldrick 65]

Or you could just read the Z-coordinate of each move, and when it drops (to the baseplate) from one move to the next, that's the start of a new part. Tough to do in a text editor, of course...

 

[aviphysics 9]

Maybe I missed something but the code in your original post shows that the LAYER-comment marks the G0 transit to the new position. The first print move is denoted by a G1 command.

The bit of code I am concerned with is.

M107

G92 E0

G1 F2400 E-4.50000

G0 F9000 X130.14 Y58.50 Z38.80

G0 X115.20 Y95.00

It includes a G0 move to near the location of the next part and a retract. I decided to solve the problem by backtracking from the layer comment to the last G1 command with an X, or Y move (not sure whether or not to include Z in the search).

@Robert,

The purpose is to produce the correct print order for one at a time printing, so that parts can be closer together. Basically, printing parts that are at the front right before parts at the back left. I got a good portion of the code to sort the parts done. I am now starting to work on the code to write the gcode for the parts back out.

 

[Daid 306]

G92 E0

Seems very safe. This shouldn't happen during a print. And the way Cura works it always goes back to 0mm of filament at the start of each piece.

 

It will happen on large prints, as it resets the E value after 10 meters:

https://github.com/Ultimaker/CuraEngine/blob/master/src/gcodeExport.cpp#L246

 

[IRobertI 520]

@Robert,

The purpose is to produce the correct print order for one at a time printing, so that parts can be closer together.

 

Ok. Now, I might just be a bit dense but, wouldn't you have to do that in the source for cura for it to actually do any good? I mean, if you're not happy with the way cura organises objects on the platform, changing the produced gcode seems like the wrong way to fix it? Yes, you might be able to pack things more tightly after the fact but it's still the same number of objects.

Or is the plan to take several different gcode files and stitch them together?

 

[aviphysics 9]

You can increase the packing density by adjusting the size of the head in machine settings. Currently Cura doesn't do a good job selecting the order to print parts. All I am doing with the plugin is reordering the gcode for the parts and adjusting the transition so it doesn't bang into anything when moving between parts.

The reason for doing this is some issues I have had with splitting multi part STL files in order to print one part at a time.

Ideally this would get fixed I'm Cura, but that would take a lot longer to happen. The plugin I can finish in a couple of days.

[Daid 306]

Currently Cura doesn't do a good job selecting the order to print parts.

 

It doesn't? What's wrong with it then? There have been a few minor problems with it, but in 14.03 I ironed them all out.

 

[aviphysics 9]

Try downloading the STL for this thing with all the parts, select "one at a time" printing, and split the STL. http://www.thingiverse.com/thing:148159

When I did it, Cura did not provide any sensible order to printing individual parts. The result is that it takes way more space then is really needed for each part. In order to get it to fit, I had to manually organize the parts, so that the ones at the bottom right would print first.

Even when single files are loaded, as far as I can tell, Cura makes no attempt to prioritize parts by their location on the build platform. It seems to do it by the order they were loaded into Cura.

 

[Daid 306]

Try downloading the STL for this thing with all the parts, select "one at a time" printing, and split the STL. http://www.thingiverse.com/thing:148159

When I did it, Cura did not provide any sensible order to printing individual parts. The result is that it takes way more space then is really needed for each part. In order to get it to fit, I had to manually organize the parts, so that the ones at the bottom right would print first.

Even when single files are loaded, as far as I can tell, Cura makes no attempt to prioritize parts by their location on the build platform. It seems to do it by the order they were loaded into Cura.

 

That... told me totally nothing. It does not tell me what you expected too see, and it does not tell me what you actually got. Except that you did not get what you expected. I knew that already.

I can make some assumptions about what you are trying to tell. But the answers would be "by design" or "problem would be way more complex then you immagine"

 

[aviphysics 9]

Daid,

What I expect is the following. If the exclusion area around the parts are rectangles, then the rectangle need only extend above, below, left and right, to the amount the print head extends to the right and to the front from the nozzle.

It is then possible to sort the parts so that parts where the head would interfere while printing another part are printed first. (for example, if the left side of part A is adjacent the right side of part B, part A is printed before part B.)

It just takes a few lines of code to map which parts will interfere with another and then another few lines to sort them using that hierarchy. I have that part done, so I know it isn't more complex then I imagined.

If you don't get what I am talking about, then maybe once I am done with the plug-in you will. You can choose whether or not to make a similar change in Cura. I am not here to make you do anything. I just found something that annoyed me and I am trying to fix it. Don't take it personally. I get that what I want might be a niche demand that you don't have time to code into Cura.

 

[gr5 2,172]

Try downloading the STL for this thing with all the parts, select "one at a time" printing, and split the STL. http://www.thingiver...om/thing:148159

Which STL exactly? There are 7 or so STLs there. Is it tenall? sixall? sixpieces? eightall? I figure likely one of those 4.

 

[aviphysics 9]

Sixall, though it is not a unique problem to this stl.

[Daid 306]

Daid,

What I expect is the following. If the exclusion area around the parts are rectangles, then the rectangle need only extend above, below, left and right, to the amount the print head extends to the right and to the front from the nozzle.

It is then possible to sort the parts so that parts where the head would interfere while printing another part are printed first. (for example, if the left side of part A is adjacent the right side of part B, part A is printed before part B.)

It just takes a few lines of code to map which parts will interfere with another and then another few lines to sort them using that hierarchy. I have that part done, so I know it isn't more complex then I imagined.

If you don't get what I am talking about, then maybe once I am done with the plug-in you will. You can choose whether or not to make a similar change in Cura. I am not here to make you do anything. I just found something that annoyed me and I am trying to fix it. Don't take it personally. I get that what I want might be a niche demand that you don't have time to code into Cura.

 

That's exactly what the code is doing. It calculates how much room the print takes (it actually uses a 2D convex hull).

Then it adds the minimal size of the head to that, which is the big shadow area you see around each print. Then it makes sure none of the big areas hit the print areas.

This guarantees that you can print it, in a specific order. (as it used the "min head size" not the actual head size) Finally it figures out in which order they need to be printed to print one at a time.

The code for this is in "Cura/util/objectScene.py"

 

[aviphysics 9]

Thanks Daid.

I think I now know why it wasn't working before. I made a profile for printing thin parts, using the height of the nozzle as the gantry height and it radius for the x and y dimensions. Of course, with those +/- x and y settings being equal, your code no longer has a preference for print order.

:oops: Certainly feel pretty foolish that I didn't get what was going on sooner.

I guess just in case anyone else wants to look through some python code, this is the working portion of the project. It was written in Python 3, but I think the only thing that needs to be changed to get it working in Python 2 is switching the syntax of the 'print' statements.

https://drive.google.com/file/d/0B8uLq8bk84WeMXc4dElKaUFsQTQ/edit?usp=sharing

 

[Daid 306]

:oops: Certainly feel pretty foolish that I didn't get what was going on sooner.

 

I'm just glad my code isn't broken :-) and that we got to the source of the issue.