BasicPI

This table shows the planned BSA support. Windows, Raspberry PI and STM32 are primary development targets, but Linux is covered through Raspberry PI and Mac’s will be covered. Other platforms, specially on the BSP (Board Support Package) side will be added.

(1) I am unclear as to wherever it will be practically to support BSA on tablets and Android in general. Making code portable is one issue, but making the designer fit on a tablet with keyboard etc is a different issue.

(2) As per need and available resources.

DataGrid and PropertyEditor is still work in progress, but the same PropertyEditor that is used in BSA will also be available as a component. The same goes to the DataGrid. DataGrid is a smaller grid designed to use inline edit. I will also use a virtual grid designed to visualize huge amounts of data.

I am not sure about “DataSource” yet. A DataGrid will need a connection to a data-source. This can be manual, a ram table, an external XML table or maybe a SQL database etc. The common way to do this is to provide an invisible componente “DataSource” that is reffered by components vidializing/editing the content. I will do something similar. It makes sence to have this as a separate component – I think.

PropertyEditor is excellent for editing a single row in a table or an object (class). If you have a SQL database the two components shown would provide a raw editor in no time. This alone is worth gold because it allow you to quickly create GUI interfaces to databases regardless of what format they are in – and most applications actually have a database or internal data-tables and structures of some sort. BSA also includes classic ER Diagrams to be able to support SQL based Relational Databases that still are very common.

With the current speed I am hoping to have an Alpha version in June 2021 – covering HMI only.

This is the beginning of BSA’s property editor. A property editor is a specialized grid that can edit objects and is very common in dveloper tools. Rather than produsing hundreds of IO diialogs you use a generic editor that you pass a list of variables. The way this will work is that it show the properties for the visual component you have selected. Having one of these in your arsenal is a powerfully tool in many applications.

Doing this in QML provided some learnings – firstly I have done this in more classic GUI solutions and you have to think completely different with QML. But, it was actually very easy to do this thought it represent a bit of work. The common trick is to use the standard edit components located in the cells at right, but I got a surprice…

I have a DataGrid as well and for each cell I added all edit controls and just made the one I used visible – big mistake – QML handled it, but starting the grid became slow because you multiply the number of components that needs to be initialized by 3 dimensions. While the GPU’s make everything look easy and you can get away with a lot of stupid code – you also must be very aware that there are limits. And one of the is how you pass information between GPU and CPU. If I create my grid large enought it will not load at all and as it grows it uses more time to grow.

My aproach is simple – I am still learning so it is try and fail – in this case I added logic so it only create the components it used + I am very well aware that my DataGrid with inline edit only can handle a limited number of columns and rows, so I can’t use this for massive data visualization – but, that is ok because it will typically be a few columns and rows – my grid handle thousands if I must – which is more than sufficient for this type of usage.

If I ever need to have in-line edit on even larger datagrids I will need to add logic to minimalize the number of components I throw into the GPU. QML actually have a build in mechanism for this that I will be using for Real-Time visualization components. But, it is a bit of work to set this up properly.

The property editor will take me a few days to get right, but it is one of the most important building blocks in BSA itself.

This first picture show a UML State Diagram. I promissed to focus on HMI, but I fancied adding the symbols before I hide these diagrams in the first version.

This second picture show a Plain Logic Diagram. I will walk through the interaction between the diagrams and their usage later. As you can see it is only default symbols as I still lack the property editor. I have also started to get all the fiddly images on place so the system starts to look more complete than it actually is. It is still a lot of work outstanding before these diagrams works the way they are supposed to.

I did earlier write about making a HMI Designer and HMI Browser. The designer is what you see above, while the browser will be a run-time engine that execute these applications. But, I will also add code generators for various platforms. First on my mind is a STM32 BSP and Qt/QML BSP, but I also want to look into Node.js and see if I can use that as a backend for a Web Server etc. Lots of options as this is a tool where you create a specification and later deside how you want to execute that specification.

Another task is that I want to add fron-ends to all my electronics boards and start using this to create control systems – lots of fun ahead.

Qt/QML lack an image designer, but I found that using good, old MSPaint worked out well. I have added tools to support various modeling techniques, but will focus on HMI design and automation in this first version.

It is a graphical GUI designer included in Qt, but good luck getting something out of that. This is what I do not like with Qt – it’s a lot of stuff that simply don’t work very well.

The dialog above is what I get if I try to open my QML code in Designer – the code works well, but Qt Designer is not able to display it or offer a graphical design – and fiddling with graphical GUI design through text only is far to time consuming for my taste – so this is my answer to this – I create my own GUI designer because this is very straight forward.

