BasicPI

ComLink is as the name indicate a component that contain a communication link (IPC, Serial, Ethernet) and contain two Methods : Open and Close. In this case both are optional because the component also have an auto “AlwaysConnected” mode. The output is either OnOpen, OnClose or OnError. OnOpen is shown red because it is Mandatory and not connected. OnClose is shown Green, Open because it is Optional and not connected. OnError is shown Green because it is connected.

Some components will have a fixed list of input/output signals as in this case. The positon of the communication points are computed automatically and the object is sized if needed.

These days we tend to work as a team through GIT or similar tools, but assuming two engineers work together on a project it would be nice to chat and see what the other is doing real-time. This feature is a bit in the future, but I like to think and plan ahead on issues I know would be a significant booster.

And yes – we do have chat options on separate tools and options to share screens on Teams or similar, but I want to look into the benefits of integrating them into the tool for the purpose of increasing productivity.

One issue is that it sometimes is nice to have closed discussions with other users, other times you enjoy chatting in a subject group – or maybe you just missed a few days at work and want to see what the others have been up to – reading up on public discussions. Also – sometimes you need to ask questions that someone picks up in a different timeline. None of this is rocket science today, but again – I want to experiment with the added value of having it in the tool.

I will leave this subject for now as I firstly need the stand-alone BSA functional. But, the idea is not that difficult to implement using a decent database as a repository server.

And Yes – I understand that some developers like privacy and be able to avoid that managers or others oversee to much, so I will support a privacy/off-line mode regardless. But, having chats and multiuser support in the tools is also about socializing with others. Often you are not involved in a project and would like an insight or maybe jump into someone elses work and copy parts of it to save some hours. BSA needs to be fun to work with!

Notes or comments are very usefully in any programming language, but they are often left out in graphical tools. BSA will add manual- and  auto- created notes. Manual Notes are Cyan by default and maintained manually as part of the diagram. The example above shows a mock-up diagram with possible notes at right. I need to experiment with colors, but those can be changed by user anyway. As BSA Compile a project it will also generate Warnings and Errors as any other compiler – these can be added to the diagram as auto-generated notes, meaning they dissapear with next compilation (or if they are switched off).

I will need a global Error/Warning list as well, but, in a graphical tool it makes a lot of sence visualizing these in the diagram as shown above. At the end of the day this is a comment added by yourself or BSA to assist you in you job, but this is smething I often miss in other tools.

The examples above lack an optional, dotted link to “State” – Auto-generated Error/Warning will need this to pin-point what object that cause the issue. And as mentioned you can remove all auto-generated stuff with a click – this is also important because sometimes you simply want to draw illustrations and not worry about executable details yet.

Showing to different Start terminals with parameters. The result is ok and I lack a better idea. In this case I list the parameters below or right just to visualize them in the diagram. I need to add default settings here because parameters of “MyToplabel” need to have values if “MyLeftLabel” is used and vice versa. This also means that parameter names are unique for the diagram and treated as local variables.

In this example  add local variables. “Locals” is a reserved name using a Data Table to hold local diagram variables. I might have to adjust the details a little, but I thing this will work just fine. To be honest I often add visualization like this and then I just need to use it for some time to make up my mind if it does the job or not.

It’s ca 25 years ago that I designed my first real-time plot that was a very advanced multi-plot showing a high number of sensors. I have used several plots since then, but I want to create something that is very powerfully for BSA that fullfill two requirements – (1) fast and easy to use and (2) capable of the same complexity as advanced multi-plots.

To achieve this I will need to create a set of tools in BSA that used stand-alone is not so impressive, but used together they are very capable.

#1 – Standard RT Plot with everything on. This is to make it dead easy to display a few plot-lines and is only a composition of the other tools.

#2 – a plot line stand-alone with or without a background. If you add multiple of these on top of eachother with transparent background you get a very interesting plot.

#3 – a stand alone Legend that you can put and format independently.

#4 – a stand-alone X and Y axis so you can add multiple of both to form a multi-plot.

Stay tuned – I will demonstrate this in a few days because using BSA as base this is not difficult or time-consuming at all.

This example show a classic ER-Diagram and how to auto-generate part of an application based on that diagram. This example is actually my own Tool Maker that I use to maintain tools and properties in BSA itself. It is not auto-generated yet, but i could be and this is one of the features that I will implement in BSA. In this case we will be using BSA to auto-generate content we can change in BSA.

