Slic3r icon indicating copy to clipboard operation
Slic3r copied to clipboard

GCode placeholder layer_num contains wrong infomation if two files are printed

Open yurecz opened this issue 6 years ago • 9 comments

Describe the bug The value of the placeholder [layer_num] in the generated GCode for two files while using the custom G-Code in the "After Layer Change G-Code" section in the "Printer Settings" incremented two times per layer change. Expected behavior that the placeholder should be incremented only once per layer. If the generation is done only for a single file with several STL copies this issue does not occur.

To Reproduce Steps to reproduce the behavior:

  1. Add two STL files on the print bed
  2. Add customer G-Code in the "After Layer Change G-Code" section in the "Printer Settings" containing [layer_num] placeholder
  3. Generate G-Code
  4. Open .gcode file in notepad check the value of the [layer_num] placeholder, use for reference the [layer_z] placeholder to figure on which layer you are right now.
  5. The issue here that within the same layer the [layer_num] will be incremented two times, for each file.

3D Model and Slic3r Configuration Export For example, use the following pseudo-code snippet: ;Layer:[layer_num] ([layer_z] mm)

Expected behavior Expected behavior that the placeholder should be incremented only once per layer. Or It is a feature???!!!

Desktop (please complete the following information):

  • OS: Windows 10
  • Version 1.3.0

yurecz avatar Jun 22 '19 20:06 yurecz

@lordofhyphens is this a bug? It should only execute the layer change gcode once per layer, regardless of how many objects are in the print?

curieos avatar Jul 11 '19 19:07 curieos

~~I can't repeat this in 1.3.1dev, I'll switch over to 1.3.0~~

curieos avatar Jul 11 '19 20:07 curieos

Nevermind that, I think I see what you mean now. It is present in 1.3.1dev as well.

curieos avatar Jul 11 '19 21:07 curieos

Looking through the code, it seems like the code for inserting gcode after layer changes is in the wrong function. It's in the PrintGCode.cpp function process_layer, I believe this gets called for every object after a layer on that object is finished. I think this logic belongs in GCode.cpp's change_layer function, from what I can tell this gets called once per layer, regardless of how many objects there are.

curieos avatar Jul 11 '19 21:07 curieos

I would like to do a PR for this issue. I was able to reproduce the problem with the code currently in master.

nwneisen avatar Aug 27 '19 21:08 nwneisen

@nwneisen then do so :)

lordofhyphens avatar Aug 27 '19 22:08 lordofhyphens

I've been looking through the PrintGCode.cpp code and it seems there are two print modes that should be taken into consideration for this. Printing the same layer of each object before moving on to the next layer (OP's case, default?) and printing each object completely before moving on to the next.

For printing each individual object, I would expect the after layer gcode for each layer in the individual objects. When printing all objects simultaneously, I would expect the after layer gcode only after the layer is completed for all objects. I believe the after layer gcode code would need to be moved to the output() method where the different calls to process_layer() are made. I also question if change_layer() should be moved here as well but that may be out of scope of this issue.

Just a sanity check as I get my head wrapped around things. Make sure I'm not way out in left field...

nwneisen avatar Aug 28 '19 18:08 nwneisen

PR #4856 .

I found the layer.id() value would give the behavior expected for non-sequential prints. This should give the behavior I previously described for sequential prints as well. I haven't been able to test with a sequential print due to the two objects being placed to close when using the command line.

nwneisen avatar Aug 29 '19 04:08 nwneisen

inting each individual object, I would expect the after layer gcode for each l

So is this still an issue, or has this been resolved, and this issue is just not been closed yet?

MakerPact avatar Jun 30 '24 19:06 MakerPact