Considering LCD/OLED Display Suuport

[bdring]

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.

[mac7988]

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/

[luc-github]

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

[mac7988]

@ LUC-Github good to know. I was about to go buy one haha.

[luc-github]

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

[luc-github]

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

[JamesNewton]

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.

[bdring]

@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.

[JamesNewton]

@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.

[bdring]

@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.

[luc-github]

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

[misan]

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.

[bdring]

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.

[Engineer2Designer]

local display shows who is connected or connected situation? mechanical status? Can help the operator solve some problems in use.

[irshadmgs011]

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

[Engineer2Designer]

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 ?

[irshadmgs011]

@Engineer2Designer Owner license is not mentioned

[Engineer2Designer]

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

[derFrickler]

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.

[JamesNewton]

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...

[derFrickler]

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

[derFrickler]

Maybe taking this as a starting point: https://wiki.shapeoko.com/index.php/LCD_on_GRBL

[JamesNewton]

sigh I don't understand why people can't understand what I'm saying.

1. ESP32 GRBL connected to tablet / cell phone via USB OTG
2. XBOX, etc... ALSO connected to tablet / cell phone via USB OTG
3. 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.

[bdring]

@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.

[JamesNewton]

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.

[derFrickler]

@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.

[petervanderwalt]

Yes! Ssd1306 in spi or i2c (:

Encoder or buttons on a PCF8574 or MCP23008 over i2c (:

[thawkins]

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.

[creisey]

i would love a native LCD on this Setup! for me a 2004 LCD would be enough

[splitn2]

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 !!!!

[mfarabee]

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: 1) 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. 2) 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? 3) 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? 4) Is there a way to force a WCO reply? 5) 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? 6) 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!

[thawkins]

There are a number of bluetooth based grbl control dongle apps available for android phones and tabets, I have used one extensivly plugged into my main rig via an otg usb cable. Rather than rig up extra displays etc, its better to use the one everybody has in thier pocket. I can also buy a low spec android smartphone for as little as $30 here in the philippines, enough to run a single app over bluetooth/wifi. Even the cheapest smartphone has a speaker and camera, that can also be pressed to good use. (Think Octoprint running on a smartphone) Maybe its time to break out the copy of android studio and hack together a remote console app if the existing ones dont cut the mustard.

On Tue, Feb 11, 2020, 02:49 mfarabee, notifications@github.com wrote:

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:

1. 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.
2. 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?
3. 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?
4. Is there a way to force a WCO reply?
5. 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?
6. 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!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bdring/Grbl_Esp32/issues/214?email_source=notifications&email_token=AAADRSPO2O6J6KHP5PAUNJDRCGOR7A5CNFSM4IVWFHQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELJZFII#issuecomment-584290977, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAADRSNUU5BRZGG4Z3LTN2LRCGOR7ANCNFSM4IVWFHQA .

[derFrickler]

@mfarabee That is more or less exactly what i am doing. I am using an ESP8266 (WEmos D1 Mini with TFT Shield) as a small DRO Display. I connected it to the RX/TX of the GRBL_ESP32 controller, as i am not using the USB port. Just uploaded my very simple code, if you want to take a look: https://github.com/derFrickler/grblLCD right now its very basic, just displaying some information and 2 buttons for start/hold. Works pretty good so far.

I already soldered some hardware for a 2nd version based on an ESP32, the ILI9341 2.4" TFT with touch and a rotary encoder, but no time to write some code for it...way to much projects right now.

[mfarabee]

@thawkins, Instead of Android studio, have you looked at MIT App Inventor? It is pretty awesome, You can develop Android apps really quick using Scratch programming. I did this to create different driving apps for some Arduino cars that a high school Robotics team built. They were able to pick it up and develop their own Apps very quickly. For my DRO/Pendant, I do not want to use a phone App, because I want to incorporate physical buttons and joystick. An mentioned above by others, I think you get a better feel and control over a touch screen for jogging. The touch screen is still handy for menu selection and some commands. I am following the same path as @derFrickler. Once I complete it and clean up the code, I will be glad to share it.

[thawkins]

Im a C++/Kotlin/Java/ C# programmer, Scratch is a foreign country to me, so it would not be a comfortable environment.

On Wed, Feb 12, 2020, 08:15 mfarabee, notifications@github.com wrote:

@thawkins https://github.com/thawkins, Instead of Android studio, have you looked at MIT App Inventor? It is pretty awesome, You can develop Android apps really quick using Scratch programming. I did this to create different driving apps for some Arduino cars that a high school Robotics team built. They were able to pick it up and develop their own Apps very quickly. For my DRO/Pendant, I do not want to use a phone App, because I want to incorporate physical buttons and joystick. An mentioned above by others, I think you get a better feel and control over a touch screen for jogging. The touch screen is still handy for menu selection and some commands. I am following the same path as @derFrickler https://github.com/derFrickler. Once I complete it and clean up the code, I will be glad to share it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bdring/Grbl_Esp32/issues/214?email_source=notifications&email_token=AAADRSKVRS4IXVTA24LAKBLRCM5RJA5CNFSM4IVWFHQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELOWMHQ#issuecomment-584934942, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAADRSM6J7SJMEHF4KRNXYTRCM5RJANCNFSM4IVWFHQA .

