BasicPI

This show a classic label and an associated edit field. Notice that the text “label” and “Text” are not aligned. In my case I force the controls to align to the grid and in this case I get the side effect that these two texts do not align. One solution would be to switch off the grid, adjust the label and switch the grid back on – thay would work, but it would also require us to do this on every label and checkbox etc. So what I am about to do is to add a property called “Text Alignment” and make sure that these align to the same with the grid switched on. All Windows controls contains a property called “VerticalAlignment”, but it don’t work in a consistent way between controls.

This is one of the reasons I use a grid – to make it easy to align controls in size and position and it needs to work straight out of the box so we don’t use extra time on these details. My challenge is however that I will need to force  all Windows components I use. The picture below demonstrate why.

Notice that label and checkbox text are aligned on top, while edit field and combobox text are aligned center. This just look unprofessional and is a detail that will annoy everyone if it is not fixed. This is also a common issue in some GUI designers as it is not the first time I observe the need to sit and adjust this manually. My challenge is that I will need to fix this in my own HMI designer, but also in every target platform SDK.

The easy solution is to just offset label 3 points from top to compensate for the fact that grid space is 20 and font size is less. I would expect VerticalAlignment to do this, but the ressults using that property vary from control to control.

The adjusted result can be seen above – the actual top adjustment needs to be calculated based on font size used. In the final code generated we just add Y + YOffset and the result should be fine. This is basically an adjustment I have been doing manually in every GUI tool I have used – it is usually “solved” with a smalle grid, but using a 10 point grid means things align easy in position and in this case I automate the adjustment that I otherwise would be sitting doing manually.

I just copied text from an earlier blog into my mini text editor for demonstration –  and this works out very nicely. The capability to edit text is usually a dinosourus in these apps, so I am very happy to see that this one actually works out well and are very functional. I need to code up tools to get rich text and images, but I could actually do with this alone. This one is a big win, so I am considering ditching the full view editor – not needed,

Engineering is a lot of try and fail, so it is very nice that some ideas actually work out as planned because I have plenty of those who don’t.

Many of the HMI controls use actual Windows Controls as base. In the example above I draw a simulated design form as a symbol and use various build-in controls to get the result as real as possible. The challenge is that these controls are designed to be in control – not be controlled by a designer – so getting them styled correctly and to behave inside the designer actually is a bit of work.

At the end of the day I probably will need to create a SDK with my own controls for each platform I support. I will look more into that as I start generating source code from BSA.

Looking at the edit fields you also see that the corners are not drawn as a complete line – this is the control and a detail I seem to lack control over.

Another issue is the color of the check box – I can control text color, but not the check box itself etc. This is very classic Windows Build In Controls – that said – I did discover styling capabilities capable of changing more than I believed I could, so might be  afew tricks I need to learn – but, I still think a lot of custom controls will be needed to add features.

Just to prove my point with borders being to dark I encreased them from 0x32,0x32,0x32 to 0x64 and it makes a big difference as you now actually can see the outline of the control. Keep in mind that these border lines are design help, not actual borders on the real Form. In design mode we are more interested in design parameters than exact look & feel – that said it is nice if it is close.

The HMI Designer part is progressing, but I must admit that it is a large project and I don’t always have time to work on it. Finally started to wrap up the Property Editor and styling up HMI controls that still have light style. The example form above got a bit dark and close to the background so I need to visualize the borders a little more.

Upgraded the project to Visual Studio 2022 and intend to make a test port to Avalonia later. Avalonia is WPF for Windows, Linux and Mac with iOS and Android coming. This is open source with MIT license and contain a few components that interest me.

I have complained about QML making design over-complicated in the past, but I must admit WPF also has it’s tweaks. That said I have never regretted moving from QML to WPF – C# integration into Visual Studio makes it worth it and I am exited to learn about what Avalonia can do – later.

This first version will be able to design HMI with a datasource and read/write data from/to that, but it will not be able to do much intelligent processing before we add PLD and the rest. It will however generate code we can continue on. My first datasources will be Modbus, CANbus and some database – I will probably wrap up a SQLite module, and maybe MySQL – lets see.

I recently bought myself a 14″ Asus VivoBook – great laptop for the price. I only have the standard laptop mouse and a single screen on this – which is a reminder that I will need to adapt the user interface for a more – keyboard only – option later. The current interface is dpending on mouse and 3rd mouse wheel which is not that available on a laptop only. Myself I prefer a desktop with 2 screens as a minimum then I work, but the laptop enable me to work more from my living room.

