Hi all,
My LCD is just beeping and flashing when it’s connected. I’ve tried the cables the other way around and things look right in the firmware.
Have also tried adjusting the screen brightness knob. Board is a Rambo v1.3
Any ideas?
Solved! I switched the cables around.
Just wondering if i have the correct firmware, all the menus refer to printing, bed heat etc.
Have I got the right one or is it universal?
2 Likes
If it shows the V1 logo at startup, then it is the right firmware.
There are a lot of 3D printing related items, you just have to ignore them. This screen isn’t easy to edit for CNC specific work.
1 Like
You give me ideas for ways to avoid my day job… Bad Jeffe! Bad!
I don’t K has the guts. He’s CHICKEN!
If you do that, make it flagged in EXTRUDERS=0, and there’s a slim chance we could force it upstream. We may have to get out the pitchforks and torches.
1 Like
I think you’re right, he’s not got it any more, sad really, but that’s the way it is…
Oh well
Rob
Don’t go counting me out, yet… I’ve been digging around in the menu code, language files, and configuration files trying to see what I can see. The current state of things is actually not horrific. Not perfect, but not horrific. Of course, I only have a dinky little discount smart controller display, so I can’t see the glorious large displays that you folks see, but from what I can tell by the code, they do a reasonable job of #ifdef’ing out a lot of stuff…
And my plan is to use EXTRUDERS=0 or HAS_CUTTER as a sanity check for any menu modifications I make. The tough ones will be language changes. Going from “Print” to “Job”, or “Printer” to “Tool” or “Machine”. We may just have to live with those foibles for a while…
Besides, I have a conference call in 5 minutes… Bleh…
1 Like
Tell you what, why don’t some of you guys with way more experience using your machines come up with some reasonable suggestions for CNC/Laser-specific menus? Maybe I can put together a “menu_cutter.cpp” that is more suitable for subtractive jobs…
I’ll chip in and help. I am keen to revisit these menu’s as I get frustrated by them,
I have a RepRap full discount display which is not the nice 3.5TFT display.
I’m going on leave for the next week, will have laptop but will not be taking my MPCNC machine with me for some reason.
I’ll have a look as well as I want a better more coherent structure and it can’t be that bad to do (can it?)
Rob
No way. I’m not opening that ball of wax. 
Just delete, delete, delete. And then leave the custom menu in there for new stuff, like home XY, or Z probe, or G92 stuff.
If the $10 screen is keeping you from working on this, I know a guy that will get you one. The trouble is, that will really add to the pressure to do it.
It’s not stopping me, it’s just that I don’t have one, so I can’t necessarily see what it looks like on one. I still get the menus on my little screen.
Now who’s chicken? Yellow-bellied coward! 
2 Likes
Do you know which branch I should work off of (my_bugfix-2.0.x?), or should I fork the upstream Marlin.org bugfix repository?
Guilty. 
(there isn’t a chicken). I will test it for you though if you’d like.
I would probably work off of either bugfix-2.0.x or from 2.0.6. Either from the MarlinFirmware repo. We can smash it into our builds once it is working, or, if it gets merged into bugfix-2.0.x, then we wil get it eventually anyway.
FWIW, the new tfts can operate in full graphics mode just like the full discount displays. You can test it and then switch to working on the touch screen stuff.
In all honestly, this is great, but there is a significant chance the tfts will take over anyway. They are pretty fast and easy to use. That will also not involve a big fork in the Marlin codebase. That’s a big reason I did dive into custom controls for the tft and I didn’t for the Marlin screen.
Well, the TFTs use their own firmware, right? So you’re forking/configuring your own UI code for the TFT rather than forking custom menu code inside the Marlin codebase. Right?
Right.
The screens have two modes. One is the touchscreen mode, where all the decisions about menus, icons, labels are all done on the processor on the screen. The interactions with Marlin all have to be done via gcode over UART.
The other mode is a Marlin mode where the processor just listens to the I2C commands that would normally control a dumb screen, and draws whatever Marlin wants.
So if you were changing the marlin code to function better for no extruders, you could use the tft in Marlin mode to test. But we are already making progress on the code running on the tft processor to make it more cnc friendly. I suspect that in a year, we will all have tft screens. But that is a total guess.
Sounds like the TFTs might be better suited to grbl, with real-time $ commands available. Marlin doesn’t have many immediate commands, does it? Maybe I just haven’t dug around enough… Anyway, it still seems like a useful thing to poke at, even if there is a visible sunset on the horizon. I suspect that the “old” LCDs will be around for quite a while, and it would be nice to have a suitable menu schema for them.
1 Like
I’m going to have to spend some time with it this weekend, but with just code inspection, it looks like the menus are actually in decent shape. Just need to figure out how to get the #defines set right.