"Layer change G-code" layer_num placeholder out of order #2634

Closed
forrestp opened this Issue Feb 5, 2015 · 4 comments

Projects

None yet

2 participants

@forrestp
Contributor
forrestp commented Feb 5, 2015

I'm having some issues with the layer_num placeholder in the custom layer change g-code. When support is enabled, the layer_num outputs are duplicated and out of order. When support is disabled, everything works great. I can work around the duplication but not the incorrect ordering. I confirmed the issue exists on both windows and linux for versions 1.1.7 and 1.2.6

Details are below. Rather than post the entire gcode file, I used grep to filter the file so that only lines containing "before layer" remain. The ordering of the lines is preserved.

Config: Start with defaults, add "; before layer [layer_num]" to Before layer change G-code and enable support material

STL: calibration_cubev2.stl

Versions:

  1. Windows 7 w/ Slic3r 1.1.7
  2. Windows 7 w/ Slic3r 1.2.6
  3. Ubuntu 14.04 w/ Slic3r 1.1.7
  4. Ubuntu 14.04 w/ Slic3r 1.2.6

Filtered output gcode without support (Win7, Slic3r 1.2.6 GUI):
; before layer 0
; before layer 1
; before layer 2
; before layer 3
; before layer 4
; before layer 5
; before layer 6
; before layer 7
; before layer 8
; before layer 9
; before layer 10
; before layer 11
; before layer 12
; before layer 13
; before layer 14
; before layer 15
; before layer 16
; before layer 17
; before layer 18
; before layer 19
; before layer 20
; before layer 21
; before layer 22
; before layer 23
; before layer 24
; before layer 25
; before layer 26
; before layer 27
; before layer 28
; before layer 29
; before layer 30
; before layer 31
; before layer 32
; before layer 33
; before layer 34
; before layer 35
; before layer 36
; before layer 37
; before layer 38
; before layer 39
; before layer 40
; before layer 41
; before layer 42
; before layer 43
; before layer 44
; before layer 45
; before layer 46
; before layer 47
; before layer 48
; before layer 49

Filtered output gcode with support (Win7, Slic3r 1.2.6):
; before layer 0
; before layer 0
; before layer 1
; before layer 1
; before layer 2
; before layer 2
; before layer 3
; before layer 3
; before layer 4
; before layer 4
; before layer 5
; before layer 5
; before layer 6
; before layer 7
; before layer 6
; before layer 8
; before layer 7
; before layer 9
; before layer 8
; before layer 9
; before layer 10
; before layer 10
; before layer 11
; before layer 12
; before layer 11
; before layer 13
; before layer 12
; before layer 14
; before layer 15
; before layer 13
; before layer 14
; before layer 16
; before layer 15
; before layer 17
; before layer 16
; before layer 18
; before layer 17
; before layer 19
; before layer 18
; before layer 19
; before layer 20
; before layer 20
; before layer 21
; before layer 21
; before layer 22
; before layer 22
; before layer 23
; before layer 23
; before layer 24
; before layer 24
; before layer 25
; before layer 25
; before layer 26
; before layer 26
; before layer 27
; before layer 27
; before layer 28
; before layer 29
; before layer 28
; before layer 30
; before layer 29
; before layer 31
; before layer 30
; before layer 32
; before layer 31
; before layer 33
; before layer 34
; before layer 32
; before layer 35
; before layer 33
; before layer 36
; before layer 34
; before layer 37
; before layer 35
; before layer 36
; before layer 38
; before layer 37
; before layer 39
; before layer 40
; before layer 41
; before layer 42
; before layer 43
; before layer 44
; before layer 45
; before layer 46
; before layer 47
; before layer 48
; before layer 49

@forrestp
Contributor
forrestp commented Feb 9, 2015

Just realized this is probably due to Slic3r tracking support material layers separately from regular layers.

Would it be possible to have a 'layer_type' placeholder available in the custom layer change gcode fields as well? It could return 'support' or 'object' depending on what type of layer it is. That would solve my problems.

@alexrj
Owner
alexrj commented Feb 15, 2015

Yeah, that's because support layers have their own number. Maybe the right thing is just to have a single progressive number as the user would expect...

@alexrj alexrj added this to the 1.2.7 milestone Feb 15, 2015
@alexrj alexrj added a commit that referenced this issue May 3, 2015
@alexrj Bugfix: [layer_num] was out of order because of support material laye…
…rs having their order numbers. Now we use a unique continuous series. Includes regression test. #2634
63af442
@alexrj
Owner
alexrj commented May 3, 2015

Fixed! Thank you.

@alexrj alexrj closed this May 3, 2015
@alexrj alexrj added the Fixed label May 3, 2015
@forrestp
Contributor
forrestp commented May 4, 2015

Thanks for fixing this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment