Marlin: Is it possible to see layer number on the LCD?

Created on 22 May 2016  Â·  19Comments  Â·  Source: MarlinFirmware/Marlin

Hi,

Is there an option to see which layer the printer is actually printing? We can see the Z height and calculate approximately but it would be easier if we could see the exact number. This could be helpful for debugging a slicing problem on the software.

Thanks.

Question

Most helpful comment

@mylife4aiurr You can use the attached add-M117.sh.gz script to add M117 lines to your G-code.

It looks for the ;LAYER:[0-9]\+ comments and replaces them.
Usage:
./add-M117.sh <gcode_file>
... and will output <gcode>_LCD.gcode

I've only tested it on Linux w/bash 4.3 & Cura 3.3.
N.B. It will overwrite the destination LCD_${file} every time without warning!

All 19 comments

that would be a new feature. please make the feature and submit a PR

Sorry.
Marlin does not, and can not, know about layers. G-code does not know about layers. All what we know about, is moves in z direction. But we do not know about: when a print starts, different layer heights, if we lift the nozzle to just move to an other point, if we are printing in spiral vase mode, ... . There is no way to derive the layer number from the information we have.
The one and only program in the software chain where layers are known about and used is the slicer. Everywhere else the concept is unknown.
With some luck you slicer puts the layer number into the g-code file as a comment.

Is there anyway to have some sort of counter that increases with a g or m code and then have that in the layer change code in the slicer? Sorry if I haven't worded that very well.

Sent from my iPhone

On 22 May 2016, at 11:12, Makaira [email protected] wrote:

Sorry.
Marlin does not, and can not, know about layers. G-code does not know about layers. All what we know about, is moves in z direction. But we do not know about: when a print starts, different layer heights, if we lift the nozzle to just move to an other point, if we are printing in spiral vase mode, ... . There is no way to derive the layer number from the information we have.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

if there is then you will have to make the code and submit a PR

@Blue-Marlin is 100% right.
@brainscan the type of counter you request is not available. But to know the layer number, look at the LCD and divide de Z by your slicer layer height..

A universal counter is not too difficult if it can be forgotten at a reset..

Could be a single g-code
Mxxx C counter-number S set_to_number I ncease D ecrease
without parameters return the number
C defaults to 0
S defaults to 0
I +1
D -1

Where the number of counters could be configurable.

#if ENABLED( USERCOUNTER )
  void gcode_Mxxx() {
  static long counter[USERCOUNTER];
  uint8_t c;
  c = code_seen('C') ? code_value_short() : 0;
  if (c < 0 || c >= USERCOUNTER) {
    SERIAL_ECHO_START;
    SERIAL_ECHOPGM("Counter number must be 0 to ");
    SERIAL_ECHOLN(USERCOUNTER - 1);
  }
  if (code_seen('S')) counter[c] = code_value_long();
  else if (code_seen('I')) counter[c]++;
  else if (code_seen('D')) counter[c]--;
  else {
    SERIAL_ECHO_START;
    SERIAL_ECHOPAIR("Counter[", c);
    SERIAL_ECHOPAIR("] = ", counter[c]);
    SERIAL_EOL;
  }
#endif

now we just need a PR for that

It's not your code's fault @Blue-Marlin but this counter thing is somehow useless..

@jbrazio
Because the first layer can have an other height this noes not always work that simple.
For debugging purposes the counter may be useful.

@boelle
If someone wants do use the code he/she may do that. But indeed its not worth the integration into Marlin.
The next requests would be to have the counter in EEPROM.
The next after that to show it on the display.
And so on.

yep.... i just see it from another angle...

people have gotten used to flodding us with feature requests and expect us to do it.

we are only 4 people official and maybe 1-2 of them can do code

people need to learn that the people that can do code have more than enough on their hands fixing bugs.. they DONT need the noise of an endless stream of feature request

if this dont stop or slow down we will never get bugs fixed

If you are using Simpify3D you can add this post processing command under the scripts tab:

{REPLACE "; layer" "M117 Layer"}
{REPLACE " Z = " " Z="}

This will display layer number and Z height on the LCD display. Not sure if other slicers offer post processing but I am sure you could post process your gcode using your favorite text editor the same way using a find and replace function.

@boelle @Roxy-3DPrintBoard
Asking for features is a thing users always can do.
Discussing features, to see if they make sense, or ways to implement them, should always be allowed.

Just the coders have to set their priorities.

Coders and project leaders do have completely different perspectives.
Leaders:

  1. Errors that can cause fires.
  2. Errors that can damage the machines.
  3. Errors in the basic print functions.
  4. Errors in existing features || Errors with specific machines.
  5. Errors for special combinations of features or features and machines.
    ...
  6. New features (The priority for new features should be ordered by usefulness - not FIFO.)

Coders:

  1. Do i understand the problem?
  2. Do i agree there is a problem. (Or user or configuration error)
  3. Do i have an immediate idea how to solve the problem?
  4. Do i understand the code of that subsystem enough to search for the problem, to find a solution? (Or do i have to analyse the code completely from scratch.)
  5. Do i have equipment to test the changes, or am i able to communicate reliably with someone who has the equipment?

Supporters again should have an other perspective.
They have to find out what the problem is and have to narrow it down until the coders get an idea where to search for the bug, or the problem is solved (user error, configuration, ...).

@chief-hacker I use Simplify3D, I'll try what you have suggested.
@boelle I also believe that people should be allowed to ask for features. I am not a coder, just a user with some needs. Those needs might be illogical/useless/impossible to implement and nobody is forced to do what a user asks for. I am grateful to all of the coders and project leaders spending thier valuable free time on this project and I understand that you might not be able to/or don't have to answer to all of the posts requesting features, however when you do so, I'd expect a more constructive answer than "Do it yourself".
Thanks again.

In the end of the day I really find this to be a slicer job, even with Slic3r it's possible to add layer debug info as suggested for S3D.

Thank you for your contribution @Drmaestro.

I agree with @jbrazio this is slicer function easily accomplished with the existing M117. Now I just have to figure out how to get Cura to do it ;-)

Did you ever figure out howto make cura do this? I luv it

@mylife4aiurr You can use the attached add-M117.sh.gz script to add M117 lines to your G-code.

It looks for the ;LAYER:[0-9]\+ comments and replaces them.
Usage:
./add-M117.sh <gcode_file>
... and will output <gcode>_LCD.gcode

I've only tested it on Linux w/bash 4.3 & Cura 3.3.
N.B. It will overwrite the destination LCD_${file} every time without warning!

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mpm1396 picture mpm1396  Â·  729Comments

bgort picture bgort  Â·  163Comments

mkeyno picture mkeyno  Â·  167Comments

kAdonis picture kAdonis  Â·  169Comments

thinkyhead picture thinkyhead  Â·  1715Comments