BasicPI

It is now ca 2 year since I started this blog writing about a Model Train Control System. The system had several newbie issues, but what stalled me was the 40Khz sender I needed for the position system. I never found components with correct size and cost that could do the job. The design itself also had issues. It was to wide, H-Bridge was wrong and mounting the MCU on one side and ESP-03 on the other side created a lot of unexpected interference heat.

Moving on I would like to simpify the design and complete it. I need to return to the position system because I have no working solution for this. It is not only about solving it, but doing it with size and cost in mind.

The first issue is the form factor. It need to be even smaller to fit into the smallest H0 trains, and it need a better connector solution. I used 1.27 pitch holes as connectors, but this decoder is generic and need to be soldered on. I can just about do 1.27 pitch, but most people will struggle with this.

Limiting the design to 12V, no sound, no positioning and no utility functions on main board. I will rather use an extension bus to allow for utilities and sound to be added.

As for MCU I have 3 options. I could go with NRF24L01 and replace ESP-03 using a STM32F030, or I could use ESP12E and control things directly from this. I could also use an 8 bit AVR, but the reason I don’t is because the AVR chips cost 1.50 USD while STM32F030 cost 0.50.- USD. 3.3V also goes better with NRF24L01.

Having Wifi directly requires a router + it is not so great with maybe hundreds of trains running, so I go for the smaller NRF24L01+ breakout bords. Shockburst (NRF24L01) is open, but it is rather easy to create a system that reject non-intended messages.

And one last modification – lets replace those 1206 components with 0603 ones. This was my first SMD design and the small size scared me, but these days a 1206 looks like a large dinosourus.

HMI Designer is reaching a state where I can use HMI Designer itself to design some of it’s content. I can do this because the Designer also embed the Browser allowing me to embed XML based HMI specifications. I am not sure I gain anything, but it will be a good test case for the Browser and help driving it.

My previous entry discuss user gauges as a series of drawings displayed on top of each other. Basically that is what any drawing is and I will need some kind of content list, so the easiest way of dealing with user controls is probably to create this content list and allow the user to select on screen what he/she want to use as a new control.

Any control (also internal ones) need a list fo interface and and spec on how these are used. I think this will work out nice.

Stay with me – this has been a deep dive (large job) so once this surfaces things will change.

This is just an idea, but C++ gauge code is basically a set of layers on top of each other. The idea for user controls is to let the user draw separate drawings – this could be visualized as a text tree, but I consider it as a graphics list/tree. The user can then link a drawing to rotate, zoom scroll based on an input value to create value based animation.

This also questions if I should bother with build in gauges at all – an xml based repository can provide the user with gauges that he can use “as is” or copy&modify. It also opens for others to create add-in libraries, which in previous tools have proven to be a key asset.

Using the clock bewel from earlier I want to add a needle (polygon) and a cap as indicated above. I now want to rotate the needle based on an input value.

Rotation can be done by doing the math yourselves and drawing graphics. The drawback with this is that you use the CPU, so what we will do is to use the build in transform that can rotate, zoom and scroll using the GPU.

So in simple words we just assosiace the rotation angle with an input value and a scale. In this case we rotate the needle layer of our drawing. The advantage of doing this is that we could also rotate the scale (not shown) or use a combination of zooming, rotation and scrolling to animate a value.

The circle above is a “Bewel” often used around a classic clock gauge. Drawing this is straight forward as you draw 3 circles on top of eachother as illustrated below.

I will create some build in gauges, but I think the most important gauge is the one you create yourselves. So I will leave you tools to create your own animated gauges and use them as if they where build in – no coding needed!

Getting there. I am actually starting to see the end of initial framework tasks, so we can soon move on to more interesting and visual content. It’s a lot of work to be honest…

I am happy with using Qt as base. It allows me to write C++ which is optional for this task due to performance and Qt have done a great job integrating OpenGL. So far you only see a 2D content, but you will see the difference as we start with 3D gauges at some point. I have done this without Qt both on MFC/VC++, C#, C++/GDI++ and Lazarus, so I know what I talk about stating that Qt carry it’s weight around on graphics.

The Property Editor is a control that allow a group of “properties” (read data variables) to be edited. Rather than making specialized screens you simply list the variables in a TreeGrid and allow each item to be edited using a specialized editor for the data type. It is a quick way of creating an editor and quite common in modern programming environments.

This editor is quite a lot of work since it also require a lot of other editors to be created. You will probably notice that I am starting with the dark theme with flat controls found in Visual Studio & Windows 10. Actually the theme and style is custom and neither Windows, Linux or OSX. The reason is because most applications today want a recognizable company style on their applications that stay the same regardless of what device or platform you use. I start with my own preference.

A custom style means that you need to create everything from scratch because you need to control every color used. I did this by modifying Windows controls earlier and it was basically more work and less freedom than what I do now. It is a lot more work than just using the build in Windows controls, but it is worth it because the result is a high performance graphics HMI with presentation graphics capable to compete with web applications.

The Property Editor is used to edit objects on the design screen, but is also a component that can be used in user applications. All colors & style setting are programmable per component, but default values are fetched from a theme database. You will be able to create your own themes as well as select pre-made themes.

Finally starting to look like something…

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.

Making an Actuator- or Sensor- Control System require a little bit of software. It is many ways of doing this, but I always tend to use a pre-tested design containing of 4 main parts:

Communication is always required as we either take instructions or send data/progress to another control unit. This is usually also the largest and most complex software component needed. Many designs will implement a communication protocol and the app as just an extension to this. Myself I use an Object Dictionary.

Object Dictionary is a generic database interfacing between multiple applications using the same data. In its simplest form it is nothing but an array between data communication and sensors/actuators mapping data. A more sophisticated feature often needed is data integrity. As communication is capable of writing partly data we need a mechanism to commit or rollback so that the application only see consistent data sets. Another feature is the capability for persistent storage on selected variables or straight forward database queries.

The various user modules are Actuator(s), Sensor(s) and various other modules either using or providing data.

The last bulk of code is the infrastructure with RTOS and utilities.

The main issue here is that this design only need a map of data in the object dictionary, the right modules added and it adapts to any actuator sensor design.