I have a problem with my five CR10Xs which are connected via IP through NL100s. They do a great job of keeping data flowing back to LoggerNet, but when I need to install new software on the CR10Xs, they will not stay connected long enough to finish the process. I've always had to rely on the COM210 phone modems we used in the past to send programs. Two of these stations are plugged directly into the company network, and all five of them can be pinged with no apparent problems. Maximum time online is set to zero (no time limit). I've tried different packet sizes and extra response time. My IT department has tried communicating with them via half-bridge, full-bridge, and auto detect, none of which seems to make any difference. I've been wondering if this might be a cause of the problem I've had with duplicate data being downloaded, so I'm revisiting the issue. Thanks for any advice.
Alex
Alex,
I used NL100s with CR10Xs over a wide area network for several years and never encountered this problem. We used to send new programs to the dataloggers without incident on several occasions so the process can work. Even downloading large amounts was data was not a problem. A few suggestions though:
1) are you using a reserved address space in the router that the NL100s are connected to?
2) I don't know how often you download data but do you turn off scheduled collection while uploading a new program?
3) be sure to check overrun and other errors on Mode B and check memory allocations.
Larry
Thanks for the reply Larry, I'm glad to know that this can work.
The five stations are all on static IPs 192.168.22.21 through .25.
I always pause the schedule for the entire network when uploading or downloading data and programs.
I get the occasional program overrun, maybe once or twice a week. Not exactly sure what you mean by checking the memory allocations, but I have these loggers setup to use the default FSA1.
I feel like this must be a datalogger issue, or some configuration in the way the NL100 talks to the CR10X, or perhaps a LN setup problem. The communication history of the IP port looks great, the communication history of the datalogger doesn't look so great. The NL100 can be pinged with no problems. Below is the results of some testing I just did.
Pinged station for five minutes, getting 32 byte replies in 3-8ms, TTL=64.
Tried to connect via Connect screen in LN, got following error:
Failure: 12/14/2010 09:03:21.100
Classic::CmdA
Unpaused the network schedule, the station polled data without any difficulty.
Repaused the network schedule, connected via the Connect screen, after 50 seconds the connection failed with the following error:
Failure: 12/14/2010 09:09:46.899
Classic::CmdClockSet
I unpaused the schedule and then received the following error, presumably while the connect screen was trying to connect in the background:
Failure: 12/14/2010 09:11:10.337
Classic::CommandG
I then paused the schedule again and successfully connected to the station for 51 seconds before getting the following error:
Failure: 12/14/2010 09:16:48.292
Classic::CmdClockSet
It seems fairly random which error message comes up and I've never found them to be much help in diagnosing the problem.
Alex
I would suspect issues of network latency, so increasing the Extra Response Time for the datalogger to a few seconds should help. Also, when you try to send programs, pause the clock check in the Connect window until you are finished.
In regards to the error messages... With mixed array operating systems, the software will first send out an A command to get the datalogger's status line. If you are trying to collect data, it will send out a G command to go to a specific reference pointer (last data collected pointer, as indicated by info from the A command), and then it will start sending F commands to retrieve that data. Intermingled with all that will be the Clock check commands sent out by the Connect window. That's a lot of traffic over a slow network. So... your failures mean that on one attempt, the software could not even return the status information. On another, it failed when trying to get the clock, another, when trying to move the data collection pointer. This would indicate to me that there is no specific failure point, which is why I wonder if it is network latency.
Dana W.