BasicPI

This is an updated drawing of the DataSource concept in BSA. The idea is that easyIPC provide an uniform access method so that the HMI user don’t need to concern himself with how data arrives or are sent. easyIPC have it’s own native transport protocol and network, but must be able to interface to other known protocols and technologies.

Modbus is easy to implement and to well used to be ignored.

CAN/CANopen is a candidate. CAN have multiple protocol candidates, but I have only used CANopen myself. The protocols used in vehicles are often proprietary variants and CANopen is not a good protocol in the first place. It is old and I was told that the first draft was signed in a hurry because someone had a plane to catch.

Database is a subject by itself, but we need to find methods to integrate the most popular ones at least. We also need embedded database operating on small SPI Flash etc.

Memory is RAM/SRAM on your node. BSA itself uses a heavy RAM based database as an example. But, the idea is that the user can design RAM based tables and use them as if they where a Database.

File system can be a hard disk, Flash or SD/TF Card etc.

The main concept here is that a UI control is binded with a variable and the rest is “magic”. In the first version of BSA I will focus on HMI design so the DataSource will need to be coded maually outside BSA, but as we move on we will be able to add logic to DataSource events as well.

One important aspect is that a user who insist on using Modbus registers directly must be allowed to do so. He/She should not see the difference. This is straight forward as long as the source is one the local computer, but a bit more complex as we introduce a network. But, this is easyIPC’s problem as it need to support “Modbus over easyIPC”. The same goes for CANopen and other protocols even lower layers of easyIPC.

The drawing above show the classic Raster Graphics where the drawing is done directly on the screen by a CPU. This is how classic Qt and C#/Forms works.

The drawing below show the same with WPF/QML involved. The code (or QML/XAML) will in this case create and object that we can manipulate from code, but drawing is done by the GPU. This causes some changes moving from raster to GPU graphics as you only can manipulate the object through commands.

The diagram above show an actual PolyLine on a diagram – or more correctly two lines. Drawing shapes you get automatic hit test support as the mouse moves over the line, so only a few commands was needed to implement a Line Move feature. The chellenge was more that a line with thickness 1 was hard to hit, so I cheat and put an invisible line with thickness=10 above. This works perfect and it was straight up moving on scrolling and zooming. I still need to add joint markers so the user can do more than move, but this one amazed me of how easy it was. I do pay the prize of drawing secret lines, but the advantage is that I can set color and transparancy=50 (as above) then mouse hit – it is actually very cool.

This first picture show the Dark Theme version made with QML, while the second show the Light Theme version made with WPF. The Light images are not all there yet, so I need to work on those. I am getting there with the light version as well. I decided to ditch TreeView and make a copy of the QML Tool Tree in WPF. Dead easy and I have far more control of what I am doing. Images are a lot of work tbh.

The WPF based version of BSA is getting there. It don’t look as cool as the QML version (yet). The reason I am avoiding Dark Theme is because I want to dig more into BSA functionality and avoid spending time on controls like the scrollbar’s for now. Usage with scrolling and zooming is in place, so I need to figure out the tab’s and multiple diagram bars next. Scrolling on this is not as cool as on QML (yet) – QML have a feature that it accellerate and deaccelerate so the scrolling feels more alive. Scrolling on WPF is by default the same old stepping – I probably have to add the animation from QML myself – no idea yet..

I would like a cooler looking scrollbar, but I use ScrollViewer 3 places and the scrollbar belong to this – I did not code a line to get scrolling correct. I fear I have to re-write a few controls to get back the cool QML scrollbar’s, but that’s nothing compared to all the QML controls I had to fight.

QML vs XAML is basically very much the same with different syntax. But, XAML is better integrated with C# and this is where productivity hits you hard. And to repeat myself – on WPF I can get a 3rd party library to deal with dark Theme.

Drawing performance ? I don’t know – looks pretty much the same so far. That said I did this app with good results in both Qt and C#/WinForms as well. WPF have many ways to do graphics so I am still reading up and testing to understand what is the best path. I can get away with any of them, but as I later will build more performance hungry controls I would like to understand their impact, pros and cons before I do to much of the graphics itself. It is also a 3rd party component “WritableBitmapEx” I want to try out. Fun for days to come.

Once I have my mind settled on graphics and how to draw optionally I will start on the drawing engine and draw more than just rectangles. But, this is pretty cool taking into account that this is ca 3 days work to get here so far. Keep in mind that what I am doing is one of the more complex graphics applications in terms of user interface. I struggled more than a bit with this on QML and it has so far been much easier on WPF – without dark theme that is.

The plan for the QML version was to focus on HMI first. The main reason was (and is) that HMI have become so over-complicated. You need to dig deep into technology like QML or WPF and many embedded developers simply do not have the time or skills needed to do this – neither should they need to. Making a HMI with a few gauges is hardly rocket science IMO.

One of the concepts in Plain and BSA is that you develop distributed system, not a single application or device. Meaning that state diagrams and logic can relate to a list of modules that are located either on HMI, on some server or a device distributed in a network. Both PLD and UML State Diagrams support this.

