Category Archives: Plain

HMI – User Controls

I still have some work to do on the basic drawing/HMI engine, but will soon be focusing entirely on what I call “furniture” as in pre-made controls we can use. I will create some fancy, build in controls, but the most important one is a “User Control” enabling us to create custom controls. Now-keep in mind that the entire HMI is specified in XML format and loaded as we start the HMI Browser, so a custom control will need to be loaded as part of this. For the Designer, we would like to have a library that is made available, but only those that are used to be included in the final XML.

The User Control itself needs to be built from other controls and by adding colors, scaling, rotation etc to create a new control. This means our user control will be a list of build-in controls where we create our own, new interface. As input values can transform to position or rotation we should be able to create most controls these ways.

To enhance our customization capabilities, we have Polygon and Plain. I don’t want to dig into the same security problems as ordinary browsers, so the Plain VM will only have access to HMI Browser, not any of the host OS capabilities. If we need the later we will have other options for that.

Plain Logic Diagram – Terminator

I did a few prototypes to test a graphical programming language a few years back. First one in VC++/MFC and later one in C#/.NET. What I will do next is to write blog entries discussing the syntax and wrap this up as a language specification.

I called this “Plain Logic Diagram” (PLD) by accident and I will use that name for now.

We have already described Plain as an assembly language, so this is a “compiler” that generate Plain assembly. The syntax is based on a combination of classic Flowcharts, SDL (Specification and Description Language) and some new concepts to take advantage of graphic diagram qualities.

The illustrations I use will have to be created in various tools, this one show the terminators of a diagram and is drawn in PowerPoint.

A classic function have a start and an exit. We already know that Plain raise events with different output parameters. In the diagram this is shown as multiple exit terminators with associated parameters. The new part is that we also have multiple input paths with different parameters in the same diagram.

The key principle here is that one diagram is a function with multiple entry points and multiple exit points. Exit points are event’s that either are Static, Optional or Mandatory.

A Static event is a hard-coded jump to another diagram that can not be changed.

An Optional event also have a hard-coded default that the user can chose to override as he uses the function.

A Mandatory event must be present in the diagram using the function.

These are the same principles we decided on for Plain assembly events. In the real diagram we will add notifications to visualise these.

A diagram is the same as a “function”. Off-page connectors can only be through terminators, but a diagram can be as large and complex as you want. Logic is flow-chart like and will be instantly recognized by most people. This diagramming technique have been tested as executable specifications and have proven itself as a superior specification technique in front of customers. The only drawback is that you need a specialized tool to do this otherwise you just end up using far to much time creating diagrams.

So in short – the IDE and language goes hand in hand. A graphical language can only exist if we create a proper IDE/Tool for it.

The diagram example shown here do however suffer from the issue that I can’t see the parameters. I see high level logic, but I don’t see the actual executable details. Also – what about local variables etc?

to be continued…

HMI Designer Annotated

This premature screenshot shows an early version of the HMI Designer. The designer itself is quite simple, you use the menu/commands on top to create a “diagram” and the design tools at left will come up. In this case we create a HMI, but I will re-use the framework for other diagrams later.

An HMI (or GUI screen if you like) is straight forward. You just draw the HMI components you want into the screen and assign names to them. This example only show a few rectangles and ellipses. To edit the properties you click on a symbol and change the properties using the property editor at right.

A tab field on top (not shown) will allow you to select between HMI screens as you design a project.

This concept should be well known for anyone with experience from Delphi, Visual Basic, C# etc. I want to just start with a simple HMI Designer for now. The objective is to create the HMI framework, XML format, HMI Designer and HMI Browser to an usable stage.

I will use Plain as a scripting engine capable of processing HMI events locally. In a later version I will add support for experimental diagram logic and see how that goes. I will write a separate entry about the ups- and downs- using a graphical programming language later.

HMI Browser will in reality be an app that starts up with either a file- or communication path. It can either retrieve the XML from a file or have it sent up from a device.

As for time-line an application of this nature will take some hours to get right. As it also have to be done as I teach myself Qt and are occupied in very tight projects elsewhere it will be something we need to focus on for a while. I do however have plenty of unfinished electronics that we can play with if I need a break.

HMI Designer

One of the applications I want to create is a “HMI Designer”. This is technically very easy as I have done similar applications before. What I will do is to create a graphical application that can design square objects on a form. Each object will have a name that we can use for IO through a serial line. To make the designer a bit more WYSIWYG we animate the objects as if they where “furniture” like Text Edit, Graphic Plot, Grid, Button etc. Each object will have a list of properties that are set/get design and run-time. The result is stored as an XML file and executed by a “HMI Browser”, a special application that download the XML and interact with the system.

This way we can design config HMI’s stored in the embedded devices as XML files and we only need to re-create the HMI Browser to support HMI on Windows, Linux, OSX, Android etc. The concept is not so unlike a Web Browser with the exception that the server here can be small embedded system in a closed loop. Nextion are selling displays build on a similar concept, so in time we can do our own embedded graphics displays as well. I do however want to do tings a bit different from Nextion.

One of the differences is usage of Plain as “scripting” language and interfacing using easyIPC and RSX as well as Ethernet/Wifi. The other difference is that I want a significantly larger object library and take advantage of GPU’s on Raspberry PI etc. I also want this to be a portable software package, not locked to proprietary hardware.

