BasicPI

I will implement some support for source code control in BSA, but this has two major challenges:

1. My repository is XML and XML & GIT have never been good friends. GIT can be messy even on classic source code, but it realy can be confusing on XML. I am writing the save file as we speak and making the XML as clean and readable as I can, but this will be an issue.
2. I am not convinced that work done in BSA can be reversed out of order using GIT due to the complex nature of the repository. It is after all a database in XML format and integrity between content needs to be maintained.

This has also been a major issue with all other tools using XML. I think I can address #1, but #2 will be a challenge. One solution is to have a very good “undo” feature and my own automated log and merge log. This also comes down to one very important feature – multi-user control – several developers working on the same system.

I am in general very happy with the property editor, but it does have room for improvements. In this case I edit a table within a table. First the list of events and on each Event a list of Parameters. It works fine, but the editor get very messy to look at. I have a bug with two different fon-sizes as well, but the main issue is clarity as to what you edit. This is a very small example. One possibility is to collapse entries – which I already do as I add new ones, another possibility is to mark the table header (Events and Parameters) better. For now I will fix the font size and leave it because it is not critical. But, it will need some attention at some point. The challenge is coming up with good ideas that actually improve things.

And for the record – the property editor and integrated tables are very fast to work with. This is a sniplet of a class and it got 3 tables of which 2 have sub-tables. It might be that a simple tree-line on the left row will help on overview? The full example is shown below with Attributes, Methods, Events etc to illustrate how messy it can get. That said – the editor is fast and easy to work with and if you avoid expanding everything it also looks cleaner.

Using the editor is simple – you click on an objekt in the diagram and it’s properties are listed – as you edit the changes appear instantly. The only issue is that as I edit text I would like the text to be inline on the object (sometimes) – this later is more an issue of text beeing 100% the same – if line width is different in editor than on the object showing the text it can get confusing. Again – this is a small issue and the editor is fast to use – I think I have mentioned that a few times :). I am whining a bit over details, but this editor is a key component. It has to be good and fast which is why I am so picky. Lets see what we can bring up of ideas.

This is an early version of the 2 navigators I want to add. Both are located as folders on the left tool bar for now.

Tools, Navigator and Document are selectable on the left toolbar.

The “Navigator” show a selection of repository content that is needed to navigate between diagrams or diagram content. It will list repository content, meaning it also lists objects that are not visualized yet.

The Document folder is similar to the Navigator, but is contains every, single detail and is not really that usefully. but, I want to have it because it is sometimes good to see the content and visual order.

Both these will be precented a bit better and probably get other siblings like you have in Visual Studio. I have however so far not opened for re-docking of folders – things have fixed locations yet. As for terminology:

Repository is your main database or “known universe” if you like. A database containing all the info you need to generate code for the included modules. A module is a package that will execute on a selected platform. Diagrams are containers holding components. More to come…

This diagram is absolute nonsence, but it is actually valid. like you can write rubbish code in any language you can do s with diagrams as well. I think the compiler will pick on this due to parameter conflicts, but yet again – these are made by you. This was just a mock up I made to test connection points – the objective with connection points are to control the visual aspect of lines to make diagrams look prettier (more readable) if needed. I am more interested in giving the programmer opportunities than fixating on rules. You have to learn the tool and know what your doing as in any other tool.

Just testing the diagrams in BSA and realizing (yet again) that the mini-editor I was happy with for small description texts will be a big failure on editing source code. Modern source code editors have so many features I miss in the mini editor + the editor is not easy to use for this purpose at all. The objective here is to write small sniplets of code in assign blocks – and while it is doable  “as is” it also has several issues that needs to be addressed.

1 – I need an editor with syntax support and capability to show the user if code written is correct + add auto-completion and a JIT Compiler.

2 – The editor probably need to be inline – meaning you edit in the “Assign” box and not in the Property Editor.

3 – I have a Assign box and a PLD Source Code box that basically are the same, so I will add language selection and let PScript be default.

4 – I also need a full size editor in separate tabs allowing the user to show only description in the box and edit content in a proper source code editor.

5 – C# users would like to use Visual Studio for editing/debugging C# code etc.

The capability to integrate with manually written code is one of the most important features in BSA and critical to it’s success. But, a full source code editor is a formidable task to take on so I have to find a solution for the short term that is ok’ish. Truth been said the current editor will be ok’ich with a few modifications for smaller code snippets if I can jump into a proper editor for larger work. But, this area of BSA needs attention.

Keep in mind that BSA only have one objective – productivity for software developers like myself.

I only lack Legend and Plot line component to make a plot as I made the rest as part of the Linear gauge. Drawing a line on screen is easy. Drawing a line with thousands of points at 60 FPS (Frames per sec) is not easy. The issue is that data arrives at the CPU and needs to be transferred to something you feed the GPU. In this case data transfer becomes the bottleneck. You can find numerous plots on internet presenting themselves as “high performance” on WPF, but in reality they are not. I will make a “slow” plot that can handle a decent resolution with 10 FPS because that is easy and in most cases all we need. But, I really want an actual high resolution/high performance line plot capable of being used as an Oscilloscope as well. The later will however take some time and research, so it has to wait for now.

