BasicPI

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.

One of the big things with any GUI/HMI is the capability to quickly create new user controls. The method I want to use is to let the user create this using a state-matrix. Layers in rows with layer 0=preview and columns as states. The control is illustrated above.

In this example I plan to rotate the needle on layer 2 to create a simple clock gauge. To do this I set in config that input value goes to layer 2 and on each state I connect that with rotation of the line. The final result will be a gauge that change background and needle color based on state.

I have some experience creating gauges in code and think  this will be a big time-saver + I can link cells to code if I need to and do other tricks. I am coding this as we speak so give me a few days and you will see it in action as we start adding user HMI libraries to BSA.

And there we area – still a bit work in progress with styling details, but I have passed the point of no return.

Back in the days then I coded MFC for User Interface I often upgraded my apps almost for free by just sticking to classic development. This was what I did here as well – I ignored dark theme assuming I would find a solution that could provide that for free. The solution is the 2nd on Nuget list – import a single style sheet, write a few lines of code and style up the places that needed manual styling – and voila.

I am ok working with light style, but dark theme is so much cooler and most important of all – I use colors and styles that get me into better moods. And yes – I need to change some of the above as this still is work in progress, but I am actually impressed over how fast and easy this actually was.

What I have done technically speaking is to avoid caring about colors and used a style sheet that override colcors and style for standard Windows components. I don’t fully understand all the XAML code yet, but I like the results and way of doing this as it means I can have different style sheets and completely change the look of BSA – but, that’s for later.

Work in progress. I found an example of how to change the style of Windows controls and voila – all the controls I have not styled myself changed. Notice the scroll bars etc. This is what I liked with Visual Studio back in the old days – you just stayed loyal to their scheme and suddenly get a lot of work for free. I need to update the rest of the color codes, but I can now go dark theme with close to no extra work. This is exactly what I hoped for as I decided not to dig into dark theme yet.

Also I discovered that the property folders I want actually exist – called “Expander” so I need to do less work than expected to build a property editor the excact way I want it. The Blend Style example that convinced me is seen below. This is basically a single xaml style file and a few lines of code added to you project. I was surpriced about how little extra code it was. For those interested you can find the original github code here https://github.com/DanPristupov/WpfExpressionBlendTheme.git under MIT license. Next time you see BSA will be in it’s final dark style. The all gray style used below is a bit booring in my eyes – I need a little bit more colours to light up the moods.

I don’t fully understand the styles.xaml yet and it is still a bit work in progress, but this was a very convinsing demo about how powerfully WPF/XAML actually is. I don’t pretend I like everything in it, but what I like is the sum speed of productivity you get – hours needed to make an advanced GUI solution. WPF is suprisingly fast to work. It’s been a few tweaks on the 2D engine, but I am very happy with the results and hours I needed to get there.

In comparison – I can (and am) doing the same in QML. I get the job done in Qt/QML as well, but working with QML is a steady stream of technical problems and an IDE that don’t do it’s job. The sum is that to do the same I use close to 5 x as much time. In WPF you write C# and XAML, but in QML you write C++, convert to Qt++, do QML bindings, write QML and JavaScript. It simply is a larger job to start with and add a poorly working IDE on top of that. That said – QML compares well to technologies we used 25 years ago like C++/MFC. And more important – QML and WPF is the only technologies I have seen that make using GPU’s decently easy. I have yet not tested the new MAUI, but I will.

The main reason I still work on QML is because I have auto-generated most of the difference and need a SDK that I can use to generate code for. While my primary target will be C# itself I also intend to pick up targets like QML. The result will be a huge difference in number of hours needed to code up systems – just stay tuned a few more months and BSA will be airborne.

Cost wise QML is a nightmare – Qt/QML with their designer cost ca 50,000.- NOK, while Visual Studio cost ca 5000.- NOK. And add to that the well of libraries like this one you find in Visual Studio. Just one advice – be very sceptical and think through what you import as you pick up nuget packages. Myself I only use MIT or similar licenses and source code unless I buy a commercial package. Make sure the library you pick up fits the bill.

