Full Graphics LCD Controller - Display Enhancements

The RepRap Full Graphics LCD Controller has information screen space for three extruders when the Robo generally uses only one. To make better use of the screen space, the layout has been redesigned and a few useful features added.

The redesigned information screen layout shows the new features.



SD Card Inserted : Shows if an SD Card is recognised (icon displayed) or not (icon outline only)

SD Card % Complete : When printing from SD Card shows the percentage of the total gcode file which has been printed. This percentage is calculated as (Bytes Read)/(Total Filesize in Bytes) and is used as a rough indicator of the remaining gcode required to complete the print. The progress bar below is displayed using the same calculation method.

Endstop Status: For X, Y and Z displays whether the physical endstop is triggered (white background) or not (no background). This information is useful mainly during startup/maintenance.

Filament used : Displays in centimeters the total filament used since the extruder was reset (G92). This filament used value is derived from the extruder position and is very accurate (including if the flow rate is changed). Note that the extruder must be in absolute mode (G90, M82) which is the default.

Estimated Time to Finish : The estimated time to finish (ETF)is displayed (and sent to a host PC) after the print has been in progress for over 5 minutes. The ETF overwrites the LCD message line and sends the ETF to a host PC every few minutes. The ETF is based on the filament used during the print time elapsed so far and the total filament required to complete the print.


More details and the updated firmware files are in the attachments.

As always suggestions for improvements very welcome.


EDIT : I have just realised there is an issue with some slicers inserting "G92 E0" resets into the gcode at various points. For example Cura inserts a G92 E0 when the E value is over 10,000. Apparently this is being done to avoid rounding errors in the gcode.

I have deleted the downloads as I need to make some changes to take account of the resets.

 

drandolph,

This error is because the CUSTOM_MENDEL_NAME you have defined for your RoBo in configuration.h is too long for the LCD display.

The maximum length is 13 characters when you are compiling Marlin in English. The reason is that " ready." is added to the end of the custom name and the total length of the custom name + ready. has to fit across the LCD width. For other languages, the max custom name length may be a little longer or shorter depending on how "ready" translates to the other language.

// Define this to set a custom name for your generic Mendel,
#define CUSTOM_MENDEL_NAME "xxxxxxxxxxxxx" //robo

 

Doh! I have included the mod for triggering a filament change if there is a high on Pin 44. This mod was to support an external filament monitor.

I will go back and mod the zip file. In the meantime you can either connect pin D44 (Ramps AUX-2) to ground or comment out this code in Marlin_main.cpp

if (digitalRead(44) == HIGH) { // check filament monitor alarm pin
if (FC_Flag == false) { // not already triggered ?
enquecommand_P(PSTR("M600")); // trigger a filament change
FC_Flag = true; //
}
} else FC_Flag = false; // reset for next alarm

 

The end stop notifications show what each Arduino end stop digital pin sees ie it is a hardware indicator which is what is needed when troubleshooting.

The Z position is useful as an indicator of the layer being printed. But I agree the X and Y are not very useful and could be replaced during a print.

This is what I had in mind when I mentioned cycling between extruder status displays as a future enhancement. This is very easy to do and can be extended to up to the number of extruders defined in configuration.h.

This is a Marlin design "feature". The Time to Finish will overwrite this message or you can use an M117 in your start up gcode

At one stage I considered cycling through a number of status message types on the bottom line of the LCD. Very easy to do - but I just put the idea aside while I got the time to finish function working to an acceptable level of accuracy.

There is a gcode to do exactly that M300 - put it in your end gcode. Some 3D users have actually written gcode "music".

This can't be done as the firmware does not know the total size of the file when printing from PC. The firmware would have to be told the file size using a gcode as I have done for the total filament.

Another Marlin design "feature". It is actually quite difficult in Marlin to know when a print starts or finishes. You have to kinda infer the start or finish from other information - but it is still not always clear whether there is a print in progress or not.

 

I have just realised there is an issue with some slicers inserting "G92 E0" resets into the gcode at various points. For example Cura inserts a G92 E0 when the E value is over 10,000. Apparently this is being done to avoid rounding errors in the gcode. However this makes it more difficult to keep track of the total amount of filament used.

I have deleted the LCD display modification downloads as I need to make some changes to take account of the resets.

 

Should be getting my printer today and won't have a graphics screen for a couple of weeks (budgetary concerns). But I noticed the dogm_lcd_implementation.h in Marlin 1.0.2 has a lot of changes that @Ziggy was trying to implement, including display of the correct number of extruders based on Configuration.h. I took the current Robo firmware from here and replaced the dogm files (all three but likely only needed the implementation file), then recompiled. No errors but I can't test. Has anyone else played with this?

 

This is an FYI about the current Robo/Marlin firmware fork and the Full Graphics LCD Smart Controller. If you replace dogm_lcd_implementation.h from 1.0.2 into the current Robo firmware. Recompile and upload. The Robo appears to work exactly as before with the exception that the display now only shows one extruder and removes the "1" designation as well. I did not read all the code to see what else has changed from 1.0.0.