I got an email with some questions about the timers. In the previous version of the standard, there was a side effect with the timer structure. The main problem was that all actions performed on the timer queue are processed when the timer functions are called within the states of the machine. In the new version this is changed, together with some improvements. The main changes:
- After a timer expires and the function Timer is called, it will be true for one cycle (one-shot). The difference with the previous version, is the removal of the timer entry from the timer list. This is now done at the end of the cycle and not by the function Timer.
- There is a new function called DelayTimer. DelayTimer will result in false when not expired and true when it is. The timer entry remains in the system as long as it is not excplicited removed from the timer queue with the CancelTimer function.
- There is a new function called RestartDelayTimer. When called, the timer entry is initialzed.
- The CancelTimer function is unchanged.
See the pages, describing the functions; menu/standard functions.
So when this problem occured, i build additional logging in the python script. Conclusion: after some time, the normal received ascii characters by the raspberry are replaced by corrupted bit strings like 'b/x00/x00 types. The python script is not accepting these information and the HMI screen is stalled. Information is still received but cannot be processed by the raspberry to fill the beautiful HMI screen.
- a special thread is receiving data from the USB port as long as there is data available. The thread is looking for special terminator characters and then strings (MEGA2560 messages) are put into a queue, to be processed by the main thread for the HMI screen.
- the main thread is looking at the queue and is processing the queue messages when there are message available. After reading from the queue, the HMI screen is updated or whatever action is required
- I analyzed from the logging after the moment the communication seems to be currupted, that i got an error reading the message queue; the qsize seems to be greater than 0, while reading from the queue results in an error; queue.empty is true!
I know, it's a work around... but after the error, reading the queue, the serial communication channel is now closed and opened again; everything is working again, but some messages must be lost between closing and opening the connection.... The new software release is available in the first week of october 2018 on the download page.
"Suddently" is not so random, it seems to be a fixed time of 90 seconds (the same time at different baudrates of 9600 and 115200)... if someone has the answer to this communication problem, help!
The next upgrades are implemented per Aug 27, 2018.
- The reading of ultrasonic HC-SR04 (standard ultra sonic device) is now programmed in the sketch itself. The NewPing library is not longer used.
- Performance issue: Message @CHM, Cancel HMI Messages is now part of the standard. When closing the debugger form (trigger "closing" in VBA), the message is send to the board and all poll and report messages are cancelled. Not yet implemented on the raspberry pi platform.
- Possible to subscribe to the AFSM newsletter. Newsletters will be send by mail when there is important news or new/updated downloads (probably once per 3 months). Subscribe at the home page! Your e-mail adress will not be used for other purposes and will not be copied to others.
The communication between the MEGA2560 and HMI (Scada) on the PC is communicating via Wifi. To keep full capacity for the AFSM on the MEGA board, the communication is pratically the same as the version with serial connection; TTL/USB, blue tooth or e.g. the APC220. The hardware serial connection of the MEGA is connected to an ESP8266 (separate card or on board the MEGA). The ESP is taking care of the network communication.
- The ESP8266 is now connected at the TX3/RX3 hardware serial port of the MEGA board, at a baudrate of 115200.
- The queue mechanism in VBA for resending lost message can be turned on/off. In some situations, messages can be lost occasionally (like trending). In such a case you can turn of the VBA message queue. It is done by an extra command line parameter: "C:\.....\FirstProject.exe" /ipadress="192.168.178.178" /port=1500 /que=ON (or OFF).
- The ESP8266 is receiving and sending the "@" messages for communication between the board and VBA. When it is not a "@" message, the ESP messages and information is printed at the serial monitor from the MEGA board. At the startup of the ESP, all messages, like network scan, IP-address and server messages, are now printed for debug purposes.
- Build in watchdog for monitoring communication with the PC (LED13 is blinking in a frequency of 500mS, at the off period there is a little blink indicating the communication is working).
The software is tested on a MEGA2560 with an onboard Wifi and a MEGA2560 with a separate ESP8266. See also the picture below.
This years theme (2018) for the festival in our village called the "Wytgaardster merke" was "Wybiza" (like the party island Ibiza). So, i made a control that fitted the theme; an automatic limonade cocktail bar. You can find the details under the projects part of the website.