In the new standard, serial3 is used for communication between boards. It must be activated by setting the global boolean UseIntercard to true (Userconfiguration.h). At the end of every FSM cycle serial3 is checked on available data. If there is data, just one message will be processed each time (leaving available data for the next cycle). By processing the message, one of the global variables for intercard communication is set for just one cycle in the FSM loop. After one cycle all global strings are blanked. It is possible to send 4 different messages to another board; @CHAR01 followed by one character; @CHAR10, followed by max 10 characters; @INT001, followed by just one number and @INT003, followed by 3 numbers. When receiving an Intercard message, the following global strings are set for just one FSM cycle; IntercardChar01, IntercardChar10, IntercardInt001 and IntercardInt003 (depending on the "expected" Intercard message). While using this communication, be aware to check on the globals while running the cycles (it is easy to miss the message).

At the moment the software is in a test phase. A possible application of the Intercard protocol is project "Notification call systems". See under "Projects" for the full description or click here.


figure. simple Intercard communication. 

Untitled Sketch 2 bb






embedded system

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.




Click here for a link to section HMI/GUI Raspberry Pi3 for more information


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...


ophaalbrug3   "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.

  • Inputs:
    - 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)

  • Outputs:
    - 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

  • Idle
    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".
  • RoadSignOn
    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.
  • WaitToCloseBarriers
    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.
  • EnableCloseBarriers
    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.
  • BarriersClosing
    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.
  • BridgeOpening
    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.
  • BridgeOpen
    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".
  • 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.
  • BridgeClosed
    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.
  • BarriersUp
    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