Proposal for new Plot control

[ImpulseAdventure]

Over time, there have been a number of requests for some way to plot data in one form or another, from temperature plots to oscilloscope graphs. The existing XGraph widget was mainly intended as a quick demonstration of how to create a graphical control but lacks the common features users might need.

At some point following the release of GUIslice v0.16, I would like to provide a more usable component (let's tentatively call it XPlot, though it might simply be a replacement of XGraph).

I would like to get users' input on what they need / want in a plot widget. What features are most important?

• Ability for user to provide a fixed array of data points
• Ability to add a data points at run-time (with incremental redraw)
• Data point range: 16-bit signed (4 bytes per data point if arbitrary X coords)
• If adding points at run-time, wrapping a circular buffer if the buffer is full
• Provide (X,Y) coordinates (arbitrary X position). Unless doing an X-Y plot, perhaps we could require that X coordinates are added in incrementing order?
• Configurable scaling in X & Y directions, ability to auto-scale
• Plot with points, plot with connected lines between (X,Y) points, plot with fill
• Multiple concurrent plots (different colors)
• Draw grid
• Draw axes
• Draw axis / scale labels (though one needs to keep in mind limited space on small displays and inability to render vertical text)
• Is scrolling / panning the buffer important?

What use-cases or examples are people interested in being able to plot?

Other notes:

• To maintain one of the library's primary goals, the storage for the data points would still be pre-allocated (to avoid dynamic memory allocation). It may mean that the user supplies a fixed sized buffer.
• To keep things simple, I think the graph rendering would require a full redraw, and only do an incremental redraw when adding a dynamic data point.
• Given limited program memory for many of the target devices, features would be weighed against keeping the widget relatively lightweight. Perhaps certain features would be controlled via feature enables to allow for some flexibility tradeoffs.

Comments or feedback appreciated!

[Pconti31]

In my opinion two different problem domains exist for plotting.
One real time which I think GUIslice is ideally suited and Charting which I don't think is as appropriate.

My feeling is just that in PC for windows and Linux charts are a solved problem with very large software packages available. Given an ESP8266 or ESP32 supporting HTTP you can even send data up to web server to draw an print charts.

Now real time holding a device in your hand or mounted someplace as a real time display would seem quite useful. The main requirements would be in my mind inputting points (x,y) instead of simply y and allowing multiple graphs each with their own colors. Scaling between min and max points would also be nice.

Scrolling I think would also be high on my List. It should be noted that David Prentice's mcufriend_kbv library supports both hardware and software scrolling and even the software scrolling version looks excellent.

[rvxfahim]

I would love to have a plotting feature. The most important features I think would be to either select whether they want a dynamic or non-dynamic plot (panning vs non-panning). It would be neat to have the y axis automatically incremented if it is a time axis. the extended millis library can be used for this i guess? Or the user can feed the y value also along with the x value. Auto scaling would be great alongside user selectable scale.

[mcarosh]

Hi I encountered a problem with two values inside one graph. It is working but really flickering a lot. In this case it was an additional Settemp-line which should work as an overshoot indication for the actual temperature. But it was really not viewable because of the flickering. I cheated in a way to draw a overlapped line to the graph where the y-values (recalculated according to the display and graph position) were the Settemp-variables. The result was usable because now only the line flickered. Maybe it is possible to add a second variable to the graph function which only updates when a button is pressed otherwise it is constant (to save performance and reduce flickering???) regards mcarosh

[ImpulseAdventure]

Hi @mcarosh -- could you attach a sketch of your issue so that I can take a look into it?

thanks

[mcarosh]

Hi Calvin I have made two example sketches for you The first one is the one where the second line (SetTemp in this case) is added through the "gslc_ElemXGraphAdd" command. The second one is a overlapped line to the graph. The sketches are really simple and uses a MAX31855 sensor board :/ I don´t know if this was really constructive for you??? I also know the "flickering" is dependent to the processor performance but when using the "gslc_ElemXGraphAdd" command, the resolution is only the half of the graphs. This makes the looking of the graph more worse. With the overlapped line I do not lose resolution of the graph and only the overlapped line flickers (a lot). But in my mind/feeling it is the better solution. I don´t know if there is real solution to this problem because of processor performance. But so far really thanks for your efforts and especially for your great work ;) Graph_incl_targetgraph.zip Graph_incl_targetline.zip regards mcarosh

[manoharnayak]

Cant wait for this implementation. I agree with @Pconti31 that a simple real time plotting solution seems to be most relevant.

• multiple inputs plotted on the same graph with both x and y inputs
• style selectable (thickness, color, form (+, -, . etc))
• plotted points could be connected with lines with selectable colour and thickness (and maybe optionally smoothing option where the lines connect to form continuous curves - though this could be a bit complicated...)
• scrolling option when the graph space is fully populated, here the x axis would have to be renumbered with the scrolling

@ImpulseAdventure @Pconti31 Thanks a ton for your great work by the way, I'm really learning a lot and able to use your tool wonderfully so far, and would really hope for it's continued development.. I'm totally new to software and coding, and thus am not yet good enough to be able to contribute to the maintenance of your code, but maybe one day!

Best regards, Mano