I have a couple of questions I am hoping somebody is able to assist with
We have LoggerNetadmin installed on a Server 2008 platform colelcting data from a variety of comms paths including TCP/IP phone modems and radio.
Are there any issues with loggernet on this platform?.
The issue I am having is the system is unstable and is crashing regularly
To achieve comms to the serial devices we are using a Belkin Network USB hub with usb to serial connectors. This is not supported for servers 2008 so I am thinking maybe part of our problem.
Could anybody recommend something similar? We need a serial connection over our netwrok as the server and radio are in differnet parts of the building.
When the system crashes it does so in three ways!
first the system simply reboots with no real signs of the errors in the event logs or the CSI log files although any suggestions as to what to look for would be appreciated
Secondly loggernet looses connection to the Localhost? I have seen this on both the Staus monitor and task scheduler. Any reason why this happens? or circumstance that this would occur?
Loggernet will not then shut down and requires the machine to reboot.
The third fault is with the belikn control center where the comm ports are frozen, this is corrected by reconnection.
I am not currently running Loggernet as a service as it would not detect mapped network drives that I use for data storage. any work around to this? I understand it is a common problem with running service applications. If there is significant gains running as a service I can re arrange the data storage and directory layout.
Our IT guys are looking into further but just checking to see what the CSI community can help with
I hope this makes some sense but let me know if more info can clarify the problems.
any help much appreciated
regards Paul
Make sure you are fully up to date with Loggernet (to 4.1) as some bugs have been fixed over the years that could exhibit themselves in ways not disimilar to some of your symptoms.
As a general rule, in my experience, running USB devices on servers long term, can be problematic. For reasons unknown, devices can either be forgotten or re-enumerated to different COM port numbers for no good reason. I am not sure if this is down to Windows in general, hardware glitches, or poor driver software. Generally we would not advise using USB hardware for long term, unattended connections.
If Loggernet has a com port "pulled out from beneath it", especially if it is in the middle of a comms session via that coms port, then it can have severe problems.
Some of the symptoms you report could be down to hardware or USB issues. The issue with Loggernet losing connection to localhost would most likely be caused by the Loggernet server having crashed, although it might just be caused by a firewall change or something else blocking the TCP/IP socket the clients talk to the server on.
The main reason for running Loggernet as a service is that someone can login/logout of the machine without having to restart Loggernet. Many IT depts do not like a user left permanently logged on as you have to do if you do not use the run as service option.
FYI Loggernet can generally use UNC nomenclature for remote machines and directories (\\machine\directory). You do not have to us mapped drives.
Thanks for help and suggestions Andrew
We have version 4.1 installed and have had no problems in the past similar. I do believe it is related to the setup made before xmas on the new server upgrade from an XP desktop that was setup as a trial system
I worked on a few things yesterday and updated some support software.
I use kernal pro virtual com ports to create a link to a UDP translation application and this may have also caused some of the symptoms
We are changing the network link today and removing the Belkin USB hub but are still installing an ethernet to USB link
The upgrade process of our network is to a system based on TDMA radios and these have a USB connection so I think we are limited to this technology.
I am starting to think the same as yourself that it is a break in one of the comm links that is causing the instability
On an aside the UDP translator we developed in house to talk to a common Modem we use here that does not support TCP/IP, do CSI have any support for UDP? or devlopment?
regards
Paul
I would also suspect the USB drivers. I have a small weather station at home. I have occasionally seen where LoggerNet stops collecting data. Upon investigation, it appears that for some reason the USB port locks up, but is "spewing data" such that it keeps LN occupied for a few hours, then the port completely locks up and LoggerNet begins its retry attempts. If I disconnect/reconnect the USB to serial cable, operation returns to normal. You may have better luck with a different USB connection/driver set.(I have a new cable I still need to try.)
The dataloggers do support UDP. Take a look at UDPOpen and UDPDataGram instruction in the CRBasic help. I have not worked with these instructions, so this is all the info I can provide.
Dana w.
Thanks Dana
My uderstanding with the UDPopen instructions that these are for logger initiated communications
are system rightly or wrongly is based on scheduled calls from loggernet from which I have found any mechanism for UDP data collection
The ssytem we developed then uses a custom phone modem that appears to loggernet as a phone modem but negotiates with the remote site as UDP.
I have tried the UNC path with no success
i have entered
\\pnt-cd1\Telemetry\Loggernet Telemetry\TRF_850\TRF_850_Data_15min.dat
but in truncates the first \ and redirects to to the local drive?
is there a naming restriction? or format? for UNC paths?
Yes, only the dataloggers can communicate via UDP.
You should be able to use mapped network drives, but they have to be set up for the LoggerNet user. The following is from the help entitled Running LoggerNet as a Service:
Mapped Network Drives
Network drive mapping are associated with individual user accounts. Therefore, to make the network drives visible in LoggerNet (i.e., in the data browser used to identify the location for an output file), the user must login as the LoggerNet user and setup the desired drive mappings.
The password used to login as the LoggerNet user is the password chosen when the service is installed from the LoggerNet Service Manager for the first time.
Dana W.
Just to follow up on the UDP issue, there is no support for using UDP as a transport layer for full (Pakbus) communications in Loggernet or for that matter in the logger. UDP support in the logger only allows the logger to send or receive data to/from its program over UDP.
I have seen some terminal server devices that do allow UDP to be used but as far as I know we currently have no plans to support UDP comms in Loggernet or our own terminal servers.
We will investigate the UNC filename issue because it should work. If/when it does work there could still be an issue with permissions though as the Loggernet user on the server would need permission to access the remote shared folders, the same as for a mapped drive.
thanks for all the help
With the tweaks made to the virtual com ports I seem to have gained some stability looks like this was dropping or hanging the connection for LoggerNet.
It looks like I have not set the system up correctly initial to run as a server and to map the network drives