Reading on the internet about embedded systems, the arduino boards are popular because of the easy way of programming. The embedded software engineers are not enthusiastic about the use of Arduino boards, stronger; some of them are just negative about the Arduino boards. Yes, an Arduino board can be programmed without any knowledge of registers, irq’s and that sort of stuff. For embedded software engineers, this is the main reason to not use an Arduino board for embedded systems.
But then again, is it necessary to know exactly how the processor is working? It was a challenge to make the FSM the way it is at the moment and it’s now possible to create stable controls with the arduino as central processor. Knowledge of the processor hardware is not needed, just concentrate on the functionality of the control you are building instead of worrying about stacks, heaps, irq’s and registers. As written on the home page, the FSM can be used for making a complex stable finite state machine with possibilities to debug the control by presenting the I/O and (active) states on your PC. In my opinion debugging the functionality of a control is just another sort of debugging mostly mentioned by embedded programmers.
Ok, I don’t care how the hardware is working in detail. What counts is the free and stable software for development of the software (everything is made in Visual studio 2015) and the hardware is relative cheap. Ah… just call it an arduino system, everybody happy. If you have another opinion, please let me know. Just curious.
"The drawbridge example"
Long time i was looking for an example for the AFSM and than suddently -talking about the parking places at schiphol airport (AMS)- i decided to choose a drawbridge (?). Parking places at the P2 parkingplace where identified by typical dutch objecs like "wooden shoes", "cheese" and .. "drawbridge". The drawbridge i used for the AFSM example is a typical dutch bridge; with signs for the ships, signs for the road and barriers to hold up the traffic and ofcourse the brigedeck.
Here a simple explanation for the working of the example:
The operator (bridge keeper) has 4 buttons on his theoretical simple desk; 3 request buttons; e.g. "open bridge", "close barriers", "close bridge". The 4th button is the safety stop. In the idle state, the red sign for the ships is activated. When there is a ship waiting for the bridge to open, the operator starts the sequence by pressing the "open bridge" button. When pressed, the roadsigns are activated; the roadsigns exitst of 2 red lamps and are now blinking at a rate of 500mS. It is not possible to directly activate the barriers; the operator has to wait for 10 sec to get permission for closing the barriers. When the cars have stopt for the bridge and the 10s have passed, the request for closing the barriers is accepted and the barriers get a command to close. After the barriers have reached there end positions, the bridge deck motor is commanded and the deck is going to open for ships. Now both signs for the ships are activated; in order to get the ships ready for passing the bridge. When the deck is in the upper position, only the green sign is activated; ships can pass the bridge. After passing the bridge, the operator can make the request for lowering the bridge deck. This request is only accepted when there are no ships present under the bridge deck. When accepted, the bridge motor is commanded to lower the bridge deck. When the bridgedeck reached the end position, the barriers are commanded to open for traffic. When the barriers reached there end position, the roadsigns are turned off and traffic may pass the bridge. The bridge is again in the idle state.
That's all for the working, now the technical implementation of the AFSM:
First of all define all necassery I/O for this control and the possible states of the bridge object:
The naming of the I/O tags is not very professional, just logical names. It applies not to any standard like S88.
- The request button for opening the bridge (reqBridgeOpen)
- The request button for closing the barriers (reqBarriersClose)
- The request button for closing the bridge (reqCloseBridge)
- Safety stop button (Stop)
- Conformation contact bridge open (confBridgeOpen)
- Conformation contact bridge closed (confBridgeClosed)
- Conformation barriers down (confBarriersDown)
- Conformation barriers up (confBarriersUp)
- Input for activate simulation of conformation signals (Simulation)
- Activation of canal signs (signCanalRd & signCanalGn)
- Activation of road signs (signRoadLower & signRoadUpper)
- Activate bridge deck motor (BridgeMotor)
- Direction of bridge deck motor (BridgeUp)
- Activation of barrier motors (BarrierMotors)
- Direction of barrier motors (BarriersUp)
- Distance measurement:
- measurement distance to possible object under the bridge (measBridgeDock)
Possible states of the bridge, the activation of outputs and transistions to another states
The bridge is in the idle state, normal road traffic is possible. The red canal sign is activated. When the operator is pressing the "reqBridgeOpen" botton, two transitions are made; to state "roadSignOn" and to state "WaitToCloseBarriers".
The road signs are activated to warn traffic. The upper and lower road sign blink in a freqency of 500mS. The road signs are deactivated when the barriers are back in the upper position by a transition to the "END" state.
The red canal sign is activated. It is not possible for the operator to lower the barriers directly from the request to close the bridge. He has to wait for an amount of time before the button "reqBarriersClose" is accepted by the control. After the time-out a transistion to "enableCloseBarriers" is made.
The red canal sign is activated. The operator is able to request closing the barriers. When pressing the "reqBarriersClose" a transition to state " BarriersClosing" is made.
The red canal sign is activated. The barrier motors are activated to go down (output "BarrierMotors" is activated, output "BarriersUp" is not activated). When reaching the lower position "confBarriersDown" the transition to state "BridgeOpening" is made.
The canal signs (red en green) are both activated; ships are signaled to prepare for passing the bridge. Command "BridgeMotor" is activated and also "BridgeUp". When reachting to upper position of the bridge "confBridgeOpen", the transition to state "BridgeOpen" is made.
The green canal sign is activated. Ships can pass the bridge. When all ships passed the bridge, the operator may request the closing of the bridge by pressing button "reqBridgeClose". The command is only valid when the distance of the distance measurement to possible objects under the bridge is greater than a given value. When the distance is valid and the button "reqBridgeClose" is pressed, a transition is made to state "BridgeClosing".
The red canal sign is activated. Command "BridgeMotor" is activated. When the bridge is in back in the lower position "confBridgeClosed", a transition to "BridgeClosed" is made.
The red canal sign is activated. Command "BarrierMotors" and "BarriersUp" is activated. The barriers are going up tp there home position. When all barriers are up a transition to state "BarriersUp" is made. In state RoadSignOn a transition to the end state is made when the barriers are in the upper position again.
The red canal sign is activated. Now the bridge is closed for boots and open for trafic and the barriers are up again, a transition to the idle state is made. A new request for opening the bridge can be made by the bridge keeper.
All software for the drawbridge example is available under folder "software".
In the example you can see that a windows popup is created by a click on the process value.
The Raspberry PI3 debug app:
Summer 2017, Merke Wytgaard
Like every year we have a feast in our village called the "Wytgaardster merke". Like prior years i've build a little control in the years theme; for 2017 it was the letter "M". For our street we chose "Mearke". Mearke stands for fairy tale. I had to build something for a fairy tale called "Rixt van Oerd" of the Frisian island Ameland.
Click here for the project
Raspberry PI 3b
The development of the debug application for the PC (Windows 10) is paused for a while. The actual version is stable, there are some improvements possible but they can be categorized as the remaining "10%". Probable extra development is taking lots of time.
But... now i have received my first Raspberry PI version 3b. Goals for the coming period is making the same sort of debug application for the Arduino MEGA on the Raspberry, based on the AFSM as described in the website (sketch interface). The Raspberry is programmed in Phyton. I used Tkinter for making the GUI. At the moment the most basic components are working; When connecting a AFSM sketch to the Raspberry, the GUI is automatically filled with the known tags present/known on the Arduino board. Tags are dynamically updated on the form. The possible states are presented in a text widget, where an active state has a green background and yellow caracters. States are also updated. Masking and forcing is like the VBA app possible by message or by a click on the process value (see the example). I used a monitor for presenting and programming the application; goal was a simple SCA (not DA yet), so i've ordered a HMI screen the size of the raspberry...
Internet of Things
I found the populair ESP8266/ESP-07 WiFi shield. The WiFi shield is communicating via TX/RX hardware serial with the MEGA board. I programmed the ESP-07 module to read data from the board and send it to the internet by Wifi and vice versa. The software for the IoT communication is all on the ESP-07 board. The Mega board software is almost identical to the software where the communication takes place by a bluetooth, USB to serial or radio module (APC220) connection. The great benefit of having the IoT communication software on the ESP shield: the MEGA board is handling the I/O via the hardware serial port which is proved to be realiable in combination with servos, temperature sensors. So, there is no extra software, extra interrupt handling and processor time needed on the MEGA for communication with the internet. It is also nice to program the ESP-07 with the programming language and IDE the same as Arduino. Error correcting -repeating lost or corrupt messages, connection failure- is also handled (ok..., with some data loss in case of the communication problems).
For testing i've build a sketch for measuring the outside temperature and used the VBA IoT debug program on the PC to make a trend of the temperature. In the plot you can see the temperature curve and two extra signals. This red and bleu lines present an output and an input. The input is connected to the output. The output is switched at a frequency of 5 seconds and the input will follow the output signal (as expected). A thick red and bleu line is now painted on the form, because of a plotter interval of 2 minutes. Also visible are some interruptions; the white gaps in the red and bleu lines. At the position of the white gaps, the connection with the internet is disconnected and connected again (loss detection of the 5Hz block wave).
The sketch is now running for several days, no memory leaks, reconnected to internet when there is a connection problem. Altough i find a serial connection more reliable and faster than the Wifi internet, this communication can be used, especially for trending the "slower" analogue proces values on a PC. Remark; the sketch is reliable at all moments, only the connection to the PC/HMI by WiFi internet is less reliable, but still usefull. Ideal for weather station projects or that kind of stuff...
In the HMI screen you can see the amount of reconnects to the internet
(now 452 times, over a period of almost 7 days (1)). Still a lot of interrupts.
The FSM is now stable. Still in test phase, but very enthousiastic about the ESP8266 on the ESP-07 shield.
I've also programmed an ESP-01 module. When knowing how, everything is easy. What a nice modules.
(1) Remark: the start time of a certain Windows 10 process can be determined by the downloadable ProcesExplorer (procexp64.exe).