This little diagram illustrate three tables Component->Property->Value. This is all text as the previous GUI was Excel. But, if this had been drawn in BSA as above I could easily have autogenerated Forms to edit those three tables. Auto-generating GUI means you need to follow some standard scrheme and the GUI you generate will be a copy of that.

This dialog is an example of a component grid. If I double click on any row I will edit the details row for this.

This next dialog show the Tool Details with list of properties and details I want to view. I now use a banner & grid on top to edit details of each component and list the components properties in a grid below. Next drilldown will be the property editor. This is not exactly rocket science, but making this manually was about 6 hours of work. My forst editor was Excel, but I decided I wanted a proper editor for this. If you have a lot of tables it is quite handy to have a first auto-generated GUI just a click away – ok it was only 6 hours with WPF, but it would have been far more with QML – and 6 hours saved is 6 hours saved – if you don’t like the layout simply change it.

This is a mind experiment. The select operation will need to specify which table it shall read, and in this example I just drew the Modbus Table and used a relation between the select statement and the table. I am not sure if I want to allow this, but it is an option. Tables can be displayed several places, so ModbudTable1 can be defined in another diagram and only referenced here. What this should do is to call select – which in this case execute a read that read 30000 to 30002 every second. And once we get a responce we trigger the “GotData” event.

Using a relation like this is a bit misuse of the technique, but it is an interesting idea that actually add readability to the code – ok, we can change the line type to avoid confusion, but this diagram is actually readable and it makes it very visible what we are doing.

ModbusTable is an abstracted Modbus interface that allows you to view Modbus as a table with continious registers – what you see is Input (Read) and Holding(Write). This will only support a small subset of Modbus so we will need an adition Full Modbus version, but this abstraction takes care of 99% of usage + it makes it easy to map registers to variables inside BSA.

“ModbusTable1” is a specification that is implemented as a read/write modbus message and an internal cash table. The rest of the system will see this as a datatable accessing registers by name. I need to do a bit adaption as I test here, but I think I prefer to use Select rather than a specialized Read in this case simply to avoid to many statemenst doing similar things.

I quickly tested using my mini-editor to edit source code and this is a mistake. The idea in this case is that you write a statement block – a small script in PScript that execute a small operation – this is intended for assign operations, but you can write a full PScript program if you want. It looks ok – you can switch between showing the actual code or just description, but the editor was bad – very bad in this case. It will kind-of work, but I need a better solution here.

One idea is to let the user double-click and open a full editor, but in this case we need a proper source code editor. I have two of these components – Assign was intended for a more Table/Tree like list of actions, while “Source Code” was intended for the example shown above. I am very unsure about the table/tree alike concept as I need to convince myself that it will add something – I think I will focus on getting sniplets of source code directly in for now – and here is the upside – I can actually let the user enter whatever source code he/she wants to use.

PScript (or Plain) is target generic and a good starting point. This will go hand in hand with PLD, but why not let the user input Python, C/C++, C#, Java or whatever is needed? Yes it add some difficulty because I need to cover usage of multiple target languages on a target, but it is doable. Python is a simple example as we can just run Python scripts from just about anywhere, but I need to add a Python API – it will be a bit of work. I think letting the user choose between PScript, Python or target language will be ok – target language for the platform and PScript is a minimum and then adding Python to those targets supporting it?

PScript is more forward because the compiler will convert PScript to target language – I don’t actually plan to use a PScript Engine.

But, editors – I need to integrate a proper source code editor… I will return to the API needed for target languages later…

This figure illustrate the work flow of the code generator that I decided to call “BSA Compiler”. The BSA Compiler will read the project file and compile the output source code that can be used by a standard IDE/Compiler to compile/link the target executable. The BSA Compiler will also verify project content because a lot of the content is loose text or drawings that the compiler will issue errors or warnings about. I am consider a JIT (Just In Time) style compiler so that I get tags of errors and warnings continiously as I work in BSA. If you draft functionality on high level you might not care about executable details yet – but the compiler will force you to deal with them before you generate target source code.

This shows BSA Table editors in use -I need to use them a little myself to verify if they are ok – I admit it is a bit confusing to have description in the table and then have to edit it as a property. But, the mini tekst editor is actually great. DataType is only a tekst string – you can write anything you want – same with name. I don’t think I want any automation restricting you here, but I will need a BSA Compiler that check rules – etc if names are unique and if DataType is known.

This leads me to a more complex editor – the one I need for assign statements, Parameters, Relations etc – I have decided to start with an easy concept of an editor where you write small snippets of logic with the dame concept – you write whatever you want and the compiler verifies the content. I can always consider more automated concepts later, but I think it would be an error to rule out text editors.