I have a few electronic designs that annoy me simply because I lack time to work on them. The reason is simply to much happening in RL with projects (have to pay the bills) + focus on Software. This one is the worst. It is actually one of my most advanced designs and a very capable Actuator Control System.
I started this partly because I wanted to make my own 3-phase motor controller. But, as I did the design I also added a 4th Half-Bridge, Hall Sensors, Temperature Sensors, End point Sensors, Resolver input as well as the RS-X port. It is much better 3-phase motor controllers than this around, but that’s the point – this is not a motor controller it is a scalable Actuator Control System.
I blogged a lot about MicroPLC/Home Automation lately, and this design fit’s right into this scheme. We can’t use long wires with actuators involved as they need to be close to the objects they control (high currents). A centralized PLC design is not optional in a home that actually need distributed unit’s like this.
I will get down to it, but for now I want to focus on getting the HMI running. One of the first projects will be test applications for these devices.
The concept I will use is that the HMI Browser contact this device and upload the HMI. So all you install on the desktop, phone or tablet is a HMI Browser. This is similar to things you know from classic Web Browsers and HTML5, but the main difference is that we operate on a closed, industrial network consisting of a combination of technologies.
One aspect of easyIPC that I have not mentioned is that you have a set of HMI & devices that actually are a closed, industrial loop. It is not connected or available to internet or the outside world unless you want it to. Neither will you be able to connect any phone or tablet if it is on Wifi – the devices will need to be enabled from inside (white listed).
The diagram above is a minimum PLD function similar to classic, empty functions. The only challenge here is lack of executable details.
This 2nd diagram show one way of presentaing executable details. This is key to our success, so we need to work a bit on this.
This last diagram show a possible single-step debugging technique. Notice that we display variable values and highlight diagram parts that is the next step. Again – we need to experiment a bit with this to see what works and what doesn’t.
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.
I still got a few components to make\upgrade before I have a full Home Automation network. The CCM and RSX module allows me to create a central, but I need sensors and I need to feed the sensors power. One solution to this is to create an active RSX Switch with power output on each network.
The RS-X Switch as drawn here will take 2 x Ethernet or 2 x RS-X (M1 & M2) input and provide 4 x RS-X output with power. Each of RS-X E1,E2,E3 & E4 can be switched on/off separately and be used for networks or 1:1 with sensors/actuators.
The functionality in the switch is simple message switching. The idea of having 2 x Ethernet and 2 x RS-X Input is redundancy, but I realise this might be a bit tight to achieve so will see what pins & space I have available.
This module will also be a great RS485 Hub used stand-alone.
3D of a 3-port RS485 GW. This actually have 5 RS485 (or RS-X). 2 on the backbone bus running high speed, and 3 isolated with lower speeds in front. These can be used Standard RS485, RSX or even Profibus/485.
The MCU is actually capable of running 3 port Profibus using UART’s saving the need for specialised hardware.
This module do not have the Raspberry PI Zero W add-on option. The reason is because the connector would conflict with the isolation area.
Added 2 coils on the 16 x Servo Module as well. On this I have plenty of space. I should have moved the MCU a bit down, but I will leave it for now.
This module provide output only, meaning it can not do generic IO as my previous 32xServo/IO could. The limitator is the opto couplers providing a full galvanic isolation. It can still do digital output and low frequency PWM (< 100Khz) in addition to Servo signals.
Servo PSU is selectable from 5, 12 & 24V by jumper. Signal is also selectable from 5, 12 & 24V by Jumpers. The MCU 5V is separate from the Signal/Servo 5V etc.
It is also has a 4 pin HMI – the same as on the CCM board. I simply did not see any point in removing it + might be cool for demo/testing.
Doing 16 channel Servo on a STM32F405RG is well, the reason I use a M4 is the speed of the backbone bus.
Not very exiting – just added the 3 extra 15uH coil options I mentioned earlier on the back. As mentioned these are added because I suspect I need them to separate 5V PSU to different high frequency modules. The issue, as we learned earlier is that these freuencies interact. The coils here simply let 5V through but stop higher frequencies – it cost me little to just add the space for these on the back side.
I have a weird package error on the 25 Mhz crystal that I need to check, otherwise this is ready to go.
Also starting to use “CCM” (Communication Central Module) as name on this because it contains Ethernet, GSM, GPRS, GPS, WIFI, Bluetooth, USB++
I updated the module list again – don’t worry – this will not be the last change here.
CCM (Communication Central Module) is the new name for the combined Ethernet, Wifi, Bluetooth, GSM/GPRS, GPS, RPI Module. I packed so much into this that it covered 3 planned modules.
Servo Controller Module was illustrated earlier.
I need to work on PSU/Battery.
3 x RS-X Module comping up.
8 x Analogue Input Module coming up.
PWM Output Module coming up.
Digital Input Module coming up.
DC/Stepper Controlles – we probably talk several modules here.
Sound I/O – now this becomes interesting. We have so far talked about a PLC that control robotics, but we could easily talk about a system that also does sound processing… I am very, very thin on analogue electronics, but some interesting options here.
These two diagrams show drafts of analogue data acquisition modules. The first is a 8 channel 24bit @30Ksps while 2nd is a 16 channel 12bit at 2,5Msps.
The ADS1256 is available for ca 5.- USD and provide 8 channels with 24 bit resolution at a sampling speed of ca 30ksps. This is very good for an ADC with this high resolution.
The faster ADC technique is achieved by using the ADC’s integrated in STM32 directly. These are 12 bits, but have a much higher sampling rate capability (2,4Msps).
I am not sure if I want to make both boards + I need to dig in a bit on analogue scaling & calibration options. I also need opto isolators that have limitations of their own. I also have the issue that the higher frequency of the 12 bit is of little usage + 12 bit resolution is a bit low for sufficient accuracy. Assuming I have space I could actually extend the 24 bit board with a few faster 12 bit channels as well.
Learning from my experience with a 168Mhz MCU interfering with a 180Mhz DC/DC I realize that I might need a similar option to separate the 4V PSU feeding the SIM808 on the module pictured above. In this case I would need a larger 2-3A coil related to 13 (4V PSU) above. This being a single side assembly I will add an optional connector for this on the back-side just in case.
Ethernet (W5500) already have a coil separating it’s 3.3V from the MCU.
Raspberry PI Zero W also feed from the same 5V – I need to add a coil option for this as well. What I will do is to add a connector that is shorted so that I can cut this and introduce an inductor if needed.
The last one is the 3.3V for the MCU itself. It feed from a 5V PSU that will feed several cards all running a 168Mhz MCU. I hope the linear regulator will do the filter job, but I will add an optional coil here as well – just in case.
I might also add some scope test-points + I will re-examin the SIM808 design – but after that I will order the PCB so I can start. I have to be realistic and expect that I will need 3-4 revisions before this module is working properly due to it’s complexity. I have evaluations boards we can connect to play with SIM808 SW – I actually need to get a new subscription with a few SIM card’s for testing.