[mfarabee]

@thawkins Scratch is a form of blocks programming. You drag blocks and connect them to create your code. They use it in teaching kids, but even seasoned programmers can use it :-) MIT App Inventor is really powerful, and easy to do. A couple youtube videos and you will be an expert!

[karoria]

@thawkins, Instead of Android studio, have you looked at MIT App Inventor? It is pretty awesome, You can develop Android apps really quick using Scratch programming. I did this to create different driving apps for some Arduino cars that a high school Robotics team built. They were able to pick it up and develop their own Apps very quickly. For my DRO/Pendant, I do not want to use a phone App, because I want to incorporate physical buttons and joystick. An mentioned above by others, I think you get a better feel and control over a touch screen for jogging. The touch screen is still handy for menu selection and some commands. I am following the same path as @derFrickler. Once I complete it and clean up the code, I will be glad to share it.

If you are using host PC, then I would suggest "pro micro" board programmed with shortcut keys as this board has native hid capability and is cheap. I use 2 of them and covered almost required io. You can even program for rotary encoders for overrides of feedrate and spindle. BTW, I use cncjs in rpi4 connected with grbl_esp32 with usb.

[svalambhia]

Hard button is must, but nice to have some display for current position next line ... this guy implemented HMI+LCD on ESP32 GRBl https://www.youtube.com/watch?v=Wu9etRQ5MxU

[xP373Rx]

This is all you need to add to report the pos to Nextion display.(Between the p373r comments.). Nextion enhanced has also 8 gpios .. i used them to jog.

report.cpp line 702 // Report machine position if (bit_istrue(settings.status_report_mask,BITFLAG_RT_STATUS_POSITION_TYPE)) { strcat(status, "|MPos:"); } else {

ifdef FWD_KINEMATICS_REPORTING

    forward_kinematics(print_position);
#endif
strcat(status, "|WPos:");

}

report_util_axis_values(print_position, temp); strcat(status, temp); //###########################P373R##################################

char out[100];
memset(out, 0, sizeof(100));
char * chars_array = strtok(temp, ",");
uint8_t in = 0;
byte b1 = 0xff;
sprintf(out, "%c%c%c", b1, b1, b1);

while (chars_array != NULL)
{

    char tm[30];
    sprintf(tm, "t%d.txt=\"%s\"%c%c%c", in, chars_array, b1, b1, b1);
    strcat(out, tm);
    chars_array = strtok(NULL, ",");
    in++;
}
strcat(out, "\r\n");
Serial.print(out);
//###########################END P373R##################################

// Returns planner and serial read buffer states.

https://www.youtube.com/watch?v=vxQ5UpJoltM

[gitzixuan]

@xP373Rx， Is there more open source and case information about Grbl_ESP32 all operations using Nextion? I am using Nextion, but there are many problems with Grbl_ESP32, I hope there is more information to enrich him.

[atrejo]

Consider using the common and cheap arduino uno tft shield: TFT LCD, 2,4" 320x240, Ultra HD, ILI9341, Arduino Mega2560 UNO R3 https://a.aliexpress.com/_m0wQJVD

[xP373Rx]

That is not SPI it is paralel. Uses way to much pins like 10 or 11

http://www.lcdwiki.com/2.8inch_SPI_Module_ILI9341_SKU:MSP2807 i use this one on my esp32 radio it is spi and has sd card slot +touch. Cosos 12 bucks or so.

[Gaab88]

This is all you need to add to report the pos to Nextion display.(Between the p373r comments.). Nextion enhanced has also 8 gpios .. i used them to jog.

report.cpp line 702 // Report machine position if (bit_istrue(settings.status_report_mask,BITFLAG_RT_STATUS_POSITION_TYPE)) { strcat(status, "|MPos:"); } else { #ifdef FWD_KINEMATICS_REPORTING forward_kinematics(print_position); #endif strcat(status, "|WPos:"); }

report_util_axis_values(print_position, temp); strcat(status, temp); //###########################P373R##################################

char out[100];
memset(out, 0, sizeof(100));
char * chars_array = strtok(temp, ",");
uint8_t in = 0;
byte b1 = 0xff;
sprintf(out, "%c%c%c", b1, b1, b1);

while (chars_array != NULL)
{

  char tm[30];
  sprintf(tm, "t%d.txt=\"%s\"%c%c%c", in, chars_array, b1, b1, b1);
  strcat(out, tm);
  chars_array = strtok(NULL, ",");
  in++;
}
strcat(out, "\r\n");
Serial.print(out);
//###########################END P373R##################################

// Returns planner and serial read buffer states.

https://www.youtube.com/watch?v=vxQ5UpJoltM

Hi!

Could this solution also be used in Fluidnc?