The example above is real with except for the lines that are added using PowerPoint for the illustration. In this case I add 7 components – 3 scales, 2 label lists, and 2 line plots. The background on the plots will be removed so you can visualize multiple series with separate scales and make your own custom plots easy. I will add a standard plot, but it is more important that you can make your own custom ones very easy and combine in other users controls for interaction customized to your own needs.

Picture from testing Linear Gauges and playing around…

I won’t recommend making a bar plot the way I did over to left, but funny that I can. Just playing around with various gauge setting to test. This one actually took a bit of time due to all the options included – and still I haven’t covered a fraction of what you can do by assembling your own by grouping individual controls inside a HMI User Control.

The work I do on HMI have two sides to it. One is the C# SDK that contains the controls, the other is BSA designer for the controls – no point being able to draw them on screen unless I can code them in user apps. The SDK part will need to be repeated for every target platform, so it is a bit of work.

Beta testing will start early next year – it is still a bit of work left, but I do see light in the tunnel…

This shows a simplified BSA Workflow. So far I have mostly blogged about the BSA Designer that will read and write a project repository – or more exact an xml file. The content of this file is used by BSA Compiler to generate Errors or Target Source Code. Source Code is generated towards a target SDK that is a pre-made library for the selected target. These can be used by 3rd party compilers to generate executable images.

Errors are feeded back to BSA Designer so that the user can correct them. BSA Compiler will allow you to design and make errors, but it will not create source code unless errors are fixed and the repository support executable accuracy. The rationale behind this is that larger systems needs to be drafted before it is worth adding all details, so the designer will never stop you, but the compiler will. I am considering a JIT style compiler so that errors can be listed as you design, but I will look into that.

BSA Debugger connect directly to the executable using easyIPC and receive feedback as the application executes. This will allow us to monitor or run single step execution on multiple modules simultaneously. Keep in mind that a BSA System might be multiple executables running on Windows, Linux, embedded platforms etc.

I have plenty of loose ends in the Designer (Work todo), but Compiler and SDK are on the table next. I need to get started on these because the design/implementation will drive the last part of the designer – speciall properties.

Some time ago I planned to focus on HMI as first out. That has not changed, but HMI dragged a lot of other stuff with it. My first target is Windows C#/WPF for natural reasons since that is what I use for BSA itself. My 2nd and 3rd target will be STM32 and Qt/QML. I already have  half-made SDK in QML. Part of the SDK’s are the gauges I curently work on.

BSA is generic in nature allowing you to make whatever system you like, but I will focus a lot on real-time, distributed systems and advanced HMI.

This picture shows two Linear Gauges created as User Controls. I have not added the linear slider yet, but these are examples of assembling individual controls as a new user controls. The User Control itself is just a shaped background and all HMI components over that will be part of the user control. In this case I add 2 x Linear Bars, 1 x Scale and 1 x Linear Labels component.

The user control draft an area and this is your design area. You draw the rest of the components on this using the designer or parameters and the content will scale as the user control scale.

Once added to a diagram you will see that UserControl1 and UserControl2 also are added to the left Toolbar and can be re-used straight away. As mentioned before you need to design properties, methods and events for your control as well – this is just the visual design part. These exact gauges are early examples of the build-in Linear Gauge.

As for the Linear gauges – what you see here is just a demo of what they can do. As with Circular components (or any HMI component) you can use the visual designer and fine-tune using the grid system or you can switch to parameterized design. The later allows you to control position, width, height through manually entered parameters for finer control. In the example above you see that distance between individual components are grid10 . The designer also support no-grid or grid5, but some of these details are just better being handled though parameters – it’s up to you.

This temp gauge is just another example. This just shows how capable this system is because I assembled this component in a few seconds while writing this blog. This is five individual components added on screen as a drawing and to change temperature youjust change the height of one of them. Gauges are all about visual effects. I actually surpriced myself with this one 🙂

This took me < 2 min to set up and is just a simple Modbus demo.

1. ComLink1 is a serial port connected to com3 in this case. The component has an auto option that allows it to always be connected that I use in this case.
2. ModbusTable1 define parts of a Modbus map – in this case a single float value located at register 30000. Ths setting also specify base 0 and that 30000 is 0.
3. MyForm is an app as simple as you get with my new Circular Gauge on it. The only detail I am not happy with here is that the name “MyGauge” is a bit hidden.
4. The diagram at bottom start with a timer triggering once per sec calling a Select that read ModbusTable1 using ComLink1. If that works I call an Assign that update the value of MyGauge.

That’s it. If you pay attention you will see that every detail I need to code this application is on the screen.