@oliof and all the others:
Release 1.4.0 is out now!
Changelog:
Get it here: https://github.com/seeul8er/RepPanel_ESP32/releases/tag/v1.4.0
@oliof Ah that might be the issue here. I use the rr_connect to get the apiLevel from the Duet. Since the rr_connect is not really required my software is missing that information. I'll figure it out.
The screen saver goes away on touch. That will work properly once RepPanel got a "proper connection". So if I fix the above the screensaver will work fine.
@oliof said in RepPanel - A DIY alternative to the PanelDue with WiFi support:
The serial console keeps running when the screen goes dark.
If I wait long enough, the screen returns for a while, then goes dark again.
That is not a bug, that is actually a feature. The screen saver kicks in after 60s 
I am sorry it does not work right out of the box for you.
On my screen the burger menu works pretty fine. You can also click on the printer status message to open the menu. Usually that is more convenient.
The current release is untested with RRF3.4. It seems like it is not detecting the DWC apiLevel correctly. If you click on the wifi symbol you can see the apiLevel it detected during connecting to DWC. It should be 1 for all firmware versions that do support the object model. If it is detected correctly it will automatically switch to object model requests and things should sort itself out.
Could you post the JSON you receive when connecting to your printer via http://yourprinter.local/rr_connect?password=yourpassword
Release 1.3.0 is out now!
It is the most stable so far. Thanks to fixes for some memory issues, crashes are now dramatically reduced. Because of that I highly recommend upgrading to it. My own ILI9488 runs super stable now.
Changelog:
idf.py menuconfigSo to sum this up a bit:
Curves:
Here is a super convenient way of understanding the differences with all the types of curves. Out of that fact, Bezier curves will require less information in the G-Code file, making them smaller in size. From a computational point of view, I do think that all of the curves are fairly easy to compute and should not cause performance issues on 32bit hardware. While B-Splines and NURBS sure are more complex and allow a more exact fitting of surface points with fewer curves, I think that Bezier curves will do just fine for a first implementation and looking beyond.
Slicing:
I always thought that there is an analytical solution for computing the intersection curve of a plane with a NURBS surface (pretty much all freeform CAD Data is based on NURBS Surfaces). But I am not aware of such an implementation or solution. I did some very basic research on some published papers and couldn't find any in that direction. Usually, they go and find a clever way of determining the area of the NURBS surface that intersects with the plane and then compute and sample intersection points. After that, you do curve-fitting through those points and get the intersection curve as a Bezier, B-Spline or NURBS. Maybe someone else got more info on that.
The script I wrote leaves all the intersection curve computational stuff to a CAD Kernel, so I have no real control over what kind of curve I will receive. That is why I was struggling when receiving bezier curves with an order of 5. If you would write a slicer from scratch you could fit multiple cubic bezier curves instead.
Since the slicing described above is also just an (very accurate) approximation of the surface based on surface points, you could also slice a very detailed STL/3MF the traditional way and then post-process the G-Code in an ArcWelder-Like fashion. That way you could use the robustness of the current slicers, and not have to deal with offsetting parametric curves. Something that I believe is not trivial to get right every time.
Interpreter (RRF):
As stated above: While it is pretty hard to compute the length of those curves analytically, there are numerical solutions that approximate the length. Since RRF needs to linearize (approximate the curve with tiny line segments of a defined length - Marlin uses 1mm by default I think) the curve anyways, one could use that to compute the length of the curve. In that case, you would need to pre-compute the entire move along the curve before actually moving the motors. I am not sure that fits into the current design of RRF.
I wrote an experimental slicing script for doing parametric slicing. Computing the offset curves is too hard in my opinion. Instead you should only make the outer perimeter a parametric curve and discretize the inner extrusions as usual.
The framework i use for slicing will also output bezier curves (converted from bsplines) that are of degree 5 etc. As I see it Marlin/GCode Standard only supports degree 2/3 which is quadric/cubic. This means you would need support for higher degree curves as well.
So the best way I currently see is doing some sort of curve fitting inside the slicer or the Duet. Maybe even assisted based on a parametric slice. Modern CNCs can already do this kind of fitting. I think I read something about it on a Siemens control unit.
@zapta I do have RepPanel running on an improved hardware platform. It is much more stable, responsive and will also allow for longer file paths etc. I might offer a few pre-flashed modules that are ready to use in the future, once I tested it a bit more.
The ESP32 TouchDown also uses the more "unlucky" hardware. The ESP32 WROOM on there is also low in RAM and the display controller causes increased RAM usage because of required colour conversions - it basically has all the flaws of my current hardware design. The new hardware platform fixes most of those issues.
Happy to announce that the new release of RepPanel v1.2.0 is out!
With support for RRF3 Object Model calls via the PanelDue port and DuetWebControl. Unfortunately, the ESP32 WROOM module does not provide enough RAM to support Duet3D+SBC via Wifi, but a wired connection should work just fine. Updated hardware using the ESP32 WROVER module could fix this.
Changelog:
Get it here: https://github.com/seeul8er/RepPanel_ESP32/releases
@fcwilt I checked and you are right. The heater state is consistent. The tool state can then be ignored. I see no benefit for now
RepRap Object model reports tool to be in state standby while it is "off" in DWC.
When powered on the tool state is correctly reported to be "off". Switching the tool heater to active followed by standby and off via DWC, causes the object model to return state "standby" while DWC indicates the correct state "off".
as reported by "/rr_model?flags=d99fn" under "tools" -> "state"
Board: Duet 2 WiFi (2WiFi)
Firmware: RepRapFirmware for Duet 2 WiFi/Ethernet 3.3 (2021-06-15)
Duet WiFi Server Version: 1.26
Duet Web Control 3.3.0
@jay_s_uk Is there something special about the SBC mode? Do you know if the standard WebControl REST:API calls will work there (Object Model return)?
Hi everyone,
I read that in RRF3.4 the support for the old Web-Interface API will be partially removed. I'll see when I find the time to update the code to accept the object model JSONs.
I use RepPanel nearly every time I start/stop a print. Now I'd like to hear from you what are your experiences with the device. Anything that needs improvement? Important features missing?
I just ordered a nicely integrated ESP32 module from China. My hopes are that the additional RAM on that board will remove many limitations we currently have. I am thinking about the max. files per directory, max file length, max path length etc. The additional RAM should also help to remove the random crashes that sometimes appear.
I might also setup a poll to collect some info for future development. I am thinking about ordering more boards in the future and offering them already pre-flashed. That way RepPanel would be more approachable for everyone.
@jay_s_uk Not sure what the issue is there. Does Duet Web Control work with a SBC/Pi? RepPanel uses the same API (the older one though) so it should work just fine. Sadly I do not have a Duet3 to test it.
@JohnOCFII
Yes burn-in can be an issue. I always turn mine off if I do not need it. The idea of a screen saver is not new. I'll look into that.
I do have the same issue with the touch screen. Sometimes I need to click twice. Maybe it's a driver issue. I'll add it to the list.
For the rest: Is there anything else you would like to see with RepPanel? I might find the time to implement some stuff or even get a custom board design working (not sure about that one yet). Feel free to post here or add an issue in the Github Repository. You can also vote for your favourite one.
Feature wishlist:
Changelog:
@zapta I know the touchdown project. As far as hardware is concerned it should work just fine. You will need to re-configure the SPI-Pins (meaning you will need to recompile the project).
I have some ideas on a custom board but found no time to get familiar with electronics design, yet.
@Nellor Nice investigation!
I did not implement a software reset on startup. Maybe the ESP-Firmware does one. Should be no problem adding one additionally.
If you want a quick fix try adding:
esp_restart()
somewhere here. That should not slow down the boot time too much.
@chimaeragh As Sindarius already stated: RepPanel is self contained and runs on the ESP32.
Sadly I do not have the time or motivation to make a port for CNC applications. CNCs require quiet a lot more manual control over the heads position. I also think that because of that a bigger display (coupled with a more powerfull MCU) would be adequate which probably requires a complete rewirte of the code.
@fractalengineer In your case to get it working you will need to write a display driver for LvGL that supports the parallel interface. The drivers from LVGL do not support the parallel display interface as far as I know. The touch screen should work out of the box since there is already a driver available.
@k3lag Thank you for reporting the issue. I think someone already mentioned that. I added the bug to the github issues 
@k3lag I think you might be in luck. To me it is not 100% clear what the "4-wires" are exactly. The current built also does not directly specify a MISO for the SPI. The display offers a "data" connection that could be independent from the SPI to read the TFT data chip ID etc. So just give it a try!