-
-
What to check first:
Power loss or spike
Other possibilities:
Low Level drivers not responding
A scan can halt as a result of problems related to both the hardware, as well as the drivers that support the hardware.
For example, a common problem during inclimate weather is power outages which can sometimes last for hours but can also
last for only a second or two. Another example which can cause a lack of response is when one of the drivers on the system
actually "hogs the system" for only a second or two. Although a second or two seems like a very short time, it can have
a very profound effect on the ability of the other drivers on the system which may require millisecond or even microsecond
slices of time to properly maintain the functionality fo the hardware they are supporting.
|
-
-
If the device has never worked, please review install.htm first for issues that
could be related to the way the installation of the hardware was performed or the possibility of incompatible PC hardware
or external hubs.
If the device has worked but no longer signs on or appears to be unable to communicate with the device, look first
at power-related issues.
Please note that although the error indicates "Device not found" the actual error could be the result of the application
not being able to access the DLL - and thus the device is not found. A common issue that creates this problem for a device
that once worked but no longer works, is the installation of new software or drivers which results in incompatibility between
versions of each. Please run our "VerChk.exe" utility to find out if there is a compatibility issues.
Be sure to place "VerChk.exe" into the directory where your application and the DLL reside. When the
utility is run, it will display the locations of as well as the versions of the DLL and Driver that it finds on the system.
Sometimes the problems is nothing more than a new driver and DLL being installed but the USB cable not being disconnected
and then reconnected (or reboot of the PC) which allows the old driver to unload from memoryh and the new one to load.
The "VerChk.exe" utility will inform you if that is the problem as well as other problems that could exist.
A problem that occurs rarely is an actual failure of the host controller driver. Such a failure is more likely when a USB
cable is removed and then reconnected "VERY" quickly. The error appears to be due to the inability for the various threads
within the drivers to begin processing the reconnect before they completely finish processing the disconnect. This error can
prevent further communication with that host controller (and thus the USB port) until the PC has been rebooted. Sometimes the
problem will also show itself as a yellow exclamation mark beside the host driver within the Windows System Device Manager.
|
-
-
As with the "device not found" problem, a failure to signon can be the result of many issues. The first of course IS
the Device Not Found problem, so one should refer to the documentation
concerning that issue first.
Another issure that could cause this is application software and it's configuration file. Some of our sample software ships
with a text based configuration file, "LL_USB.CFG" which requires the entry of your actual device ID number. If you don't
update that file with your device ID the application won't signon since it doesn't know what to signon to. Likewise, if an
error is made to that configuration file, it will become unreadable and the application will fail to signon since it won't
be able to acquire the information from that file that it needs to do the signon.
As with the possibility of the incorrect device ID being entered in the "LL_USB.CFG" file, some of our sample
software also has the option for the user to enter the device ID into a window on the main application panel. We've had
customers contact us when they couldn't signon, and the problem was nothing more than the obvious issue of entering the
correct device ID within that box.
|
Other errors ( such as buffer wraps )
|
-
-
The "Microcode Buffer Wrap" problem can manifest itself in various ways depending on the application
software being used. We've devoted a great deal of time to do the best we can to deal with this situation when it happens as
well as preventing it from happening in the first place. A microcode buffer wrap is the result of our device driver not
receiving a long enough slice of time to keep the data read from the data-buffer within the M30x hardware. There are many
things that can create the problem, but most of them are the result of other drivers that are poorly managed and "hog" the
system time slices. One example would be the game "Pinball" that ships with versions of Windows later (and including) WinME.
We've determined that when a user starts that game, our driver recieves no slices of the system time that it needs to process
data for the amount of time required for that game to start - typically several seconds. We've also determined that other forms
of software such as automatica schedulers (to name just a few) can do the same sort of thing.
An issue that is somewhat related to the previous paragraph has to do with maintenance of the user's PC using some of the
utilities that ship with the Windows Operating System. One of the utilities we recommend using frequently is the "Disk
Defragmenter". Whenever an application runs, the disk is often used to store data - sometimes in user files and sometimes
in system cache files which aren't quite as obvious to the user. Since a single file can be spread across a diskdrive in
small chunks, adding and deleteing files can leave a disk very fragmented. When a disk is extensively fragmented, the disk
access time is also greatly effected. Since low-level drivers are used for accessing the disk drive, a fragmented disk will
cause the driver to require more of the system time-slice which then effects every other driver on the system - including ours.
Another, yet less common problem is "Scan Buffer Wrap". This problem is related to the data buffer located within the DLL,
and is usually a result of the application not calling into the DLL frequently enough to keep it's buffer emptied. This problem
is usually very easily fixed by fixing the software and shouldn't be a problem that occurs within any of our "sample" software.
One of the most effective steps we've taken to deal with the above-mentioned problems (as well as a few others) that is
"user interractive" is the use of the "LL_USB.INI" file. Within that file are various parameters that can be manipulated to
help make our DLL and Device Driver perform efficiently on a system which may not be currently functioning as well as it
should. Documentation concerning the various parameters within that file can be fournd
here. Be careful when changing the parameters in that file, and be sure to save a copy
of the original before editing it, as it is shipped with parameters that should work well on most systems. A very powerful
paramter within that file is the "ProcessPriorityBoost". which boosts the thread priority of the DLL
which in turn boosts the priority of the user application. What that does, is it causes the user application to sort of "Hog the
system" which is something we usually discourage unless the option is needed to gain priority over another running application
(maybe a background task the user is unaware of) in which case it is often required. A couple of other powerful options are
the "StackedIrpCntOverride". and
the "ScanSystemBoostLevel". Both of these parameters cause the device driver to put pressure on the
more powerful (because they ship with Windows) lower level drivers causing them to give us the data we need from our hardware
at a higher priority than we are typically allowed by our own driver. However, beware that setting the paramters incorrectly can
have a negative effect. For example, setting the "StackedIrpCntOverride" to "1". will
give less of an advantage to our driver but "will" cause the driver to use a little less memory which is rarely a problem. However
setting it to a value of 20 or greater can have a very positive effect with no bad effect accept more use of memory which is rarely
a problem on the PCs these days. A similar scenario exists in regard to the "ScanSystemBoostLevel" except
it shows itself a little differently. If that value it set very high, our driver will request larger packets of data from the
low-level driver which is fine, but the problem is, it won't return that data to the user until it has it all. Therefore, setting
that value too high can cause your scan data to appear at the application level at a very slow rate, but in "big chunks" at a time.
If a "Microcode Buffer Wrap" problem presents itself, it's usually best to increase
the "StackedIrpCntOverride" to 20 or greater and if that doesn't solve the problem start increasing t
the "ScanSystemBoostLevel" but start at the number, "4".
|
-
-
Power Loss Recovery (follow link for recover solutions or read on for overview)
A common problem during inclimate weather is power outages which can sometimes last for hours but can also last for only a
second or two. Power "spikes" can, and often do occur under a variety of circumstances - for example, large motors which
are connected to a shared power source starting, or relays connected close to or within the PC (such as some modems) being
activated.
If the Model-30x has it's power supply connected to a wall outlet and the computer is connected to a UPS
(Uninterrupted Power Supply) the computer may give no indication that there was a loss of power while the Model-30x will
automatically reset itself to recover from a loss of power. The condition is more obvious when the computer and/or monitor
is also connected directly to a wall outlet. Occassionally power spikes can also occure which likewise can have more of an
effect on whatever hardware is connected directly to the wall if the spike occured somewhere external to the PC such as in
the wiring leading up to the outlet.
We've also experienced spikes occuring within the PC itself. Most of the spikes that occur within the PC are a result of a
relay residing on an add-on card such as a modem. Such a spike can often be determined by noticing if an error condition
displayed by the software seems to occur frequently when using the modem to connect to the internet. A spike can sometimes
even occur if two external hubs are connected to a PC and then either the power cable to one of the hubs or the USB cable
going from the PC to the hub is removed - this too happens more often if the external hub uses a relay (rather than IC) for
switching.
|
Low Level drivers not responding
|
-
-
This is a problem that occurs occassionally. It appears to be a result of unknown activity on the USB cable and is related
to the low-level drivers below our driver. If performing a scan when the error occurs the scan will halt and need to be
restarted. Our driver is in constant communication with the low-level drivers during a scan. Although the occurrences are
somewhat random, we've seen this error occur when two USB cables are connected to the back of the PC and then one of the
cables is quickly removed and reconnected. We've also seen it occur when two cables are connected to the PC and an externl
hub is connected to it's power supply - not often, but occassionally and usually with an external hub that later proves to
have other problems.
The low-level drivers pass information back to our driver concerning the status of the data packet it's requested as well
as the status of the driver and the hardware it is communicating with. Occassionally it will indicate that it has lost
communication with our M30x device, however our factory tests have shown that our devices are still functioning normally
and attempting to pass the scan data back to the host. This indicates that there has been a loss of communication between
the actual onboard hubs (or external hubs) and the host drivers themselves.
The only known solution is a reset of the host hubs which we do either on request by the application or somewhat seamlessly
the next time an I/O is attempted by the user application.
|
Recovering from power loss or spike
|
-
-
1.)
Often all that is required is a reinitialization by the application. When a power outage has occured, certain codes
are passed from the hardware to the driver and finally to the application by way of the DLL. One or more of the codes
represent a cycling of power to the M30x device which is an indicator that a new initialization is required. Depending
on the software being used, a reinitialation may automatically be performed by the next attempted I/O seen by the DLL.
2.)
Check that all power cables are connected. One thing that is frequently overlooked is a power cord that isn't plugged
all the way into a recepticle. Another thing that happens occassionally is the toggle (on/off) switch found on many power
strips can accidentally be pushed to the "off" position when the power adaptor module is connected.
3.)
If connected to an external hub, check to see that the LED(s) that coincide with the port on the hub that the the Model-30x
is connected to is lit. If not, the hub may need to have it's power cable disconnected and reconnected. If the LED(s) still
don't turn on, the USB cable to the external hub may need to be disconnected and reconnected and if the LED(s) still remain
off, try rebooting the PC. If the LED(s) on the external hub still remain off, the external hub may have been damaged by a
power spike in which case it will need replaced. However, if the an external hub and/or the M30x is connected to a
"power distribution strip" the strip may have been damaged by a power surge - this can usually be determined by connecting
a known good appliance such as a lamp to the power strip to see if there is power going to the strip's outlets.
|
|