Hi,
I have a CR800+NL201 connected to a Moxa switch, which in turn is connected to a satellite terminal. The logger controls the power to the terminal to facilitate periodic callbacks to a loggernet server. This is being done using the TCP client connection setting, so that the logger maintains (well, restores) the connection once the satellite internet connection is up.
This works fine for about 2-3 hours, then the logger ceases to try to reconnect to loggernet... therefore, callbacks fail, and data does not get collected.
To correct this, the program needs to be restarted. I've tried using EthernetPower(), but that doesn't help.
Am I missing some setting which the logger uses to govern how it deals with intermittent network connectivity?
What OS/firmware versions are in the CR800 and NL201? Is the NL201 doing the callback? Is it connected to the datalogger in bridge-mode? If the datalogger is doing the callback, are you using the TCPClient connection setting or is the datalogger doing the callback using a TCPOpen under program control?
Sorry, neglected to mention - Unsure of the NL201, but 99% sure it's the latest. It's in bridge mode, the logger is performing the callback (using SendVariables()). The Logger is 28.02 (this is our internally approved/tested OS, so would prefer to stay there if possible, but if this is a known bug then we can upgrade if required).
The connection is configured as a TCPClient connection setting.
I've made some program changes today to reduce the amount of IP activity on the local LAN segment which seems to have improved things, but I'm not happy to consider it solved until I have a good week+ of no problems. Things changed were:
1) There is a SlowSequence scan that checks the sat terminal's signal level and data throughput using HTTPPost() - it now correctly only tries to check when the terminal is powered on. (boolean check on one line needed to be broken into two with an If/EndIf conditional wrapper).
2) The callback retry code was improved to be slightly less agressive after the first failure - but this shouldn't affect it, as the failure would need to occur before the old agressive behaviour started.
Mike,
I will do some checking with a satelite modem when I get into the office in the morning and let you know what I find. I will try OS 28.02 and OS 30.1 to see if there is a difference. Thank you for the details.
I do know that the TCPClient setting in the datalogger using OS 30 is fairly robust. I have a test where I have a datalogger with this setting set to reconnect to my LoggerNet server. I rotate between a PPP connections, a WiFi connection, and a Ethernet connection every 15 minutes with one 15 minute segement with all my connections turned off. TCPClient has been able to re-establish a connection to my LoggerNet server without a reset or reboot.
I am also using SendData() instead of SendVariables().
Thanks Gary. I'm using SendVariables() as so:
SendVariables(CallbackResult, -1, -1, CallbackAddress, 0, 1000, "Public", "Callback", true, 1)
My program was trying two HTTPPosts every 10 seconds (which cause a skipped scan on timeout - there's no timout option for HTTPPost()), to the terminal address - if you create a slowsequence doing this to a non-existant IP on the LAN segment, perhaps that was causing it.
Secondly, the program was bringing up the terminal, and pinging google DNS (8.8.8.8) until 5 consecutive attempts succeeded before proceeding to a callback. Post callback, the loggernet server uses cora to set a "collectioncomplete" variable which signals the logger it's able to bring the link down (taskmaster, "After Callback" event).
Quick update - started failing again after ~6.5 hours.
Mike,
Thanks for the updates. I have just started my testing. I will let you know what I find.
For your FYI, time outs were added to HTTPPost, HTTPGet, EmailSend, FTPClient, etc. in OS 29.
Gary - I'll be interested to see what you find. I completely commented out my slowsequence with the HTTPPosts after the 6.5hour failure, and it still fails, so there's something else going on.
A workmate and I looked at the OS30 changes, and there's enough in there about TCP that we've decided to give it a try to see if it corrects the issue.