Grbl_Esp32
Grbl_Esp32 copied to clipboard
bdring
Considering LCD/OLED Display Suuport
I am considering adding support for a local display. I am looking into hardware and wiring options that might make sense. I welcome any suggestions.
I think this wired interface should support a display, a few buttons and possibly the SD card. This would allow for a full featured local control or pendant.
One of the criteria I will judge solutions by is what has the least amount of I/O requirements from the ESP32. Ideally it is a single I2C or SPI connection. This rules out a lot of the existing RepRap solutions.
Hi Bart,
I think this is a great idea. I would think something from Nextion. This way if noobs like me want a bigger screen or something different we can configure it. https://nextion.tech/
I have tested Nextion and for me it is not adapted it use serial, specific protocol, - and screen reactivity is less good than a ILI9143 + xtp2046 in spi mode - I droped the devt of it for esp3d the only thing nice in nextion is the IDE for UI design
using I2C oled 128x64 is pretty easy to integrate, several libs working for ESP32, another posibility is TFT with SPI, it use CS + DC + MISO/SCK/MOSI and there are good libs for them and ESP32 also
I am on touch screen development right now for ESP3D, so I did several bench and tests. Just my 2 cents
I have several - even the one with rtc and gpio and you need to do a FW for each resolution so no real gain at the end - and they are not cheap
there is very nice lib to get same level of UI - https://littlevgl.com/ really great but I think for GRBL simple UI would be ok and I2C would fit the needs : like this working for esp 32 https://github.com/ThingPulse/esp8266-oled-ssd1306
for TFT I use : https://github.com/Bodmer/TFT_eSPI
Please consider using USB OTG to an old cell phone or cheap tablet. For a $10 cable, you can have a nice display with any functionality you like without taking up extra pins. If you don't want to write an app, you can use an app like DroidScript to write an app in JavaScript and run it on the cell phone automatically when USB OTG is plugged in. That can also be compiled to an app (small donation) if you want to make a standalone.
Depending on what you have laying around the cost could be as little as zero, and couldn't really be more than a Nextion. Cell phones are available for next to nothing on eBay, etc... e.g. a Galaxy S3 will run you $20. There is one trick to it: You must use a device which will both charge and run OTG on the one USB cable. A list and some other options are at: http://techref.massmind.org/techref/io/usb/OTG.htm
Just as one example (and please keep in mind that any graphics / front panel appearance could be supported, this minimalistic layout was just what I wanted) http://techref.massmind.org/techref/language/DroidScript/BusPirate/index.htm (scroll down for the pictures)
I'm now expanding that DroidScript "app" to support headless Linux boxes (aka RasPi zero) here: https://github.com/JamesNewton/nixPanel
I'd really LIKE to see some sort of generic /graphics/ terminal app instead, something like the UI part of the Nextron, but I don't currently have time to focus on that, and honestly, I'm pretty clueless when it comes to GUI design. But I could imagine something that would work both as a text AND GUI interface. E.g. The ESP32 could say:
Menu: Select Mode
1. Configuration
2. Jog
3. Run Job
Input: mode #
And that would show up just fine on your serial terminal. But if the cell phone / tablet was connected to the same USB port via OTG, and the app was running, it would see the "Menu:" and grab the title, then look for number items and make buttons from them, then grab the text after the "Input:" and if the user pressed button "Jog", it would squirt "mode 2" back up to the ESP32.
Hopefully I'm conveying the general idea: Develop a syntax which works for human interaction on the standard terminal, and also clues in an app to make a control panel. This has the (serious) advantage of NOT requiring a bunch of extra GUI code on the ESP32. And... allowing the user to customize the look and feel and size of the control panel.
There are so many other ways this could be done. For example, when the app starts, it could squirt out a request to the ESP32 (or other device) for information. E.g. "echo $PANEL_SETTINGS" and expect a sequence of descriptors in return which define the layout of the control panel.
Embedded in that would be the description of menus and what string should be sent for each menu selection. As exampled above.
And of status fields and what string to look for to grab a value to update that status on the GUI. E.g. if the ESP32 sends: "LIMIT SWITCH 1 PRESSED" then turn on the "X LIMIT" icon. That might be a string in the PANEL_SETTINGS like Icon: warning @upperright highlight: "LIMIT SWITCH 1 PRESSED" normal: "LIMIT SWITCH 1 CLEARED". Hopefully you get the idea.
Any any number of other standard GUI interface items: Sliders, Inc/Dec, TextIn, TextOut, etc...
Yes, it sounds like it's own project, but I think it could be started with VERY simple controls. Just a few button and status fields. And then it could grow on its own. I'd be happy to help, I just can't start it at this point.
@JamesNewton
The primary reason I have resisted a wired display for so long is that I have always felt a tablet, PC or smartphone is a better choice.
Bluetooth is already supported and offers very high performance. There are several very good applications that are already compatible.
The WebUI also works very well. While the update rate is slower than Bluetooth, there is no need to develop apps for Android, IOS, Windows, etc. If you have a browser, it just works.
USB OTG on a device like the ESP32 is a huge undertaking. I know the newest version of the family may have it, but that is a single core processor and unlikely to be ably to run what we have now.
While I am not 100% sold on the wired display, I could see a rugged and sealed pendant with an old school e-stop and maybe a jog wheel cold have it's advantages. The features are in the firmware, so only one code base is required.
@bdring Sigh. You completely missed the point of my comment. Sorry I failed to communicate effectively as usual.
The USB OTG is NOT for the ESP32, it's for the cell phone / tablet. It allows the cell phone / tablet to be connected to the ESP 32 in place of the PC and provide a dedicated display / interface at much lower cost. You would NOT need to implement USB OTG on the...
Nevermind. If it isn't obvious, there is no reason to keep trying to explain it.
@JamesNewton Sorry I made you sigh. You said "using USB OTG to an old cell phone" Your use of "to" threw me off.
I have used USB OTG on tablets to connect to Grbl many times before. I have had issues with driver availability for tablets for some of the USB chips that come with ESP32 dev modules.
Here I have a cheap chinese tablet integrated into an Inventables X-Controller via USB OTG. I also have video jog controller attached too. I did this about 4 years ago.
but a screen need input so need an i2c keypad also - right ? or a 3x4 key pad 3 wires but means need another wire available
If I understand @JamesNewton proposal correctly, an app running on the phone will send serial commands so no need for I2C. Input would be done through the USB serial to the ESP.
The app can query over the serial the ESP to keep the configuration of info updated on the app too. A bit like PC programs like Candle or bCNC.
I guess the aim here of using OTG instead of Bluetooth would be to keep the cellphone battery charged too. Otherwise, using Bluetooth would work similarly.
You could do the OTG now without any changes to firmware. If you want it charging, you need to leave the controller powered, even when not in use. This is a hardware issue, not a firmware issue. I would suggest a common dual cable with separate charging plug.
If you have it wired, just have it wired for charging power and use the Bluetooth.
These two methods are fully support with great performance. This thread is about a possible firmware solution.
local display shows who is connected or connected situation? mechanical status? Can help the operator solve some problems in use.
I think this is a good option, I want you to fork this repo, add more LCD support, and add more future https://github.com/mstrens/grbl_controller_esp32
I think this is a good option, I want you to fork this repo, add more LCD support, and add more future https://github.com/mstrens/grbl_controller_esp32
LICENSE ?
Can the screen input be changed to the following pin? #define CONTROL_RESET_PIN GPIO_NUM_2 // Uno A0 #define CONTROL_FEED_HOLD_PIN GPIO_NUM_4 // Uno A1 #define CONTROL_CYCLE_START_PIN GPIO_NUM_35 // Uno A2 ... ESP32 needs external pullup user rotary encode
Using serial would allow to use gcode commands for jog, home etc... And grbl reports it's status and pos via serial for the display.
Another minimal option for jog only would be a Wii nunchuk via i2c. It has a small Joystick for x/y jog and 2 buttons for z up/down.
Small note: Another advantage of using a tablet or cell phone for display via OTG (as I suggested above) is that they have the processing power to do visualizations. e.g. you can drop in any of the many open source G-CODE rendering Javascripts and have a nice preview with real time updates based on the position reports (as derFrickler mentions). And since it's all JS you can use the same development effort for the web interface. With a bit of work, you can literally re-used the web interface as a front panel interface. Or re-use parts of it if you decide you need a layout that is better suited to the smaller screen. And... a good USB OTG adapter can support /multiple/ devices so you can plug in a mouse, keyboard, XBOX controller, whatever...
Yes, but that's a different purpose, Real buttons and joystick is way better for jogging than a touchscreen. Don't wanna Miss my pendant on my other machine. https://der-frickler.net/_media/technik/railmill/img_20190824_181457.jpg
Maybe taking this as a starting point: https://wiki.shapeoko.com/index.php/LCD_on_GRBL
sigh I don't understand why people can't understand what I'm saying.
- ESP32 GRBL connected to tablet / cell phone via USB OTG
- XBOX, etc... ALSO connected to tablet / cell phone via USB OTG
- You press the "Real buttons and joystick" and the tablet / cell phone sends the g-code to jog the machine to the ESP32 and it IS "way better for jogging than a touchscreen"... Because I'm NOT suggesting using the touchscreen to...
Am I not writing English?
Key point: NO extra code or IO pins required in the ESP32 to support "yet another thing tacked on" so it can just focus on getting G-CODE and generating pulses.
@JamesNewton Yes, we can understand you. Please try not to be so confrontational.
What you are talking about is already supported. This thread is about something completely different. It will be optional and not conflict with the method you are describing.
My apologies, I didn't understand that this thread was limited to add on hardware only and excluded the existing USB interface. I will say that I don't really get the advantages of that approach, but if it's one you want to look into, I'll unsub this issue and stop pestering.
@James Newton, sorry, must have missed your part about using a hardware controller on the OTG as well. I use that since years with grbl, not on a tablet via OTG, but on a Raspi (1st gen 265mB) with GRBL Controller and UGS, Works fine, but requires settings on the machine running the GCode Sender.
With Grbl_Esp32 i really like the idea of running jobs from SD-Card and just using any device to view the webinterface. Means having the full CNC machine self-contained without and needed configuration on any other machine/device.
Yes! Ssd1306 in spi or i2c (:
Encoder or buttons on a PCF8574 or MCP23008 over i2c (:
In My fork i have added an i2c oled display mainly to display connection information (ipaddress etc). , im using a heltec wifikit 32 which has the display on the package using i2c on pins 4 and 15.
What about a bluetooth connected phone? The are quite a few android apps around to do grbl control over bluetooth for example
https://github.com/zeevy/grblcontroller
Its mainly designed for a standard AVR Grbl with a HC05 bluetooth serial module wired into its rx/tx pins. But given that the esp32 has onboard bluetooth, adding support for it could scratch a few itches.
@JamesNewton , it supports direct otg usb too, so theoreticaly you just plugin an otg lead, plug a microusb to type A into that and fire up the app and it should just work, that would solve your requirement.
Hey I have just compiled this GRBL ESP32 onto an M5STACK module. This module has 3 buttons and an I2C LCD and some gpio pins. Its probably the best prepared wee off the shelf to use as a controller, really tidy. I am building a portable 24 volt battery powered machine and an lcd on it would be ideal. Anyway food for thought guys. www.m5stack.com I just got the basic core unit and a battery module and some relays to play with and I am impressed. I even got GRBL servo to work using the pwm and on the oscilloscope the pwm looks nice and clean. Well done for making such a great package thanks to all !!!!
I would also like an LCD display and ability to control the CNC in a standalone mode (headless). I have this on a 3D printer and it is really helpful to be able to insert an SD card and tell it to run. From what I can see in the GRBL code, the SD reader code has a built in gcode sender, which makes this possible.
Concerns: Have done ESP32 programming and dealing with interrupts, I have great respect for Bart and what he has accomplished. I had the hardest time trying to overcome Watchdog timeouts! I worry about any additional code that may impact timing. If I understand everything correctly, adding LCD would require GRBL to do additional processing (queuing and sending additional commands as well as potentially processing more commands to create displays/ jog/SD functions. This seams like a lot of extra work being pushed in the GRBL processor with unintended consequences.
Suggestions: It looks to me that everything is already in place within GRBL_ESP32. After requesting use model information from Bart earlier, it sounds like the best way for daily interaction with GRBL is through the USB interface. This eliminates many of the timing issues that can happen with Telnet/WiFi or Bluetooth. If the typical "head" of the machine is going to be hard wired (USB), this frees up WiFi and Bluetooth for other functions. The great thing is that USB and the Bluetooth/Wifi can work at the same time. I recommend just using Bluetooth for the "Pendant" or "DRO". I quickly put together something that looks like it is working great. I used and ESP32 connected to a touchscreen (I have a dev board I built that makes this easy). I can then add a joystick, buttons, rotary encoders to create any functionality I want. The great thing is all of the processing is done remotely (on my pendant ESP32) and I just send commands to GRBL via Bluetooth, where they can be queued and processed in the normal fashion. If you are using ESP32 board version 1.04 or later (in Arduino IDE), you can set the Bluetooth as a master and hardcode the GRBL Bluetooth name, so it auto connects.
In Summary: Instead of adding an additional hardware interface, take advantage of what is already there. This is pretty cool because you can build an untethered DRO with almost unlimited capability!
Questions: I do have a few questions that I would like to post here, if that is OK:
- It does not look like GRBL sends generic information (position, status, etc )to Bluetooth without it being requested. Is this correct? It looks like UGS and other controllers must query regularly.
- To find the WPos for the DRO display, I am sending a "?". Is this the correct way to do this? I am currently sending the "?" every 5 seconds, but would need to speed that up. Hopefully once every .5 seconds would not be too much. How does this impact UGS, if it is doing the same thing?
- When I get back a string from the "?" command, I need to process it. I see that sometimes I get WCO inside the string and sometimes I do not. I assume that WCO is only sent if it changes? I also see a lag between when I send a command like G92 (changing WCO) and when I get a WCO that reflects that change. Do I need to do something different?
- Is there a way to force a WCO reply?
- From the documentation, it looks like I can take the WPos and WCO and quickly calculate machine coordinates. I can also use the "$G" command to find other data I may need (what work coordinate system I am in). Is this the right way?
- Do I have any contention issues I need to worry about? Such as with a running program? From accidently jogging? In other words, do I need to limit functionality if something is running (I only plan on sending jog commands for movement)? I will have the touch screen be able to send reset, G92, clear, etc...
Thanks in advance!
