Frequently Asked Questions
1.Question
I have configured an ODBC data source for the RADS archive but it event logs
that it can not find the data source.
Answer
Since the RADS archive runs as a service and starts before any user is logged on
it uses a system DSN (data source name). Configure your data source as system
DSN.
To Top of this page
2.Question
I have configured an ODBC data source for the RADS archive service. It is an
access database DSN. Archive reports that it can't find either the Data source
or User name from INI file.
Answer
There could be a couple of things wrong here. First - the archive.ini file may
be in the wrong place. The archive.ini file must reside in the windows
directory. This is %systemroot%. An easy way to check this is to start a
command prompt window and type in the command "echo %systemroot%" without the
quotes. Second - since this was an access database you may have thought a user
name was not needed. Even though the access data source may be configured to
not need a user name, the INI file entry [DATABASE] USERNAME= still needs to
have a user name. Use anything.
To Top of this page
3.Question
I've noticed that all the event log entries begin with "The description for
Event ID ( 0 ) in Source ( PROGRAM NAME ) could not be found. It contains the
following insertion string(s):". Is there any meaning to this?
Answer
No there is no meaning to that. RADS does not register any event strings for the
event viewer so the event viewer displays that warning for each entry. A future
release of RADS may correct this. It can be safely ignored for now.
To Top of this page
4.Question
When I start the RADS executable I get a dialog box that states "Unable to load
group. Open." When I press OK a job window comes up but no job information is
displayed.
Answer
A number of things can cause this. What this is telling you is that the
default.grp file in the "[DIRS]JOBDIR=" directory can not be opened. When the
initial RADS window is opened it uses the RADS.INI file to locate the JOB
directory. So the sequence to check is: 1) is there a RADS.INI file in the
directory that the RADS.EXE is located in? 2) Is the "Start in:" field of the
shortcut set to the directory that RADS.EXE and RADS.INI is located? 3) Is the
JOBDIR entry in the [DIRS] section? 4) Is the JOBDIR entry ended with a '\' ?
5) Is the JOBDIR entry valid? The way to check this is to open a command window
and do a dir to the JOBDIR entry and verify that the default.grp file is
listed.
To Top of this page
5.Question
When I start RADS I get dialogs that indicate that it is unable to connect to
the RADS host. How do I correct this?
Answer
The RADS window connects to the host computer that is set in the JOB file. For
the initial RADS window this is the default job. One of two things is wrong
here. 1) The RADS service is not started on the host indicated in the default
job file or 2) the setting in the default job file is incorrect. For number 1
use the control panel on the RADS server to verify that the RADS Server Service
is started. For number 2 go ahead and acknowledge the dialog boxes (they may
keep coming up every 20 seconds, simply acknowledge them) and go to
Edit->Servers. This menu option is only available to the RADS
administrators. This is set on each computer running RADS. This is controlled
by the RADSADMIN= entry in the RADS.INI file in the [APP] section. This defines
a group that if the user is a member of this group that user will have
radsadmin rights and can edit the server used for the job. After creating a
radsadmin group and putting yourself in it and logging off and back on again,
the Edit->Servers entry will be enabled. Take this option to bring up the
dialog and verify that the server entry is correct. Insure that the entry does
NOT start with the \\ characters. Next verify that the RADS port is set to
9270. Future versions of RADS Server may allow customizing the port # so this
entry must match the RADS Server setting. If you correct any of these setting
in the server dialog, press the save button, then do a File->Save and then
exit the program and re-start it.
To Top of this page
6.Question
When I create a new RADS job the new JOB window immediately indicates it is
unable to connect to the RADS host. Why does it do this when the default window
works ok?
Answer
When you create a new RADS job, the base settings (including the RADS host) is
taken from the RADS.INI file. These setting are in the [NEWJOB] section. The
entry RADSHOST= and RADSPORT= controls what server the JOB window attempts to
connect to. The RADSHOST entry is probably set incorrectly.
To Top of this page
7.Question
When I try to close the RADS window nothing happens. What's wrong?
Answer
This is the design of the RADS default window. The default window will not close
as long as any other RADS job window is open. Also note that a side effect of
this is that if another non RADS window is open with a title that begins with
"RADS - ", the RADS default window will get confused and think that another
RADS window is open when there really isn't.
To Top of this page
8.Question
I've turned on additional devices in the field but they fail to show up in the
active device list. I already have some devices working properly. What's wrong?
Answer
In this case it is good that you already have some devices working. This
eliminates a lot of troubleshooting. First manually add the devices to a job
window. If they display with "NO DATA" as the name, this indicates that the
devices do not exist in the RADS server 'in memory device list'. If the devices
appear with a name other that "NO DATA" but are showing LOST status, we'll
tackle that later. Let's deal with the "NO DATA" for now. First let's verify
the RANGE CHECKING option. Edit the WRMGAT.INI file and check the [INCLUDE
RANGES] section. Verify that the devices you are dealing with fall within one
of the RANGES listed. Make sure the RANGES listed start with "RANGE0=" and the
ranges are sequentially listed. Also verify there are no more than 10 ranges
used, RANGE0 through RANGE9. Also verify that a RANGE does not use device 0
(e.g. RANGE0=0-999999). Zero is a special device number and is not valid to
start a range with. Verify the RANGES are formatted correctly (e.g. 100-200).
NOTE: RANGE CHECKING CAN NOT BE DISABLED AS IMPLIED BY THE DEVICES.EXE UTILITY.
If the RANGE CHECKING was the problem, save the INI file and stop and start the
WRMGAT service using either the control panel, services or net stop, net start
commands. If the RANGES were okay, let's now use the DEVICES.EXE utility to
check the quantity of existing devices. The RADS server is internally
configured to hold 500 devices. When the list is full, no other devices can be
added unless the "reuse oldest device" option is enabled. You can try enabling
this but is not really a good idea to use this option for any length of time
and some of your inactive but legitimate devices may be replaced. Use the
serial # pull down and see if there are lot of devices. You can count them but
usually if there are several pages of them the 500 may be used up. You can
verify this is the case by trying to add a non-exist device. If you add it and
then look in the pull-down and it is not there, it is a sure sign the list is
full. This can easily happen if the "Use only configured devices" option is
turned off for any length of time. The system can fill up with bogus devices.
Look through the devices and if you recognize that some of them are bogus
delete them. You can delete a range of devices by entering serial # in the
format of "100-200" and clicking delete. If you specify a large range ( more
than 1000) the RADS server will take several seconds before it re-populates the
pull-down. Be patient. Now you may either manually add your new devices or
uncheck the "use only configured devices" for a few minutes. The bogus devices
are encountered over a period of days. A few minutes won't add a bunch of bogus
devices. The problem with devices displaying in the RADS job with a name other
than "NO DATA" but still showing a status of LOST can be caused by one of two
things: 1) The device is really not being received by a receiver or 2) the
device had been manually added with DEVICES.EXE and the data is being rejected
by the RANGE checking. Check the RANGE checking as described above. To
determine if the data is actually being received by a receiver use the
WGMAINT.EXE utility to select the server and receiver that should be receiving
the data and turn on the data display. You can watch the data for your device.
If you see the device in the raw stream, turn on the message display and see if
it is in the message display. If it is it should be posting data and time to
the device. If it is not in either display the transmitter is defective.
Sometimes the label on a dosimeter does not match the internal number the
dosimeter actually sends in the message.
To Top of this page
9.Question
What is the first step in troubleshooting receiving RADS data from telemetry
devices?
Answer
The first step is to use a utility such as a terminal program or telnet to
connect to the serial port or network terminal server that is receiving the
data and verify that the data is being properly received. These utilities
operate outside of RADS and provide an independent verification that data is
actually being received. The next step is to check the WRMGAT.INI and verify
the COM PORT/ NETWORK settings.
To Top of this page
10.Question
What is DATGAT.EXE and how does it fit in with RADS?
Answer
DATGAT is basically the same as WRMGAT but supports additional types of devices.
It uses the DATGAT.INI file for its configuration. The same INI file settings
used for WRMGAT work with DATGAT. Eventually WRMGAT will be phased out. DATGAT
can be run along side WRMGAT. To do this the PORT number of DATGAT must be
changed so it does not collide with WRMGAT. WRMGAT's PORT number is coded at
9271. DATGAT's PORT number is configurable in the DATGAT.INI file. Running
DATGAT along side of WRMGAT allows you to use WRMGAT for the WRM91 devices and
DATGAT for Siemens EPD and SAIC PDX devices. If you need to make changes to the
WRM91 channel settings, COM port, network devices, etc you can re-start WRMGAT
w/o affecting EPD and PDX devices. EPD and PDX support allows dynamic
configuration of these channels w/o restarting DATGAT. Eventually this dynamic
support will be offered in DATGAT for WRM91 channels and AMS4, mini-edgar
support.
To Top of this page
11.Question
When I start RADS the splash screen displays and then the application hangs.
What's wrong?
Answer
The default.grp file has become corrupted. Rename the file and try again. When
the RADS job window opens expect a dialog that complains about "Unable to load
group. Open". This is because the default.grp file is missing. Simply do a
File->New and create a JOB called default. Be sure to Edit->Job Devices
and click on Default Job. Then perform a File->Save. You can then close the
RADS application and re-start it and it should come up.
To Top of this page
12.Question
When I change RADS job settings in Job Properties and click on save and then
later open the job the settings are back to their original settings. Why is
this?
Answer
Clicking on Save in any of the dialogs causes RADS to save those settings in the
memory image of the job file. You must click on File->Save to cause those
settings to be recorded to disk.
To Top of this page
13.Question
When two users are using the same job file on different computers at the same
time, when user A adds a device to the job why doesn't user B see the device is
his job window?
Answer
Job files are files stored in a central location, generally on a shared server.
When a user opens a job file, the file is read into memory. The memory image of
the job file is not re-read at any time later. However, when a user changes
settings on a device in a job file, those device settings are updated in all
RADS windows that is displaying that device. Device settings are maintained
consistent across all job windows, job file settings are not. This job file
implementation also causes another side effect known as "the last that saves
has it". What this means is that if two users on different computers using the
same job file, the user that saves the job file last has his job file settings
saved to the disk. Job files were not intended to be used in this manner.
To Top of this page
14. Question
I have a device number of 0 appearing in my devices tool or in my available
devices. I can't seem to delete it, what do I do?
Answer
Device 0 is the device number that gets transmitted if an MG transmitter has no
dosimeter plugged into it or there really is a transmitter somewhere with or
without a dosimeter. The devices tool may not let you delete it because of a
blank field logic check that is equating to 0 or it may be transmitted and
coming back in. At any rate it can be safely ignored.
To Top of this page
15. Question
When I move a job file window around the screen, at a specific place on the
screen I loose camera control.
Answer
There are several possible items which may cause this to occur.
1. Check your RADS.INI file, in the [APP] section you should find two entries
("SCREENSIZEX" and "SCREENSIZEY") verify that they are there, if not add them
and set them to the display resolution of your monitor.
2. If you are running a multi headed video card or you have more than one
computer monitor, check your RADS.INI file, in the [APP] section you should
find an entry labeled "RADSRECT" verify that it is there, if not add it.
a. If you have a single computer monitor - Set this to the upper left corner (usually 0,0) and the lower right corner
(on a single monitor with a display resolution of 800x600, this would be set to
800,600). The final RADSRECT line would read "RADSRECT=0,0,800,600"
b. If you have two computer monitors stacked vertically - Set this to the upper left corner (usually 0,0) and the lower right corner
(on two monitors with the resolution 800x600, this would be set to 800,1200;
note the double height). The final RADSRECT line would read
"RADSRECT=0,0,800,1200".
c. If you have two computer monitors sitting side by side - Set
this to the upper left corner (usually 0,0) and the lower right corner (on two
monitors with the resolution 800x600, this would be set to 1600,600; note the
double width). The final RADSRECT line would read "RADSRECT=0,0,1600,600".
3. If you are running a multi head video card or you have more than one computer
monitor, check your RADS.INI file, in the [APP] section you should find an
entry labeled "DISPLAY" verify that it is there, if not add it and set it to
"NORMAL" if you have a single monitor, "VERTICAL" if you have two monitor
stacked one over the other, "HORIZONTAL" if you have two monitors setting side
by side.
To Top of this page
16. Question
I receive an error, "Cannot load group. Open.", in other words, RADS cannot find
the group files it needs.
Answer
There are several possible items which may cause this to occur.
1. The host that a RADS job window attempts to connect to is contained in the
related job's .GRP file. The job that gets opened at startup is DEFAULT.GRP. IF
the window can't find DEFAULT.GRP it displays a somewhat cryptic (to be fixed
in next release) message that reads something like "Cannot load group. Open."
What this means is it cannot open the group file. The location where RADS looks
for group files is specified in the RADS.INI file located in the SAME directory
as the RADS.EXE file. There is an entry in the file JOBDIR= that should point
to a shared directory on the RADS server. Okay the JOBDIR gets you to where
DEFAULT.GRP is located.
2. Once the job window opens default.grp it probably will read a server name
that does not exist on your network. After you acknowledge the error message,
you can fix this by using the EDIT->SERVER menu option to display the server
dialog and change the server name to your servers name. Unfortunately, The
EDIT->SERVER is probably grayed out because you are not a member of the
radsadmin group. This group is specified in the RADS.INI file with the setting
RADSADMIN=. The easy way around this is just set the RADSADMIN= to an already
existing group on the machine - like Administrators or Users. This will let the
EDIT->SERVER option come on. After entering your server name and click save,
be sure to do a FILE->SAVE also. You will have the fight the re-connect
messages - just press okay and keep going. After you do the FILE->SAVE then
exit RADS and start it again.
3. Another good point to take note of is the [NEWGROUP] section. The entry
RADSHOST= should be set to your server before creating any new jobs. The
information in the [NEWGROUP] section is used as the default for all new job
files. Therefore another way to get the right server set in default.grp is to
delete the default.grp file on the server (or rename it if you want to save it)
and open a RADS window. It will cry about "unable to load group. open" but say
okay and click on File->NEW and create a new job and call it default. This
will capture the [NEWGROUP] settings into the new file. Do a FILE->SAVE and
then exit and re-enter.
4. IF you're still having problems try pinging your server from the DOS prompt.
Most times the server name is wrong, a dash is an underscore etc. The server
isn't in your networks DNS with the right name, etc. If DNS is the problem you
can enter a straight IP address in for RADSHOST=. If the server pings, go to
the server and verify that RADSVR.EXE is in the task list. If not you need to
start it via control panel services. However if the name of the server does not
ping, the shared directory probably wont work either.
4a. Don't use the UNC convention specifying TCP/IP hosts (\\SERVER is wrong).
Only use the \\ for shared directories. Hosts specified in CAMERAHOST,
RADSHOST, etc and on the SERVER dialog never has the \\ on them.
5. A common problem is that the share where the .GRP files are kept is not
accessible. An easy test is to simply do a DIR from the DOS prompt on the path
that you have set JOBDIR= to in the RADS.INI file. If you get an error doing a
dir, then that is an NT network problem and needs to be resolved.
5a. Also I have seen situation where no one has loaded TCP/IP on the machine.
Usually happens with laptops running in stand alone mode though.
6. Another big problem is that someone made a shortcut to RADS.EXE but failed to
set the start in directory to the directory that RADS.EXE is in.
To Top of this page
17. Question
When I open the Job Window for any project, including the default group, I
receive the message "Unable to set local time".
Answer
You will have to give the user the ability to set the workstation time, using
Windows NT's User Profile Manager on your server. You don't have to make the
user an administrator. Use user manager, and go to policies, user rights and
select the right "Change the system time" and add the user to the list
displayed. An even easier way would be to just give the right to all users or
set up a group (you'll want to set up a group for control of the RADS jobs
anyway) and give that group the right to change the system time. A future
release of RADS will change this so that the workstation time won't have to
match the server time.
To Top of this page |