Happy coding!

This list will increase, but I need to start with some basic components. The first version I need is HMI only together with a few other components:

This list will change and grow. The main challenge here is to limit the scope of this first release so I actually can release a first version. Also keep in mind that we are not just designing the screens here, we are actually coding the content as well. I have fetched HMI content from standard GUI designers, but it is important to remember that this is a design specification used to generate code. That gives us far more automation options. Using Modbus as an example – I want to grab a Modbus map as data source and be able to create a fancy desktop application in minutes and literally have the same on desktop and web without thinking about it – it needs to be that easy.

The easiest way to discuss properties is by discussing actual components, so I start with HMI Form. The terminology “Form” is well known for C# developers. I could have used dialog, window or whatever, but decided that “Form” is a good word. What you see below is the current HMI Form draft used in BSA. I will make this a bit more WYSIWYG later, but this is NOT the actual Form – this is the design of a Form. The actual Form will be generated from BSA. In this case I illustrate a Form that is a Display dialog containing a property list that design look and behavior. The result will be a long list of properties, but my experience with this from C# and other tools is that I 99% of the time only use a few selected properties – so lets start with those:

Colors and Style is something I set and later reuse. So the best idea is I think to remember what was last use and use that as a starting template. Simply said this is something I change once and seldom use so it can go into background on a separate page.

• Description is very nice to always have in front.
• Name of component
• Caption Enable and Title
• System Box enable
• Minimize, Normal and Maximize box.
• Starting Window state
• Window Size and Scale limitations.
• Window style – modal etc

The idea is to put the properties you actually use a lot and will change on a default front-page, while all the colors and nitty gritty details can go on specialized pages. The rationale for this is that I often spend time looking for things, so I want to see if I can make this a bit easier. The components will need a lot of properties so it makes sence focusing like this.

To do this one I will need the following completed:

• My mini dopcument editor.
• Standard single line text editor for name, title.
• Boolean to enable caption, boxes and features.
• Number editor
• Combo box.
• Color editor.

Form is a container for other components so it has no direct data-links.

The next task on BSA is to get my Property Editor functional. What you see above is an early demo draft to test a concept. I just wanted to get a feeling with how this could be done and test out the “Text Edit” part. The concept with a Property Editor is that you click on a component in a diagram and get properties for this displayed. Some of these properties are documents, source code and tables making them a bit complex to integrate without to many trade offs.

I considered using an existing Property Editor, but (1) WPF does not contain one, (2) this is a very important component for BSA and (3) it is actually straight forward to implement if your not afraid of huge work loads. It is a large job and you will get tired of me blogging about various editor details as this evolves, I will need a specialized editor for each datatype I use. Some are very straight forward, while others will need a good design and some fresh ideas.

It is three editors that are of special concern – Tables, Text documents and Source Code. These can all be implemented as a property line. Text document is illustrated above. This was far more capable than I first expected as I can widen the Property editor and get a larger doc. But, having all tables, docs an source code like this have it’s usage and limitations. I will need something more.

Having source code as part of the property editor is usefully as you want a quick look by selecting a block on a diagram that contain source code. You can see and even edit in the mini editor, but I thing we all agree that we can’t do more serious work here – we will need a proper source code editor. So the idea is to do both allowing Tables, text doc and Source code to expand into being a full View in BSA itself. This might also work for sub-diagrams. I obviously need to experiment a little around this and see how this works out. But, this is a functional area that will decide the success of BSA – it is that important. If I don’t get this to become something that is very convenient to use the entire tool will become a big, clumbsy failure. The reason is obvious – time usage.

This is the one thing you need to have in mind all time – time. BSA is  a productivity tool that should enable you to do more faster. But, I have used so many tools in my carrier that ended up as a failure that I am well aware of the danger of repeating that failure if you make the wrong choises or compromizes.