The most important difference is however system thinking. I want HMI Designer & HMI Browser to be building blocks in the CASE (Computer Aided Software Engineering) Tool I want to create on top of Plain. For now we will use Plain and the HMI Designer, but I do plan a fully graphical programming concept later.

As mentioned before with my Plain blogs I want to evolve the way we do software based system development. The network I build here have plenty of fun for C programmers and electronic hobbyists, but we need to create infrastructure and tools enabling this for non-specialists.

Plain – hitting the road

I wrote lengthy blogs about Plain syntax and concepts earlier this year and want to wrap up the specifications and get going. The challenge with pushing on ideas and concepts is that you start getting blind-folded and stuck as you push for results. This is why I prefer new concepts to mature because what seems like a good idea one day might not the second day. Many of the concepts in Plain have however evolved over several years as I started on this far earlier than this blog.

The difference with other programming concepts is that I don’t want to create another language, I want to evolve the way we work so we can achieve more with less. Plain embrace several new concepts aiming for that, but this is untested theory. I believe it will work as expected, but I am also prepared for setbacks as we move forward.

Plain is also more difficult to achieve than normal programming languages because I need electronic devices supporting it and an established infrastructure to build on. Things take time, but we will get there.

Thanks for reading.

PLC – 24-bit Analogue Input Module

This analogue input module uses a ADS1256 that allow 8 channel input with 24 bit precision and 30Kbps sampling rate. With a programmable gain amplifier 1:64, programmable filter and support for single or differential inputs as well as calibration this board can cover most ADC needs.

The input here can be 8 stand-alone channels or 4 differential channels. A stand-alone channel will measure voltage between input and ground, while a differential channel measure voltage between two points. The later is more flexible as it also can be used for current loops. The challenge is however that different usage require different line adaption circuitry, meaning we will need different analogue boards.

My primary focus is on typical analogue sensors like light, temperature etc. This example circuitry feed a voltage in that is split over 2 resistors with the sensor being the 2nd, variable resistor that changes with light, temperature etc. A typical ADC line driver is shown below:

This is the water sensor I illustrated earlier where we use a specialised PCB as a resistor. R1 need to scale the input so we get 0-3.3V out to the ADC. The capacitor is only a filter. More important is that we can Interface to this in two ways – we can create a 2 pin connector for the external resistor only, or we can supply +/- and expect an analogue value in. Many modern sensors will require the last 3 wire Interface as they provide their own specialised analogue interface.

The main drawback with this technique is that we can only have a limited distance between sensor and the ADC since the wire will start acting as a resistor that needs to be taken into account. A different analogue technique that can be used over 5km is a current loop – I will consider making a Board for that later. But, also remember that we have RS-X based sensors that can cover some distance in wiring.

PLC – GSM Module

This is a draft of the the stand-alone GSM Module designed around the SIM800C module. I still want to see if I can get this into the Ethernet module, but made the diagram above to illustrate the content.

The primary interface to the MCU is UART + some GPIO. This uses the AT command set to control the GSM.

An USB is available from the GSM Module for debug and firmware download. The intention is to connect this to the USB on the MCU as well as making it available through an extern port. I have a loose end on how to do this that I need to dig into. I might also put this port a bit hidden as it is only optionally needed.

GSM antenna need to be added.

SIM Card holder need to be added.

Sound In/Out is usually to a mic/speaker. As this is not a phone, but a PLC we would like that digitalised so we can play sound files, do funny things like speech recognition etc. The later will require a Raspberry PI (Zero ) Add-on to do the processing. I am thinking of running an open source solution where the GSM act as a line card to FreeSWITCH or Asterisk + PocketSphinx to support a single line.

All in all I must admit that this module will require some space, so it might be a bit crowded to get in on the Ethernet Module – lets see. It’s a lot of loose ends here yet.

PLC – Ethernet Module

The block diagram above show the Ethernet module. Starting with a dual RS-X to the backbone and a SPI based W5500 for Ethernet connectivity. In addition we add a ESP-12 for Wifi, SPI Flash for storage and a RTC battery & oscillator as well as the mandatory SWD connector. I hope to have a 3D model of this board ready within the next days. The red box on Ethernet/Wifi mark that this is galvanic isolated.

The STM32 design will differ from earlier designs as I will be using x-tal’s with higher quality and add the RTC x-tal as well. I am toying with the idea of testing a supercap as “battery”. A normal battery has a degrading over time that forces it to be replaced on regular basis. As a RTC battery only need to survive a power down for some time it could be interesting testing a supercap as an option. It is also an option to dedicate one of the available pin’s on the backbone to “Power off battery” and use wakeup functionality on the MCU.

I have also drafted a GSM as optional add-on here. As this will be an external breakout it might make sense to add it to this module rather than creating a separate one. This is however something I need to look into. At present I have little experience using GSM like this.

The RS-X backbone speed will probably be 2.5Mbps, both lower and higher speeds are an option.

PLC – All In One Home Central

A Modular PLC system will have some size & cost, and as a home central should be small, easy to hide and low cost it might be wise to produce a specialized “All In One” solution. The diagram above illustrate the content with “backbone” replaced by a MCU. The C firmware will basically only be a simplified version of what we use on the modular system. The content focus on communication only since we expect distributed nodes communicating through RS-X to perform the sensor/actuator parts.