BasicPI

The diagram below show two sub-diagrams. Sub_Diagram1 is a standard function call while Sub-Diagram2 have multiple input signals each connected to a specific method in the diagram. Both are legal drawings “as is”, but they have conflicting precentation needs. In “Sub_Diagram1” is is natural to assume that we call a function “Sub_Diagram1”, while on Sub-Diagram2 we call “Sub_Diagram2.<method>” – what method can be visualized on the input line.

Earlier I had a seperate function call that I removed, so it’s possible to bring that back – I removed it because visualization was identical with a sub-diagram. Another possibility is to make a rule that unless you specify a method you actually call “Sub_Diagram1()” – this will work, but how do I then specify what diagram “Sub_Diagram1” is located on? This is the same as with C++ or C#, you need to specify “class.function” one way or another – so do we. I am not concluding, but I need to look into this one and see what notation that works and not.

Copy & Paste is finally working as they should. BSA allows you to draw duplicated tags, but the compiler will raise it as an error, so paste do not change tag names like the “Start_68” below (yet) – I am not sure I want it to either because design and coding are different tasks and we need to support both. I lack handling of versions as well – we need an option to handle multiple versions of a diagram, but that is not critical now – I was mostly interested in Copy&Paste because it was very annoying not to be able to do it.

My November/December release is running a bit late, but the list of what I want to have implemented/fixed is getting shorter. I need to convince myself that I have a properly working modeling tool and while I started on class diagrams, state diagrams and PLD sneaked in adding to the scope – but, it makes sence. The main thing remaining is sub_diagram to diagram linking + error fixing. I am surpriced about some of the bugs I find – or more correctly – how little things are tested – this is one of the reasons I need to get this on the road.

The diagram below is an “abstracted SDL” – or simplified SDL if you like – it is a flowchart with SDL heritage that is a very good way of writing a visual specification assuming you have a tool that support it. This is at core in PLD. This exact example send a message and wait for responce. It performs an operation that in this case send a message out, PLDState will wait until a selected event happens etc. The direction and bar colors on operations and events is just presentation issues – in fact this is only a drawing tool as we speak as parameters for code generation is missing yet.

Events are key to PLD! The example above use a SDLState that “Wait for an event”, but you can add this event tree to any symbol that has multiple events. The event symbol will only accept one input line and pick an available event from the connected symbol – in this case a PLDState that list the events it is waiting for.

This last diagram use a switch symbol to indicate that we select one of many conditions. Unlike PLDState that will wait for an event this executes directly without delay and is an elegant way of drawing complex if/selections. This is modified SDL behavior and a very effective way to draw a complex if, elseif or switch.

One of the reasons I call this “PLD” is because it is a graphical language with heritage from Flow-Charts, SDL and UML, but it is a separate standard so we get to find symbols and ways to precent them. Nothing is written in stone yet as it comes down to what works and what does not.

PLDState and PLDSwitch is very similar in the sence they have a dynamic event/condition list – the difference is that state will wait until one is true, while switch will not as it is designet to make a selection “now”. Other symbols can use the same tree, but events will be a static list base on availble events.

One of the upcoming features is the capability to import C/C++ code into a BSA project – correction I only want to be able to read C/C++ so I can set up the BSA Repository to generate code that uses an external C/C++ library. This is one of many important features as you integrate high-level to an actual platform. Looking for existing projects that does this I found several targeting C# so I plan to re-use one of those. This will enable an user to import existing libraries into BSA and use them.

The process is fairly simple – you run a CPParser that read your source code or header files and generate some kind of repository “AST” – you then run an internal import converting the info we need into our own Repository. This function will be added as soon as the modelling release is out in Beta.

I am also looking for similar libraries for other languages, but it will obviously also be possible to define this manually.

I am experimenting a bit with C++/PScript coding in PLD and you can see the mock-up below where I create 3 math functions.

The diagram is named “Math” so the functions are Math.Pow2, Math.Abs and Math.Sin – two of them in C++ and one in PScript. Assuming the target is C++ you can add C++ scripts using the Assign block. This is handy then you want to just add a few lines of code in C++ directly. PScript does the same in a generic way, but on the low level functions you will need to use C++ a bit. My first target is C++/STM32.

My first comment is that – yes it is possible to write target source code, but it is not a nice way to code as is. The editor I use is ok for text, but not for source code so I will need to change this. My plan is (1) to add a more decent editor for sourc code – double click to open an editor or something – (2) add an import function and support external functions so you can write target language code in your IDE and just include it from BSA. But, these changes will be for later.

Another issue is that Math will be a large library – the actual library will be an include, but I would like to be able to create this or similar in BSA- and yes I can. Looking on the picture above you will see that I run out of diagram space. This is the one drawback with diagrams – they take visual space. So in short – I need a sub-diagram option or “partial diagram” – simply an option to create a new diagram as an extension of a previous one so I get the “Math” prefix on all functions. The simple solution is to create a new diagram and call it “Math” and then let BSA auto-detect this being parts of the same diagram. Diagram name in BSA is the same as Class or Namespace in C++/C#.

It is a few things on the modeling level that need fixing before I have a release:

• Annoying line errors. Diagram lines are sometimes a bit off and you don’t see it before you copy or re-load a diagram. This must be fixed.
• A consolidation of tools available in PLD.
• Listing known errors.
• Implement Copy function.
• Add partial diagrams.
• Fix select function to be consistent.
• Fix internal diagram to diagram links.

That’s it – after that I release a Beta and start on C++/STM32 code generation. Next is adding HMI back in and supporting C#. The plan is to support C#/WPF for HMI and C++/STM32. I need to start somewhere and these are the two that is easiest to implement for me.

I am getting closer to finishing a Beta version of BSA as a pure Modeling tool. It helped a lot starting to use BSA on a PLC project and the visual dictionary UI is a step in the correct direction. What you see below is one of my remaining bugs. I removed connection points after some testing, but the lines below is still computed as if CP’s are precent. I Only need to click on Actuator and move it forth and back and lines are corrected, but it is a very annoying error. As I save the diagram and re-load it the error is fixed so it is only minor.

Dictionary organized to show main diagram content is a step in the correct path. Switching to the alpabetic content list (below) you can see the example BSASymbol – I now get BSASymbol + a clear indication of precentations of BSASymbol. All in all th dictionary starts to function as a navigator, but it still lack some critical functionality like the capability to drag existing objects into a diagram.

My first objective was to release a UML Class modeling version, but state diagrams and PLD is also included now. What I do lack is a UI to import/export between precentation classes and the original entry, but having the freedom to draw as you pleace is important.

The weakest part of this release is PLD that will need a bit of work before it is fully functional, but as is it is great as an addition to a UML State diagram. I don’t think PLD will be completed before I start generating code. It is a matter of actually coding with PLD on real examples and see what is missing. I am working on a PnP robot and need to modify the existing firmware (C/C++) so it could be fun to test that up against BSA. It is specially the G-Code engine that I need to work on. I think a few projects that drive the last bit of development will be needed because it is not possible to see what is missing otherwise.

But, lets focus on dictionary and integration between diagrams first – PLD modeling and Code Generation is next.

The Dictionary part of BSA is quite important as your project grows because it is instrumental in keeping overview and re-using components. The content is always the same, but I decided that I needed at least two precentations of the Dictionary content that is selectable by buttons on top of the Dictionary folder itself. You see examples below and this is not written in stone. The first organize content by diagrams, the second list content by category. The actual project below is just a mock-up used for integrity testing.

Names and terminology will need to be consolidated + some more testing and this Beta is ready to go.