The reasons why I do this is because I need the graphical coordinates as input into an intelligent code generator so I can automate far more of the HMI application than I otherwise could. The core concept of the HMI designer should be very familiar – you simply draw objects on screen that look similar to the real GUI forms you want – this is just a drawing, but each object have parameters, a name and coordinates + property values I can use for automation.

Based on this I can auto-generate all QML and JavaScript as well as bindings to C++. Work that otherwise would take hours for every dialog can be done in minutes, but I will not stop there. Doing this for Qt/QML is just the start – I can as well do it for C# Core and others. My first target will be QML and I intend to create parts of BSA using BSA.

Auto generating an user interface is actually very easy, but the key is to accept a standard way of doing things that can be repeated. Take a simple edit field as an example – it needs to be initialized, you need to fetch the result and you need to validate the result dealing with wrong inputs – doing this properly is actually a bit of code that is repeated for every user control.

Those of you familiar with C# will know that Visual Studio generate a lot of code automatically to make C# Forms easy to work with – I intend to go further in the interest of dramatically increase productivity – or more exact – reduce the hours I need to use to create advanced HMI solutions.

I have started this designer in MFC, C#, Lazarus, classic Qt etc and it is doable in all of these, but I seriously wanted a technology that gave me easy access to GPU’s and this is where QML is unique. I plan gauges that is hard to do in old fashioned raster graphics because you start using to much CPU power, but they are straight forward in QML + not to mention that I actually can dig into 3D user interface objects.

Dark theme is sadly difficult to do – all the tools require that you either buy a package of controls or do the hard job yourself – QML is no exception. QtQuick controls out of the box have various quality and don’t look the way I want them to, so I ended up creating everything from scratch. But, QML makes that job very easy. I am seriously impressed about how easy it is to do graphic components. I will still be working on basic UI components for a while, but it is progressing fast compared to the hours I can put in.

Desktop-, Web- or Tablet- application? This is the advantage of a CASE tool – I do functional design and let my code generators deal with the rest. I see no reason why my desktop application should be different from my web applications or wise versa.

As mentioned – the first release will focus on GUI and QML because that is what I need the most myself. You might see a first, functional release before summer 2021.

My previous entry talked about coding in QML. I am still on the learning path here, but I am slowly finding my way into QML. It is a steep learning curve, but once you start master the technology it also get easier and the graphical result is the best I have seen so far. It is complex with code in JavaScript, QML, Qt and C++ being combined. The alternative would be C# Core and WPF, but I have yet to learn that.

What you see above is the beginning of the HMI Designer. It does not look like much yet, but I am getting there. I am still planning a HMI Designer and associate HMI Browser to simplify advanced HMI design, but I will not stop there. I have yet to decide if I actually want to use Qt/QML for this as I am still on the learning side of things. As a C++ developer I can control my enthusiasm about Qt, but QML is a technology I so far have liked to work with.

The designers that are part of Qt have never really worked – I fail to understand why they can’t make a proper, visual HMI designer – it is not exactly rocket science. But, well – as you can see I am on my way of making my own. And my reasons have nothing to do with the non-working QT versions – I actually need this designer to be able to simplify HMI design to the level I want since the HMI designer is the first component of a complete system designer. This is about dramatically redusing the work-load needed to create well functioning, advanced systems.

I am using a concept of universal diagrams – the diagrams can include multiple HMI Forms as well as other diagrams like UML mixed. At this point I will focus on HMI design and the code generators needed to generate the HMI part of the system. And don’t worry – you will be able to use this together with whatever GUI system you use be it Qt, QML, C# Forms, C#/WPF etc.

BSA will be using a Repository that basically is a JSON file and the code generators will be script based. Many like Phyton and JSON is well supported in Python, but I also plan a more specialized code generator script – something that I experienced with ca 25 years ago. I will return to that in a different blog entry.

This is Qt Creator 4.12. I have worked with Visual Studio for many years, so every IDE get compared to VS. QtCreator does the job as an editor, but it suck as a debugger. Even STM32CubeIDE that uses the same GDB is far better that Qt Debugger. And working with QML you might want to try Qt’s Graphical Designer – One advice  – don’t bother!

Myself I found it easier to deal with QML through a text editor than trying their buggy Graphical Designer. Don’t take me wrong – I actually use QtCreator on QML. It exist a Visual Studio Integration, but I have yet to see the advantage of that as it is not a full VS integration.

Judgement on QtCreator ? It gets the job done and it’s better than nothing!