I think I'm still missing what your primary aims are. I thought you wanted to build a web server with dynamic content on the web pages which shall be process values e.g. displayed as numbers or bar graphs. So therfore you would simply need e.g. Java applets doing a read in the process image. In case of a power loss the system starts up and would display the current process values. What would you need any old process values for? Process values are always updates cyclically (e.g. every 10 ms) so you always do have current values in the process image. Which kind of values do you have in mind when you want to store things permanently?
Generally the type of format to store variables in files would depend on the language you are using. Different languages do have different ways of reading and writing data. It also highly depends on what grade of usability you expect for debugging your software. Having plain text in file allows to read the data using a simple text editor. Having binary formats needs tools to read the data. So please give us a little more information and we might understand more what you are aiming to and how you could reach your aims the easiest way.
c++ app web interface
Unser RevPi Motto: Don't just claim it - make it!
Sure you are very close 
. Im am working it out as i go and slowly beginning to see how it may work.
The main reason i need to have some saved valuse is for uesr setting e.g temperature setpoints, cycle time, alarm levels, etc. I would like to have these backed up to a USB i case of hardwear malfunction.
Currently what im working towards is having a c++ app running the mechine logic e.g switching of pumps, valve , taking readings of sensors. Im doing this in c++ to gain more knowledge in c++. By using this separate app im hoping to also have a level of redundancy that should the web server stop working the the app carries on functioning with the last settings.
This app would then write a file in json(not plain text anymore after doing so testing) with all the varbles needed to be used in the web page.
I would like to use node.js over apache for the server. For the dynamic loading and updating values and asynchronous benifits.
The web page will display the data that has been sent from the c++ app via json to show values of sensors, staues of pumps, manual overrides buttons, etc. When a button is pressed to over ride a motor lets say then a second json file would be made or updated to be readed by the c++ app that then turns on the output on.
So far im seeing a benifit of using a file over a pipe as a file is non blocking.
There is a good chance in over complicating the simulation. Im very intrested to know your thoughts on the over all flow of the solution. To see if im on the rigth track or not !
Thanks agin
. Im am working it out as i go and slowly beginning to see how it may work.The main reason i need to have some saved valuse is for uesr setting e.g temperature setpoints, cycle time, alarm levels, etc. I would like to have these backed up to a USB i case of hardwear malfunction.
Currently what im working towards is having a c++ app running the mechine logic e.g switching of pumps, valve , taking readings of sensors. Im doing this in c++ to gain more knowledge in c++. By using this separate app im hoping to also have a level of redundancy that should the web server stop working the the app carries on functioning with the last settings.
This app would then write a file in json(not plain text anymore after doing so testing) with all the varbles needed to be used in the web page.
I would like to use node.js over apache for the server. For the dynamic loading and updating values and asynchronous benifits.
The web page will display the data that has been sent from the c++ app via json to show values of sensors, staues of pumps, manual overrides buttons, etc. When a button is pressed to over ride a motor lets say then a second json file would be made or updated to be readed by the c++ app that then turns on the output on.
So far im seeing a benifit of using a file over a pipe as a file is non blocking.
There is a good chance in over complicating the simulation. Im very intrested to know your thoughts on the over all flow of the solution. To see if im on the rigth track or not !
Thanks agin
just a update so you do not waste your time. I have been playing with node.js and i am seeing how using node.js and help me better now. Currently i am trying to use a socket in my c++ program to communicate with the server.
Yes, please do use sockets. They work like files but they are kept in memory instead of using the eMMC. So you save life time of your eMMC doing so.
For the values which need to be retained (e.g. set points etc.) you may use eMMC files instead of sockets.
And if you do need direct IO values in your node.js environment you could well read directly in the process image using the piControl file-like interface to do so. C++ and node.js could read in parallel from the process image while it would be wise to let only one of them write to it.
For the values which need to be retained (e.g. set points etc.) you may use eMMC files instead of sockets.
And if you do need direct IO values in your node.js environment you could well read directly in the process image using the piControl file-like interface to do so. C++ and node.js could read in parallel from the process image while it would be wise to let only one of them write to it.
Unser RevPi Motto: Don't just claim it - make it!
sound good ! thanks you for you guidance. It has really helped me to clear out my head.
From what i understand the raspberry pi is sensitive to power cuts without shutting down first. I believe it may corrupt the memory. Have you guys taken any measures to help with this ? or should we be using a small UPS for protection ?
From what i understand the raspberry pi is sensitive to power cuts without shutting down first. I believe it may corrupt the memory. Have you guys taken any measures to help with this ? or should we be using a small UPS for protection ?
Please do forget this! It is one of the urban legends which has its roots in past versions of the original Raspi and in wrong assumptions. The Raspi foundation has done a lot research in it at they found out that most of the reported cases are due to low quality SD cards. With high quality cards Raspi user would never experience such problems. The developers of the foundation had a meeting with us in Cambridge and told us that they themselves never had a single case of lost SD card content due to power shut off since they started using high quality SD cards.
With the RevPi things are totally different: The built in Compute Module does not use consumer SD card technology but eMMC chips which do have a perfect built in power down protection circuit. KUNBUS developers are using Compute Modules for more than 2 years now. Every day they reboot our RevPi systems by unplugging the 24 V power supply dozens of times. We never ever had a crash of the eMMC because of doing so many thousand times. We also have thousands of systems out there and none has been returend to us because of a crashed eMMC. We also have not a single report that users had to reinstall their image because of a power loss. Check the internet and you will only find one obscure case of a single person reporting he would have destroyed several dozens of Compute Modules 1 by shutting off power. So our actual experience is this: There is no evidence that you take an appreciable risk to destroy your file system when switching off the 24 V power supply without prior executing a regular system shut down. But there could be many more reasons not to do so in a control system: You might have safety reasons to turn your system down in a controlled manor instead of risking an unpredictable system state.
With the RevPi things are totally different: The built in Compute Module does not use consumer SD card technology but eMMC chips which do have a perfect built in power down protection circuit. KUNBUS developers are using Compute Modules for more than 2 years now. Every day they reboot our RevPi systems by unplugging the 24 V power supply dozens of times. We never ever had a crash of the eMMC because of doing so many thousand times. We also have thousands of systems out there and none has been returend to us because of a crashed eMMC. We also have not a single report that users had to reinstall their image because of a power loss. Check the internet and you will only find one obscure case of a single person reporting he would have destroyed several dozens of Compute Modules 1 by shutting off power. So our actual experience is this: There is no evidence that you take an appreciable risk to destroy your file system when switching off the 24 V power supply without prior executing a regular system shut down. But there could be many more reasons not to do so in a control system: You might have safety reasons to turn your system down in a controlled manor instead of risking an unpredictable system state.
Unser RevPi Motto: Don't just claim it - make it!
