BasicPI

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.

Tables are objects with their own methods and events, so the example below grab events from tables and process them. This is the same as adding a start label with the event name as the PLDFlow link will need to be connected to an Event and a Method and convert data between them. Event comes with parameters and so does Methods, so the PLDFlow will need to take the input event parameters and create the method parameters.

I could have done this in my previous example as well – taking the PLDFlow directly from the OK button, but this is your choice – sometimes it is convenient to use start labels. PLDFlow will allow you to select available events in the scope – if you drag from a Start symbol the selection is whatever is selected in the start symbol. If you drag from a component the selection is the exit events of that component. Notice that the line with Arrows are PLDFlow while the lines with “forks” are Data Relations. I will change colors to make it more obvious that they are different. Table is one of the few objects that can use both Data Relation and PLD Flow.

SQL Databases also support Triggers (same as events) and Stored Procedures etc. BSA will support these at some point allowing import and definition of those. But, this is not primarely a data modelling tool, so it’s a bit down on the list.

This creates a question – with table supporting events and methods as any other object – do I actually need the specialized Select, Fetch, Update and Delete?

This diagram have no input flow to Table – which is ok because Methods and Events are either Mandatory, Optional or Static. An Object with no Mandatory Methods do not need an input PLDFlow – that said it could benefit from a Timer connected to Select in this case.

Mandatory Methods/Events are those who MUST be used. The BSA Compiler will issue an error if these are missing. Optional means you can chose wherever to implement them or not, meaning they must have a default implementation. Static Events cannot be overrided by user – in this case you have decided that the event shall call a specific method. Only events can be Static.

As for Select, Fetch, Update and Delete – these also have a filter part, so yes I do need them.

BSA contains two techniques to model data. One is classic ER Diagrams and the second UML Class Diagrams. Class diagrams provide an object oriented approach that will go well with languages like C++, C# and Java, but a class is basically only a definition of a new datatype that you can declare as a variable using ER Diagrams. Tables in ER Diagrams represent actual, physical data structures with variables. This is how BSA will need to use the two techniques and the current scope focus on ER Diagrams. It might be incorrect of me to use terms like “ER Diagrams” and “UML Class Diagrams” because at the end of the day I tailor the modelling techniques to what I need them to be to support an executable specification.

Each diagram name must be unique and as you draw a table on a diagram the diagram name + table name form an unique, global name that can be accessed from anywhere.

This example show a simple Customer Table, an associated form to edit it’s content and the logic of what happens if you press the OK button. Both Tables, Forms and the components you add have multiple events you can activate with the PLD Start symbol, but I only show one event processed here for the purpose of illustrating BSA at use.

To be formal I should probably call the event “Form_Customer.Button_OK.LeftMouseUP” or something, but I want to look into default naming to simplify diagrams, so if I use the name “OK” on the button and as no other object on the diagram uses that name – “OK” should be ok – local name scope. I need to work a bit on the details here, but I am reaching a point where I can generate code. And once I start generating code I will probably also need to adjust BSA to cover details I have not seen yet.

Another observation is that the forms and logic shown above can be auto-generated from the Table definition – simply adding a Wizard that provide a default diagram you can change afterwards. This capability is worth gold if you do heavy database modeling and want to quickly test your model. Keep in mind that the “Table” here can be anything from a real SQL Table, to a XML file, RAM table etc.

The one thing I am a little unsure about is binding of events from the Table to the Form – I think I will like to avoid creating a “source” in the edit fields and force “Fetch” to convert data in the current entry to fields on the screen (or other data entries) – this way I leave the user full manual control and avoid auto-magic that don’t always work. The complete diagram can be see below.

I think this will work out just fine – and sorry for the dotted flow lines – that is a bug 🙁

One complicating factor here is that Select, fetch and Update hide the executable details – you will have to click on each bog to see actual code in form of properties. This means that while it is easy to follow logic it is more difficult to see actual code and find bugs – so I need to work on that a bit as I address the debugger later.

BSA is coming together, but it is a complex tool and lot of things that needs to work properly. I am currently focusing on classic database modelling, Forms and Modbus in the first release that probably only will target C#. It is more or less exactly 1 year since I started on this task with WPF so progress have been good, but it is still a lot of work to be done.