Looking at the example above I typically have five events I need to process:

• Starting the dialog
• Updating the dialog  with data from a datasource
• Three button events.

In reality there will be more, but lets keep it simple – the challenge with a HMI only designer is how do I process those events? I have two options (1) I can generate code where the user add the missing part, or (2) I can add in a minimum of UML State Diagrams, meaning that a HMI only design will have little purpose except for being a milestone. I need to think about this one a little. I do however have a secret agenda because I work on QML from time to time and Qt’s HMI design tend to crash + I want to autogenerate a lot of the code to speed development up. This is why Qt/QML is on my target list.

Don’t take me wrong on QML – WPF/QML is the only two technologies I have found worth working with. QML is very capable and some parts are better than WPF, but I stick to WPF because it is much faster and more productive to work with – that said – my next system will be made in BSA.

BSA is moving on and is getting more advanced on the diagramming side than I actually planned for in this first version, so one option I am considering is to create a free flowcharting tool. I basically only need to wrap up some of the interfaces and add a print/preview option in addition to custom libraries and it’s done.

This screen shows the polygon tool. You click with left mouse button to add edges and with right mouse button to the remove last corner. I am very happy with how that worked out. Drawing polygons with shart or rounded edges is a must for creating custom components for HMI or diagrams. I need to add text fields connected to a property etc, but I am thinking that this is becoming a very nice semi-automated drawing/flow-charting tool on it’s own. I have often tried to find free ones and end up with some tools that are not well suited for diagrams. BSA on the other hand is designed with semi-automatic diagrams in mind.

The diagram above took me around 30 seconds to draw as is. I obviously need to adjust default property content, and yes this is SDL, but if I start creating custom symbols I can draw any diagram very fast with proper automated content.  Adding PScript I can also let users automate content. The usage would be as a free flow charting tool and BSA viewer to assist in discussions. It is worth considering at least. I need to think a bit on the total work-load, but adding customs control- and symbol- libraries add a lot of value and with PolyGon in place it is becoming an easy thing to do.

Process diagrams are also important as it would be easy to let a process engineer draw hes/her own user interface and send it to a SW engineer that links it up in the HMI with little or no extra work. This can be done with other diagrams as well. Using high level diagrams as specifications tend to increase quality, but you need specialized drawing tools or you end up spending too much time on the drawing part.

This actual screen dump from BSA illustrate both User Control and User Diagrams. The diagram to left is a process diagram very common to a lot of industrial control systems. This diagram is the actual, main  user interface in this case. The User Gauge to right is just an illustration made by 3 polygons and a circle on how to create a 3-Way Valve symbol. I need to work on the User gauge function, but this will privide one way to create very powerfully user gauges/interfaces.

The “Function Name” will be replaced by a unique gauge name that is listed in the left toolbar together with build-in tools. As mentioned before – BSA will contain two different tool libraries – one is build into BSA and cannot be changed, the second is user libraries. The build-in tools must be static to ensure that BSA alsways remain functional.

Since we now allow user libraries I have a second issue – what if I save a project and import it to a different computer? The obvious answer is that the saved file must be stand-alone and include either a reference or a copy of the user library. A reference should cause BSA to prompt for installing the required user library and maybe replace missing library components with a “TODO” something. BSA will compile the output checking integrity, so non-functional content should result in an error.

Keep in mind that this will give one way – not the only way – to create user symbols. The usage above have it’s limitations + you can use older user symbols to create new ones etc, but you can also create user content in old, fasion code. One obvious part here is that a user symbol also need an associated property list/tree that the user must edit.

Another challenge is mixture of automated and manually located lines – with diagrams being user interface themselves I need to care about manual control (positioning) of lines.

Also notice the small dot (above). This is a link connector and is a normal symbol that allows me to connect link lines to show what lines are connected and not. It also gives me manual control of the connect location. I can create 2-Way that rotate, 3-Way that rotate and a 4-Way version of this and I have full manual control of diagrams. I can later add auto-inserion of these to make diagrams a little easier to control – if needed. This can be used on all diagrams. As with all these ideas – I have to draft them and test them in actual usage and it is not always an idea proove to be a good one, but that is engineering for you.