BasicPI

Don’t worry – you will hear a lot about the Property Editor. The one you see above is yet a simple one. I am still using string edit for colors, but it works fine due to the nature of JavaScript. JavaScript accept colors in string format by name or #xxxxxxxx. (ARGB format). I will add a proper dialog option for that later – but guess what – I wait for BSA to generate that dialog for me 😊.

The top 3 lines for each HMI object will be standard – a display of what control this is, the local name and the full name – currently you see the full name only. The name of the control is “edit1”, but since this is located on “form1” you get “Form1.edit1” – or more correctly “From1…” since I have a spelling error 😊.

I currently lack a lot of properties here like x,y,width,height etc. I will also need options to expand category trees and sort properties. And well – I did mention specialized edit dialogs.

One of the most wanted is actually a multi-line text editor. I want this to expand using the full width so you get a mini editor and optionally expand into a full window if needed. Adding comments and having proper tools to do so is important.

The Property Editor is important because it enable me to easily and uniformly edit all details of a diagram. The alternative would have been to create dialogs for everything and use double-click etc. With a property editor you only select the component and change properties watching the changes apply as you change them. A Property Editor is however not ideal for every property – descriptions etc is one of them, but you also have information that needs a table presentation. Forms itself need a hierarchy tree so you can see a list of content and control appearance if controls are located on top of each other.

The options I have is to (1) use trees, (2) use pages and (3) use edit buttons where you pop into a specialized dialog. One of the pages I probably need is the event list and bindings for it – not sure – I actually plan an event selector as part of some diagrams, but every form and component are a source of events + how do I handle this before the diagrams are in place etc – I need to think about that one.

I am reaching a point where my illustrations regarding BSA are more and more the real thing. Property Editor is now real so I can start edit the components and add properties. I have a few days work setting up correct properties and then I will deal with saving and loading projects and a few other outstanding issues before I am on to generating code. Or well – don’t worry – I have plenty of work left yet.

Keep in mind that BSA uses Universal Diagrams, so unlike other design tools you can draw multiple things on the same diagram. In the illustration above I have drawn multiple dialogs. Each dialog has a Name, each component have an unique name within that dialog. Each dialog only cares about the component located on top of itself – so it is perfectly legal and beneficial to draw multiple dialogs on the same diagram as I have illustrated above.

Only basic components will be build in as the next, big feature is component libraries created by BSA itself. For example standard dialog boxes, gauges etc – I did decide to use a HMI solution fuled by GPU’s for a reason.

I used to design HMI solutions as a profession some 25 years ago, but never jumped on to the web thing. Watching over Web developers making HMI’s I was stunned about how limited their tools was as I have never understood why web developement needed to be worse than classic desktop development. Since the illustration above is a specification I can easily generate it as a Web page, desktop or tablet design at my chosing – without the developer needing to worry to much about the details except one – screen resolution if you use tablets/phones as target.

Qt will deal with execution on multiple platforms, but I do get an extra challenge using Qt – Print Preview and Printing is far from strate forward with that framework, but I will deal with that later.

A critical component for a HMI Frontend is “Data Source”, meaning where is data loaded and saver. HMI alone is worthless unless it is actually connected to something. This can be a remote Modbus device, a database, simple memory structure, file structures etc. BSA will provide the component, but the user must add the source behind this API in ordinary code. This means that if your GUI display the value of a memory variable you need to put this inside a data source so that the GUI is updated every time you change that variable. This also means that updating the GUI now becomes as easy as setting a variable.

Modbus (as an example) is just as easy – you bind a modbus variable to the HMI and as the HMI write you write to the device and as the device update a variable the GUI is updated automatically.

The only difference between the pure HMI version and the later versions is that PLD can use data sources and process data. For now that needs to be done in source code. But, this is still a close to no-code system once you deal with the protocols.

