This first TFT cost ca 3.- USD and is 0.96″ with 80×160 pixels, 64K colors and what seems like a Half Duplex SPI. What I am looking for in displays are high quality displays with bare-bone adapters only adding connector, PSU and mounting screws. This is the smallest candidate and will be a bit challenging as I can’t hide a Hat behind it. One rule is that the HMI solution can’t extend the panel size, so I need a cable option between this and the GPU board. The entire board is only 24x30mm so this is small.
This is the same display without the bare-bone adapter. One option is that I grab this and add this on the back of my own adapter with GPU, but I have so far avoided this type of connectors. The price difference is marginal. I will look into it.
This cost around 4.- USD and is 1.3″ with a resolution of 240×240 pixels.
I face the same option to either use the adapter or bare TFT on this one. The adapters are however so well done and makes my life so much easier that
The next is this 4″ display with 800×480 pixel resolution as I mentioned before. This uses a OTM8009A controller that is supported in STM32 and several variants exist for ca 20ich USD. They offer SPI or parallel Interface.
I seriously want a 7″ display with minimum 1024×600 pixels, but I have not found anything that that match my criteria yet. I have a 800×480 display for ca 40ich USD, but I expect more 1024×600 displays to pop up soon.
The HMI solution I find most attractive is stand-alone TFT solutions with UART as interface. I have used a few off-the-shelf displays earlier and the concept is great, but I want to evolve this a bit beyon just a stand-alone TFT – I want a complete, plug & play solution.
These displays interface to embedded solutions using a UART. You pre-program the graphics in a GPU and use the UART to exchange data only. This is an excellent solution and concept, but I lack a few components.
- Using a TFT for data input is not always convenient, I often need custom keys and knobs to make up the rest of a panel.
- I don’t always want to pre-load the graphics design, I want an option to download graphics from the embedded system using XML alike formats.
- I want to chose wherever I use Web, PC, Raspberry PI or something else based on my needs without having to program x number of HMI Interfaces.
- Graphics quality must be high!
- And at last, but not least – customization factor needs to be very high.
I have already started a HMI project with a HMI Designer for a Desktop, Raspberry PI, Android or iPad etc. This is still a bit work in progress, but what I want to add is the embedded “HMI Browser”.
This is just an example display – this is a barebone TFT with a dumb adapter that is perfect for my plans and it exist loads of these. I want more options than a single display, but this is a start. The base concept is that I stack a HMI adapter with the GPU behind this – and as the adapter will be a Hat I can add whatever I want to this again.
I will finish my 3Phase/PWM board first, but this is my next project. Completion of a HMI solution for my projects is long overdue!
Working with software is often long hours with invisible progress. In this case I worked on the Edit Control. I actually tried to use a standard Windows one, but decided to make my own from scratch. In effect it is only a few things I use from Qt including their interface to OpenGL.
Edit Control – that can’t be much work right? Actually it wasn’t, but it forced some design changes to get it the way I want it. The picture above show inline editing with no borders.
Having coded C++ for years before learning C# and Java I actually want to implement some of the C#/Java techniques in C++. This is about making things simpler and more efficient to code.
One of the issues is Reflection. In C# you can assign an object to the property editor and edit it’s properties. Doing the same in C++ is much simpler than people think – you simply add a linked list declaring your member variables and voila – you can edit, save xml, read xml with a few simple commands.
Another issue is Events. I often need to call a parent class from a sub-class. Again if the sub class simply have a mapping table that I can set from the parent …
These techniques do however dig into the memory and dynamic side of C++. But, it leaves me with what I want – a HMI without C# or Java around to slow it down.
This picture show a single Gauge on a form to illustrate how HMI Designer & Browser works. In this case we have a rotating needle that needs to be associated with an input value. What we do is to save this form as an XML and include it in a device.
But, we also need to associate this needle with a variable on that device. This is no coding, only a few clicks -job done.
The next that happens is that we start HMI Browser on Windows, Linux, OSX, iOS, Android or whatever. It contact our device, upload the HMI XML and we have a working HMI with a gauge showing the value of the variable we selected.
No coding involved, just a few click & plays on the screen and job done. No more need for hours by hours from expensive C#, Java, C++, HTML5 developers- no more need for specialised HMI/GUI skills – just a few clicks & play.
And I have not even got to the best part yet…
HMI Designer is reaching a state where I can use HMI Designer itself to design some of it’s content. I can do this because the Designer also embed the Browser allowing me to embed XML based HMI specifications. I am not sure I gain anything, but it will be a good test case for the Browser and help driving it.
My previous entry discuss user gauges as a series of drawings displayed on top of each other. Basically that is what any drawing is and I will need some kind of content list, so the easiest way of dealing with user controls is probably to create this content list and allow the user to select on screen what he/she want to use as a new control.
Any control (also internal ones) need a list fo interface and and spec on how these are used. I think this will work out nice.
Stay with me – this has been a deep dive (large job) so once this surfaces things will change.
This is just an idea, but C++ gauge code is basically a set of layers on top of each other. The idea for user controls is to let the user draw separate drawings – this could be visualized as a text tree, but I consider it as a graphics list/tree. The user can then link a drawing to rotate, zoom scroll based on an input value to create value based animation.
This also questions if I should bother with build in gauges at all – an xml based repository can provide the user with gauges that he can use “as is” or copy&modify. It also opens for others to create add-in libraries, which in previous tools have proven to be a key asset.
Using the clock bewel from earlier I want to add a needle (polygon) and a cap as indicated above. I now want to rotate the needle based on an input value.
Rotation can be done by doing the math yourselves and drawing graphics. The drawback with this is that you use the CPU, so what we will do is to use the build in transform that can rotate, zoom and scroll using the GPU.
So in simple words we just assosiace the rotation angle with an input value and a scale. In this case we rotate the needle layer of our drawing. The advantage of doing this is that we could also rotate the scale (not shown) or use a combination of zooming, rotation and scrolling to animate a value.
The circle above is a “Bewel” often used around a classic clock gauge. Drawing this is straight forward as you draw 3 circles on top of eachother as illustrated below.
I will create some build in gauges, but I think the most important gauge is the one you create yourselves. So I will leave you tools to create your own animated gauges and use them as if they where build in – no coding needed!
Getting there. I am actually starting to see the end of initial framework tasks, so we can soon move on to more interesting and visual content. It’s a lot of work to be honest…
I am happy with using Qt as base. It allows me to write C++ which is optional for this task due to performance and Qt have done a great job integrating OpenGL. So far you only see a 2D content, but you will see the difference as we start with 3D gauges at some point. I have done this without Qt both on MFC/VC++, C#, C++/GDI++ and Lazarus, so I know what I talk about stating that Qt carry it’s weight around on graphics.
The Property Editor is a control that allow a group of “properties” (read data variables) to be edited. Rather than making specialized screens you simply list the variables in a TreeGrid and allow each item to be edited using a specialized editor for the data type. It is a quick way of creating an editor and quite common in modern programming environments.
This editor is quite a lot of work since it also require a lot of other editors to be created. You will probably notice that I am starting with the dark theme with flat controls found in Visual Studio & Windows 10. Actually the theme and style is custom and neither Windows, Linux or OSX. The reason is because most applications today want a recognizable company style on their applications that stay the same regardless of what device or platform you use. I start with my own preference.
A custom style means that you need to create everything from scratch because you need to control every color used. I did this by modifying Windows controls earlier and it was basically more work and less freedom than what I do now. It is a lot more work than just using the build in Windows controls, but it is worth it because the result is a high performance graphics HMI with presentation graphics capable to compete with web applications.
The Property Editor is used to edit objects on the design screen, but is also a component that can be used in user applications. All colors & style setting are programmable per component, but default values are fetched from a theme database. You will be able to create your own themes as well as select pre-made themes.