I have been modifying my Marlin code as I find the XYZ detail on the Graphical LCD meaningless for my use.

I much prefer to have the display show the Layer count and the Estimated Time Remaining for the print.

For example : L004/076 e01:12 -- indicates that the printer is busy with Layer 4 of a total 76 layers, and estimated time remaining is 1 hour, 12 minutes.

So far I have this working reasonably well and just need to find a solution to 1 little annoyance :

How to update the LCD display before reading an SD card file.

My method is that once I select a file on the SD card ( void process_commands : case 23: //M23 - Select file ), I then create a boolean flag to tell the sketch to read the SD Card file.

In the next loop of the main loop(), if the boolean is true, then the SD file is read and analysed.

During the read, the SD file is looped and counts the total number of layers ( lines start with G1 and contain 'Z' ) and counts the number of Print Lines ( starts with G1 and contains 'X' ).

My modified code then tracks the line-by-line read of the SD card file, and updates the 'current' layer and print line variables.

So the LCD displays the Layer number data, and uses the Print Lines Conpleted, the Time-since-print-started, and the total number of print lines, to estimate the number of hours and minutes remaining for the print job.

All working great, and I promise to share the code once I have the last problem solved.

The display on the LCD is updating perfectly when the print is running, but the part I have a problem with is the refresh of the LCD display directly after the 'case 23:' and before I read the SD card file.

I find that after I press the rotary encoder button to select the SD file, the top half of the LCD goes blank until SD file has been read and analysed.

Is there a standard command or function call that would cause the LCD to refresh ?

Update :

I have found that the code I have that updates the Layer number and time remaining is in the file dogm_lcd_implementation.h, in the function : lcd_implementation_status_screen

The display message portion of the code looks like this :

sprintf (LCDline1, "Reading SD Card ..");
u8g.setPrintPos(2,37);
u8g.print(LCDline1);

Is it possible that I am writing this code in the wrong function, or do I simply need to find a way to trigger the function ?

The other code that updates during the print job is in that same function and that works fine, so I can only assume that there is a call I am missing that triggers the LCD to update or refresh.

Edited 1 time(s). Last edit at 07/13/2015 06:36PM by DaveOB.

How are you estimating the time remaining? RepRapFirmware has been providing layer counts and estimated time to completion via the web interface for over a year, and via the colour touch screen since it came out. We have learned a lot over that time. In particular, layer count alone provides a very poor basis for estimated print time in the general case. It's ok for something sple.like a cube, bur falls down on more complex shapes. A better measure is the rate of filament consumption averaged over the last few layers compared with the remaining length of filament required. Another approach is to monitor how much of the file has been processed, but that isn't very accurate either for irregular shapes.

Edited 1 time(s). Last edit at 07/14/2015 03:12AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hi dc42

The code isn't perfect, but it givs me enough of an indication.

As an example, I sliced a Marvin keychain model that had 75 layers and the gCode file contains 27226 lines of print code.

Slicer said the job should take 34 minutes

My code said :
At layer 22 after 10 minutes, estimated remaining was 19 minutes = total 29 minutes
At layer 27 after 12 minutes, estimated remaining was 18 minutes = total 30 minutes
At layer 43 after 20 minutes, estimated remaining was 11 minutes = total 31 minutes
At layer 59 after 28 minutes, estimated remaining was 4 minutes = total 32 minutes
after that it remained a constant 'total' until the end of the job, which did take 34 minutes.

Here's the code for the calc that I am using :

( yes, I know it can be optimized a bit, and will do so once I get the LCD refresh sorted out )

// PrintLinesTotal  = the number of lines in the gCode file that start with G1 and contain X
// PrintLinesCurrent = each line read from the gCode file during the printing that starts G1 and contains X
// LayerCountTotal = the number of lines in the gCode file that start with G1 and contain Z
// LayerCountCurrent = each line read from the gCode file during the printing that starts G1 and contains Z

		char LCDline1[20];  // create the LCD line array with the data to be displayed
		LCDline1[0] = '\0'; // clear the line to be displayed
		int DHRP = 0; // integer for estimated hours remaining
		int DMRP = 0; // integer for estimated minutes remaining
		if(PrintLinesCurrent >= 10){ // start calcs after the first 10 lines have been printed
			long CurrentPrintTime=0;
			CurrentPrintTime = millis() - starttime;             // calc the milliseconds that the job has been running so far
			long EMR = (CurrentPrintTime / PrintLinesCurrent) * (PrintLinesTotal - PrintLinesCurrent); // calc the estimated millis remaining
			int SRP = trunc(EMR / 1000);                         // convert remaining millis to seconds remaining for print
			int MRP = trunc(SRP / 60);                           // convert seconds to minutes remaining for print
			if(MRP < 1) MRP = 1;                                 // keep the value at 1 minute for the last few layers when the actual value < 1 minute
			if(PrintLinesTotal == PrintLinesCurrent) MRP = 0;    // switch to zero when all lines printed

			MYSERIAL.print("PrintLinesTotal = ");
			MYSERIAL.println(PrintLinesTotal);
			MYSERIAL.print("PrintLinesCurrent = ");
			MYSERIAL.println(PrintLinesCurrent);
			MYSERIAL.print("CurrentPrintTime = ");
			MYSERIAL.println(CurrentPrintTime);
			MYSERIAL.print("EMR = ");
			MYSERIAL.println(EMR);
			MYSERIAL.print("SRP = ");
			MYSERIAL.println(SRP);
			MYSERIAL.print("MRP = ");
			MYSERIAL.println(MRP);
			MYSERIAL.println("-------------------------------------");

			DHRP = trunc(MRP / 60);                              // how many hours in MRP remaining for print
			DMRP = MRP - (DHRP * 60);                            // calc remaining minutes after subtracting DHRP hours
		}
		sprintf (LCDline1, "L%03d/%03d e%02d:%02d", LayerCountCurrent, LayerCountTotal, DHRP, DMRP);
		u8g.setPrintPos(2,37);
		u8g.print(LCDline1);

Edited 1 time(s). Last edit at 07/14/2015 04:34AM by DaveOB.

I have a question, As I understand it you are parsing the gcode on the SD card first to determine the number of layers by incrementing a count every time you see a Z move in the gcode. Would this not fall over when the slicer option to do a retract using Z as well is enabled as this will create many more Z movements that are not layer changes.

Can I suggest that you rather do a current height vs total height display, this will just require you to look at the last Z adjustment at the end of the file and then use that as the final height?

Thanks atunguyd

You are correct in your understanding of the method I have started using.

I suppose that it would be just as easy to count only positive Z moves, or as you suggest Current-Z vs total height.

It should be easy to customise as I have just about finalized my code and almost ready to start compiling a step-by-step list of the mods that I made.

But first I need to figure out how to get the Graphical LCD to refresh and display a 'busy reading SD file' message before I start parsing the gcode file, as that seems to take up to a minute to do with the file I am testing with.

No you will need to count positive and negative Z moves then, remember the retractions are a up and then down, so I guess if you sum up the Z moves and add them algebraically you will have the total number of layers. This however becomes difficult with gcode that is absolute as opposed to relative because a retraction would be a z move to say 6.8mm then a Z move to 6.7mm. A relative commadn would be Z 0.1mm then Z -0.1mm which I believe is very rare.

Quote
atunguyd
No you will need to count positive and negative Z moves then, remember the retractions are a up and then down, so I guess if you sum up the Z moves and add them algebraically you will have the total number of layers. This however becomes difficult with gcode that is absolute as opposed to relative because a retraction would be a z move to say 6.8mm then a Z move to 6.7mm. A relative commadn would be Z 0.1mm then Z -0.1mm which I believe is very rare.

Thanks.

I am certain there are a dozen different ways to look at this problem, and I am probably going to try a few different angles.

But first I need to get the LCD to display some text in Marlin_main directly after 'case 23:' where the code detects the 'M23' case. This is the point where I am parsing the file but for some reason the LCD does not respond until after the file has been parsed.

I am certain there must be some way to specify the text message to appear at the bottom of the LCD, but I can not see how to make it happen and refresh. It appears that it can not happen from inside the select case code.

Thanks to all for the input.

I have redesigned how I am addressing this problem, and now have a working solution.

As suggested by dc42, I have also added a calculation for the filament usage to estimate the time remaining, as well as a calc based on the print lines.

However, the parsing of the SD file is not viable. It just takes too long ( that's why I wanted the refresh of the LCD screen ) with over a minute to parse the gcode file for a simple Marvin model.

The new method gets the data in about 1 second.

I have a complete working solution and am busy with the last final test. Once that is done, I will create a new post with a step by step of what I did, and how it works.

If you want to get the Layer number and the estimated time remaining to display on your graphical LCD screen, then it may be worth a read.

New post to follow soon.

OK. Detailed the changes in this post :
[forums.reprap.org]