Yet Another Fake Diagram. The symbols are real, but the links between the symbols are fakes yet… give me a few days. But, the fun is that I have reached a point where it is easier to make illustrations using BSA than Powerpoint.

The illustration show a classic sub-diagram – you have a state symbol that also is a diagram and some tools allow you to see the sub-diagram directly. I can do this, but I am a bit undesided on wherever I want to or not – or the details because it makes no sence to me unless you connect the input and exit points to the diagram edge as illustrated below:

This last version makes it clear what output is used where and make more sence for me since the first one actually could be misleading. I also used the smaller exit symbols in this case to save space, but thats details for later discussions. The actual drawing inside the sub-diagram would have to be scaled – and if I do this it will be an option to display description or this.

I will leave this as an idea for now because I also need to take readability of executable logic into mind. The challenge with diagrams versus actual code is that executable details tends to be hidden and making it more difficult to read/debug logic. I have an idea of how to counter that, but that will be for a later entry.

Update: I have to admit that I don’t see the purpose of displaying sub-diagrams as illustrated above. The reason is because I expect them to be far more complicated than ilustrated here + you can double click and jump to them anyway. As you use a building block you should either trust it or jump in and review/debug it. But, diagrams using a building block should abstract and tell you what it does, not dig into the details of how it does it – this is the exact same way you work if you make a function call in source code.

Navigation between diagrams will be important. KiCad have a nice feature where you can click yoursef into a sub-diagram and use a tool in the toolbar to click yourself back – I think a version of that might be usefully to mavigate between diagrams – or maybe the option to set bookmarks or have a outline tree etc.

I have 2 different diagram techniques that overlap PLD and UML State Diagrams. In reality I could merge the two to one and then let it up to the user how detailed the diagrams needs to be. A possible hybrid diagram is shown below.

This diagram is obviously a fake, but I just wanted to illustrate the outcome. The fork and join symbols are excellent for visualizing parallell processing. I am not sure I would keep both UML State and PLD Call symbols because they basically do the same things.

UML State Diagrams are typically drawn horizontally while PLD is drawn vertically. PLD is better at visualizing high level logic, while UML State Diagrams are better at visualizing signal flow in a system. As UML State Diagrams have no logic you will sooner or later need to use something else for that purpose anyway. A diagram in PLD can be a sub-diagram in UML State Diagram and vise versa – in fact PLD only lack the Join and Fork components to be able to draw diagrams that look like UML State Diagrams.

Readers new to PLD will probably be a bit alien to how Plain & PLD deals with signals – a function can have multiple entry points and multiple exit points (events). PLD can visualize events in two ways – one as a straight line since every line in this diagram is an event – or by using the event symbol in cases where you want to. The event symbols actually only visualize the events – they are not needed. Which is why you see them at bottom, but not in other parts of the diagram.

It will be a while before I work on this so I will let the idea rest a bit. If I do this then it basically will be up to the user if he want to stick to UML or draw hybrid diagrams. I never liked the terminals on UML State Diagrams, so making these hybrid terminal symbols make sence since PLD terminals lacked a clear, visual difference between start and exit signals. In reality I could keep the UML State Diagram terminals as internal connection points. This one need some thinking – fun for later.

I am not so fuzzed about wherever I am spot on some UML standard or not – this is not a drawing/modelling tool – it is a programming tool. Your one button away from executable code, and the objective is to create large systems faster and with better quality – the diagrams and symbols are only techniques to achieve that – and yes the demo above looks messy…

This first version of BSA will not have any capability to create anything than HMI, so we need to be smart about how we integrate source code. And the answer is straight forward:

• We could parse the source and auto-detect interface functions and events – it is possible, but it will require a good parser and it would still be a challenge to get it right – how do we detect events etc. The Answer could be that we use an API and detect that usage. It is possible.
• The alternative I like is simpler – I expect the developer to add Interface tags in comments. This is already done by tools like Doxygen, but I want code to be clean and comments to be readable – so what I will do is to parse tags that are formatted as proper comments – and we can generate them as well. This means I parse a definition of an interface from structured, readable comments and leave it up to the developer to ensure the specification and code to be in line.