To enable this we will need to maintain a list of modules. A module is a functional module where you decide where you want this located by simply selecting platform from a list. This also means that you with a single click can move modules between platforms. Obviously we also need a definition of Nodes so we can describe the system we develop and a target platform selection – the later is static, build-in for now. It get a bit complicated, but the concept will save a big bulk of development hours by reducing complexity for the developer.

And here comes the trick called RPC (Remote Procedure Call). If PLD make a function call that call will need to adapt to wherever the module is local or on a remote node. If a function is local you simply make a standard local call, but if a function is remote it needs to convert into a message that is sent and wait for response (or timeout). The developer need to be aware of this, so function calls needs to be enabled for RPC as they are called.

Module is the key here because this also means that the repository needs to be structured around modules as the root component – something that goes hand in hand with how Plain is designed and works well for all other target languages.

Another level that is BSA specific is that we need to be able to load multiple projects. This will enable BSA to copy modules between projects or use library projects. Now this creates a new requirement as we need to keep track of dependencies between projects.

Going back to the discussion wherever I should use WPF or QML I think the discussion above tells it all. I have only worked a few days in WPF and are straight back into BSA functionality rather than HMI “How To”. Integration between XAML and C# is much easier to deal with than fighting the complexity of QML. That said I still miss some of the good things about QML so it is not a black/white discussion!

This illustrate the 4 main components inside BSA. You obviously have the UI part that visualize things on the screen. This is the main and largest part, but you also have Repository, Code generator and Debugger integration that needs to be in place.

One of the reason’s I wanted to try WPF is the Repository/UI integration. In WPF I can just use standard C#, but in QML I had to use C++ and a complex binding to QML/JavaScript that basically took a lot of development time.

Debugger means that once you have generated the code and build/deployed the executable you can run it and step though logic and set breakpoints etc from BSA itself. BSA will actually be the tool you develop in unless you need to get your hands dirty with smart source code modules.

Repository is basically the project database either in JSON or XML format – I like JSON, but I need to test text etc in JSON. XML might be a safer choise as storage format. The objective of using XML/JSON is that this is basically your source code and as a last resource we need to be able to manually fix this. The UML model inside the repository will be complex as this is a complex tool to make, but I won’t dig to much into those details.

The code generator might be a command line tool that read the repository and generate code.

One part of PLAIN was that we made distributed systems rather than devices, so the code here might be several executables. For now I will repeat the session on focusing on Forms and HMI, but I will return to the more complex parts of BSA later.

These two examples show one of the edit controls I am considering. The challenge with a property editor is that it is an array of labels and values not well suited to edit text needed for descriptions. And just giving it more height as shown above don’t really help. So what I consider is an option to expand the edit as shown below. Even if I just stay inside the control this will be an inprovement. I just have to test as we go.

The compromize to hold the text within the control is easy and can be seen below. This might be combined with a button to pop into a larger word-pad. This was not even hard to make.

I have added the 6 most common object that I will need as well as got a start on the control itself. So far it has been very straight forward. I discovered that you cannot use inheritance with XAML, so these are identical, stand alone XAML objects for now – QML could use inheritance, but in WPF you need to use C# kode more – which is ok. One thing I do not like with WPF is details like the ComboBox and ScrollBar – I have a hard time controlling their colors. On QML I had different challenges with ComboBox so we will see.

Text Editor is one of the reasons I want to make this myself – Text in this case is a multi-line editor and I want to show a few lines in the property editor and have a expand button that allow me to show an extended text editor. I had this ca figured out in QML, so I will redo some research on how to do this here.

The next step is to be able to click on a symbol or the diagram and set the property list and fetch it back. I really struggled getting that done in QML, but I expect this will be far more straight forward in C#. As mentioned I am not new to C#, but I am new to XAML/WPF.

The nice thing about C# is that I have several options while in QML I only found one that I did not like. Since I am using C# I can either create a separate binding list for each object or use reflection and attributes. I think I prefer the later, meaning that you just throw an object to the property editor with close to no binding code. Reflection is feature in C# that open for some awesome API functionality.

The QML version of BSA is almost finished on Forms design, but I froze further development until I have tested WPF. I get things working in QML, and I am happy with what I see and experience on the screen. But, I am not happy with how much work it is to get simple things done. I needed to create a QML SDK to be able to generate code for QML, but for BSA itself I want to do the same with WPF before I make a choise on how to continue.

Doing this in WPF is not straight forward either, but one issue that keep kicking me is the complexity of maintaining a repository in C++, QML and JavaScript – it does cost a lot of hours. In WPF I will maintain the repository in C# only – that alone is a huge difference. As for Qt Creator – well it is better than it was, but it is not even close to Visual Studio sadly. The two key issues is Visual Designer that crash with advanced QML and a debugger that only work on a good day. These two account for a lot of hours lost.

At the end it comes down to a long term decition on what is the best toolkit for BSA!