Propeller with Pink in datalogging application - Pink webserver dies
Jufra
Posts: 24
Hi all,
I created an application where a propeller is monitoring a flow meter (for liquids) and internally logging the pulses that come from the flow meter.
The prop is connected to a Pink module to communicate some data to the intranet.
The prop chip writes updated values (average flow, peak flow etc) to the NB_vars of the pink every second. The user of the system can then log on to the pink and look at the website and display the values (it is an auto-reloading website that also uses some javascript).
At the same time the propeller also send the data via udp to a remote server for logging, also every second. This server listens to the udp packets and writes them into a csv file (this is for producing offline charts etc). The packets are very short, they have 8 bytes each.
So this all works fine most of the time. There are however some issues that I have noticed, sometimes they happen after a few minutes, but mostly after a long time, such as 10-12 hours. Here is a list of those issues, and my question to all is whether there are known issues on the pink:
Facts: I'm using Firmware Version: SB70 Parallax Web server 1.33, the code on the propeller to talk to the pink is from the OBEX, called PinkV2:
**************************
* Pink V2 object v1.2 *
* Coded by Peter Verkaik *
* Date: December 19, 2007 *
***************************
and I'm also using the F u l l - D u p l e x S e r i a l D r i v e r v 1 . 2
1. It so far has happened once that out of the blue the UDP destination address was reset, ie, it just went back to NA (or empty), there was no external setting at this time. I have read in another post that the first email address variable can be reset due to a bug.
Question: Is this known to be the case for Nb_var_BI? After I set the address again, the udp was working
2. I have twice encountered the situation that the udp was happily firing away and sending a packet every second to the remote server, but the website which the users looks at suddenly stopped working. There was then no http connection possible, just udp worked and ping. I also wasn't able to ftp or do telnet to
the pink. Powercycling the pink fixed it and it worked again.
Question: are there known issues with the stability of the webserver? Is it too much to send updates to the pink Nb_vars and also udp at the same time every second? I hope not.
Or could it be that the webserver has a fit when the Nb_vars are read at the very same time when they are written to by the prop chip?
3. Sort of a minor issue. The prop sends the udp every second, but as it is using many cogs, there is a mechanism built into the code that it doesn't read and send the data on udp when the other cog still writes it to avoid corruption. It all fires off ok, ie, data is sent every second, but after a few hours
it happens that the data is sent only every 2 seconds. First I thought maybe due to timing, my corruption mechan.on the prop has triggered and it skips every other second, but then when I only powercycled the pink, it was sending again every second. so I assume the propeller was sending the data every second, but the pink wasn't sending it.
Maybe some timing issues due to my code on the prop, but why would it work after I restarted only the pink? Are there any memory issues known on the pink?
This is a really big issue for me as this system will have to go into a customer installation in a big hospital here in Australia. I need it to be rock solid as this is also a showcase project for our technology.
So I'm humbly asking for some help with this, it will be greatly appreciated.
Thanks!
Cheers
Frank
I created an application where a propeller is monitoring a flow meter (for liquids) and internally logging the pulses that come from the flow meter.
The prop is connected to a Pink module to communicate some data to the intranet.
The prop chip writes updated values (average flow, peak flow etc) to the NB_vars of the pink every second. The user of the system can then log on to the pink and look at the website and display the values (it is an auto-reloading website that also uses some javascript).
At the same time the propeller also send the data via udp to a remote server for logging, also every second. This server listens to the udp packets and writes them into a csv file (this is for producing offline charts etc). The packets are very short, they have 8 bytes each.
So this all works fine most of the time. There are however some issues that I have noticed, sometimes they happen after a few minutes, but mostly after a long time, such as 10-12 hours. Here is a list of those issues, and my question to all is whether there are known issues on the pink:
Facts: I'm using Firmware Version: SB70 Parallax Web server 1.33, the code on the propeller to talk to the pink is from the OBEX, called PinkV2:
**************************
* Pink V2 object v1.2 *
* Coded by Peter Verkaik *
* Date: December 19, 2007 *
***************************
and I'm also using the F u l l - D u p l e x S e r i a l D r i v e r v 1 . 2
1. It so far has happened once that out of the blue the UDP destination address was reset, ie, it just went back to NA (or empty), there was no external setting at this time. I have read in another post that the first email address variable can be reset due to a bug.
Question: Is this known to be the case for Nb_var_BI? After I set the address again, the udp was working
2. I have twice encountered the situation that the udp was happily firing away and sending a packet every second to the remote server, but the website which the users looks at suddenly stopped working. There was then no http connection possible, just udp worked and ping. I also wasn't able to ftp or do telnet to
the pink. Powercycling the pink fixed it and it worked again.
Question: are there known issues with the stability of the webserver? Is it too much to send updates to the pink Nb_vars and also udp at the same time every second? I hope not.
Or could it be that the webserver has a fit when the Nb_vars are read at the very same time when they are written to by the prop chip?
3. Sort of a minor issue. The prop sends the udp every second, but as it is using many cogs, there is a mechanism built into the code that it doesn't read and send the data on udp when the other cog still writes it to avoid corruption. It all fires off ok, ie, data is sent every second, but after a few hours
it happens that the data is sent only every 2 seconds. First I thought maybe due to timing, my corruption mechan.on the prop has triggered and it skips every other second, but then when I only powercycled the pink, it was sending again every second. so I assume the propeller was sending the data every second, but the pink wasn't sending it.
Maybe some timing issues due to my code on the prop, but why would it work after I restarted only the pink? Are there any memory issues known on the pink?
This is a really big issue for me as this system will have to go into a customer installation in a big hospital here in Australia. I need it to be rock solid as this is also a showcase project for our technology.
So I'm humbly asking for some help with this, it will be greatly appreciated.
Thanks!
Cheers
Frank
Comments
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
If it does not beat against the feature of beeing "supersmall and embedded" I would even consider using a tiny linux-PC as the webserver.
Did you contact the technical support of parallax? I think they a highly interested in making you satisfied with their product.
best regards
Stefan
thanks so much for your replies so far. Yes, localroger, I had also thought about what you suggested as the root of the problem, some resource lockup issues. Makes total sense.
Initially I had also considered transients as I had the whole prop chip dying on me, but later I discovered my code had caused memory corruption. Basically I agree, a transient wouldn't cause just the webserver to go down, this issue here is a firmware problem.
Stefan, I will contact Parallax support for sure. Haven't done so yet.
What you suggest sounds good, I do have a little SME server based machine that receives the udp packets for logging and it runs a number of scripts to produce charts ertc etc. It can be put onto a single board PC which can be placed in the box of our equipment, however, at the moment it receives the udp data from the pink.
So:
Propeller
> PINK
> Server PC
serial udp
I guess you are suggesting to scrap the Pink and talk to the server PC directly (which would have to run a webserver app)
I am not sure how to interface the propeller to a PC. How would the serial connection to the PC work?? FullDuplexSerial? What to run on the server side to receive the data?
My biggest issue is R&D time, there's only 2 of us running the business, and we need to take care of everything, so
time's very limited. Took me a long time to get the pink going with all the functionality, and since it works and does exactly what we want, I definitely
would like to stay with it. But of course not if the stability isn't up to scratch.
Thanks to all again, very grateful for more input
Frank
On the prop-side you can use fullduplexserial on the PC-side even excel can be made to receive data from a serial port.
A lot of serial terminal-programs have a logfunction. But then you have to have another software to build the webpage.
What I know personally is that it is quite easy to write a small software in delphi that can receive the serial data and send udp-data
Somebody who has experience with a program-language like delphi, java, c++ will need a day or two to make this work.
So the pink would be replaced by this software that would run on the SAME PC as the webserver
It's no problem at all to send and receive udp-packets on the SAME PC
Sound a little bit like from the back through the heart into the eye but would need less development time as develop a webserver that can receive
serial data
best regards
Stefan
seems like we can speak German, hehe
Ok, thanks for your ideas, that's great.
There are two parts in our application,
1. First one is the prop sending data to the pink webserver (ie, it updates the NB_vars), and the Pink webserver renders the website
2. Second one is the prop sending udp through the pink to the server (it's different data as in 1)
(I think you slightly misunderstood me, the udp data is never going to a webpage, it is only received to create remote logfiles (which are later processed into charts))
I understand that for 2., I can use a serial port monitoring program on the server (actually I found one written in Perl, which I'm comfortable with), and then shoot out udp packets which are received by the same box and do my logging.
However, I could also receive the serial data on the server and log them straight away w/o using udp, I think that part of my logging SW does not need much modification other than deriving the data from serial rather than udp. So this part doesn't cause me many headaches.
But point 1. is not so clear to me. I would receive serial data on the server (which now replaces the pink webserver) and this data would need to go into a website. Can this be done through CGI? (Sorry, my CGI knowledge is less than minimal). How is serial data stored so that another script can pick it up and build a website?
I'm digressing from my original question, I know. But since I like your suggestion, at least as a backup plan if the firmware cannot be fixed, I thought I keep digging into it...
Many thanks, and btw, I have asked Parallax support now, see what they say
Frank
I have even less knowledge about CGI than you. Without knowing ANYTHING about dynamic websites another "von Hinten durch die Brust ins Auge"-idea would be that a software writes the *.html-file with updated data
again and again and again. If a harddisk can stand continously writing to the virtualmemory pagefile this shouldn't be a hardwareproblem. I don't know anything about perl. I'm familiar with delphi. In delphi it is possible to
search for other applications through the name of the window or a kind of ID. If you have this ID it is possible to send messages to this window or even to GUI-objects like edit fields. But I have NO experience if this is
reliable to work for months non-stop with a new message every second. Another idea even like
"Spaceship enterprise sends the emergency energy back through time it will be reflected by a singularity back to future to the other end of the ship where the enegy is needed"
is to use Autohotkey to read in the data from *.txt-files and send messages to a browser-window simulating typing in the data and click on "update page" (all done by autohotkey
So in todays PCs the ways to transport data are in fact as various as transporting energy through spaceship enterprise
So if you ask in a CGI-forum can a CGI-script read in textfiles and then delete the textfiles this would be an option.
By the way I have realised things like that in PC-based industrial controls to store received data and it has worked reliably for years.
But it was VERY important to make really sure to DELETE the files after processing the data. Otherwise the harddisk would be filled with hundredthousands of small textfiles
which makes windows go down on its knees.
Another idea is to name the textfiles Data001.TXT .. Data999.TXT and then rollover to Data001.TXT again. So if an old Data001.TXT-file should still be there it simply gets overwritten by the new one.
best regards
Stefan
Working with Files
So it seems that perl can handle files easily.
I have downloaded ActivePearl but it seems to be a bit more complicetd than to start an exe.
I did a quick cross-reading at self-html and it seems to be nescessary to first setup a local webserver like apache and
then configurate the webserver and the perl-script engine.
As this is not propeller-related anymore I continue questions about perl and webservers in the sandbox
best regards
Stefan
just wanted to let everyone know that Parallax support have come back to me with a firmware upgrade, they have fixed a number of things and the firmware they gave me was 1.35 beta.
Works like a charm now.
However, i'm still keen to give the serial solution that Stefan suggested a try... if time permits it
thanks to all again
Cheers
Frank