Now – this will work for my IoT devices as specified in my previous entry and it will work for any manual code the developer want to create or use – they add the interface specification in code.

I am not against parsing source code, but I realize that is a larger task that I prefer to not dig into right now.

A “device” is a definition in our system that can be visualized as anything you want – in this example I use an image showing two of my cards attached.

What is important is that this device have input and output events – in this case shown as PLD terminals. This is a mock-up diagram (not real) so the actual diagram will have a few more details. Is this a UML State Diagram or PLD? Actually it is a UML State Diagram, but I can draw the same in PLD – and both are used the same way.

What the diagram show is that we have 1 timer and 4 input signals while we have 8 output signals. A signal in this context is a unique name with parameters. The device might have far more than this, but this is what I decided to import of the API in this case.

Part of the definition is that (1) I give the device a name, (2) I give info about connection protocol, (3) I define the signal list I am interested in. The rest is a black box.

Assuming this is a Modbus Device it will mean we need to import or create a Modbus table. Each signal is then mapped to one or more Modbus registers and the Timer will do the polling. As we set signals we just write to a local storage, wait for timer to do a write and read, and as we receive values we trigger the out signals we want.

This is just a mock-up/early illustration, so the actual diagram will be better. The HMI Designer will have a simplified version of this – we do not include the diagram only define the device as a component. The drawback is that any signal processing needs to be done in code, but that is where we start. As we add diagrams later we will be able to do processing a bit more visual as part of the diagram. But, we will still maintain the capability to just do this in code.

And how do we do it in code? Simple – pick up your favorite code editor and manually create a module that uses the BSA API. You can then import this as a “black box” with only the IO signal list available. and just use it.

Many solutions depend on something happening as a responce to time – it can be something you need to do 12 a clock Wednesday or every second, but to do so you need a timer object that can generate a signal on the requested time. This tool is needed in all diagrams in BSA for this purpose including HMI.

Assuming I want to read CPU Temperature from a device 10 times per sec – to do so I create a diagram with 3 objects – my device “device1”, a HMI screen with a label “label1” and a timer “timer1”. In the properties I configure timer1 to send a signal every 100ms. That signal is sent to device1 that as a response read CPU temperature and send this back. In the HMI device1.cpu_temperature is mapped to label1. Voila – we got ourself a temperature meter.

In the diagram above that is an actual BSA diagram you can see the solution. I have drawn timer1 and label1. In this case I used a Link Tool to create a line between them. The Link Tool is the base for many diagram line based links, but in this case it serves only as a comment to illustrate that timer1 is related to this label. Neither the timer or the link will be visible on the HMI. Timer symbol itself is formed as a start terminal/event that can be used in both PLD and UML State Diagrams.

A smarter solution would be to locate the timer on the device and only start/stop it from HMI to avoid extra trafic on the connection between HMI and device1. I will get back to how we join signals together later, but we basically declare device1 and specify how we communicate with device1 – once that is done the API for device1 will be available and can be mapped to objects in the HMI – no coding needed unless you want to.

A later version will allow you to visualize this in diagrams and do more than just passing events forth and back, but for that we either need to do some manual coding or UML/PLD active – fun for later.

The table below shows the current list of tools in HMI Designer part of BSA. It is few common tools like lines, notes etc not listed here, but this is the basic collection. I might add a few tools as I see the need, but this will more or less be version 1.0. A main milestone is to be able to auto-generate dialogs I will use in BSA, so basically the first version of BSA will be used to generate parts of the next version. This is needed due to the amount of work with these dialogs, but it is also an important milestone and proof of concept. The next step will be to add gauges and more HMI controls in hundreds – or more exactly – the current list is build-in tools while I will open for add-in tools later.