STISIM Drive - Troubleshooting and Errors

Although it is considered taboo and should never be discussed openly in public, we would be remiss if we did not at least touch on the subject of the computer system failing to adequately navigate the bug free software that we have developed. Yes we are talking about the not common, quite elusive and very seldom repeatable (that is when we try to solve the problem), system hangs. To the best of our knowledge, STISIM Drive is bug free and should generally work. Unfortunately, this is the real world and you are dealing with a highly sophisticated simulation system that sometimes seems to have a mind of its own, and therefore, when running a simulation, problems may occur. One of the easiest things to do when you are trying to use a complex computer system that uses both hardware and software is to find problems. Conversely one of the most difficult tasks is to eliminate the problems that you find. This is mostly due to the complex nature of correctly installing computer hardware and understanding exactly how it is supposed to be used. However, this can also be caused by misunderstandings with the software/hardware and can also be caused by software bugs. Such is the case with STISIM Drive because it uses multiple pieces of hardware that require numerous software drivers and Windows DLLs and is itself a software program trying to utilize all of the specified hardware. Therefore we have included this section to provide you with possible hints to the brain teasers that may lay ahead.

In general there are 4 different types of problems that you will encounter. The first is the basic STISIM Drive error. As much as possible STISIM Drive tries to detect errors and display a descriptive message box that indicates the error and a possible solution. These errors generally fall into the "Oops! I forgot to specify a parameter or file" category and are readily corrected. The next level of error deals with Windows errors that are not caught by STISIM Drive and therefore generate a Windows failure error. These will be discussed subsequently in a Windows Errors section. The next category falls under the name of troubleshooting. These problems can be the nastiest problems of all because they do not produce an error message and the program still operates, but not as either you or we intended it to. In these cases there is generally something missing, either a parameter or a flag is set incorrectly or not at all and this produces the undesirable results. A listing of common troubleshooting problems is subsequently discussed in a section cleverly called Troubleshooting. Finally, there is the software bugs category where you come across something that is wrong with the software that we, up to this point, are not aware of. We have no section for this type of problem, but you can contact our sti@systemstech.com and let us know what you found so that the problem can be fixed in subsequent versions of the software.

To help in the elimination of all perceived bugs, STISIM Drive automatically creates a log file in the STISIM Drive temporary directory (generally C:\STISIM\Temp) called not surprissingly STISIMDrive.Log. As STISIM Drive configures your particular run, it logs messages in this file that can help in determining what may be happening with your system. This provides a running record of what the program did from the time it starts until you exit. This file is a simple text file that can be viewed with any editor capable of displaying text files. If you feel adventurous you can view this file to see what processes took place before the problem occurred and try to solve the problem yourself, or you can email this file with a description of your problem to our superb technical support staff (sti@systemstech.com) and they will look into the problem.

Windows Errors

Nasty word errors. No matter how hard we try they still seem to sneak up and get us on occasion. Unfortunately, when it comes to hardware and Windows sometimes things just don't work. The following is a list of common Windows/STISIM Drive related errors and what they generally mean:

Problem	Description/Solution
Any error with the word Voodoo in it:	Something is wrong with the graphics card. Either the drivers have not been installed, the Glide2x.dll file is incorrect or the Stigvs.dll file could not be found. Review the hardware configuration graphics subsection for more information.
Could not find Cbw32.dll:	ComputerBoards driver DLL could not be found. You may need to reinstall the software if this is the case. Make sure that the C:\CB directory was created and that it contains the Cbw32.dll file. If this file and directory exist, check the computer's environment variables to make sure that the CB directory is included in the path.
Could not find Stigvs.dll:	One of several STISIM Drive DLLs could not be found. This requires uninstalling and reinstalling the software. If the Stigvs.dll file cannot be found then chances are other files are missing also and it is probably best to re-install the software. You don't necessarily have to uninstall the current software, but most Windows experts say that this is a good idea, however Microsoft doesn't always do it with their products, go figure?
Could not find Sx32w.dll:	The dongle driver could not be found. Review the hardware configuration hardware protection key subsection.
Expression too complex (Error 16):	Review the hardware configuration graphics subsection.
Hardware Error (Error 52):	This is a problem with the Input/Output cards. Generally it means that the WinRT driver that controls the optical encoder board has not started successfully. Sometimes restarting the program works, sometimes restarting the computer works. If neither of these work then most likely you have not configured the board correctly and STISIM Drive can not identify that an I/O card is present in the system. If you look in the Resources tab of the NT Diagnostics program, it should show that WinRT is using interrupt 9. If this is not the case, and something else is claiming interrupt 9 then you have a device conflict. If nothing else is claiming interrupt 9 then WinRT did not start. Review the hardware configuration I/O subsection and troubleshooting discussion for more details.
Mapmem or Genport error messages	These are caused by the 3DFx graphics card not initializing properly and generally occur when you first try to run STISIM Drive. Most of the time if you simply try to run STISIM Drive again, the problem will resolve itself. This is because STISIM Drive tried to access the driver before the driver was started (a Windows ordering issue). If the problem persists, then the graphics drivers have been corrupted and will need to be reinstalled. If this is the case, read the installation procedure provided in the graphics card manual.
One or more processes do not start during system boot	This error message occurs after the system has booted and is displayed in a message box in the center of the screen. There are a seemingly infinite number of reasons this message comes up. The most common are due to either an ISA bus interrupt conflict, or a piece of hardware missing or configured incorrectly. The best course of action is to go to the Event Viewer (see troubleshooting)  and review the system log process. Review your Windows NT documentation for details on the event viewer and the errors generated. At this point if you need additional help, contact STI technical support at sti@systemstech.com with the error that is listed.
WinRT errors:	If you receive an error saying that the WinRT process could not start or something similar to that effect, it is generally an interrupt request (IRQ) conflict between WinRT and an existing piece of software. Several things can be done to resolve the problem: If you are running a system with analog control inputs, you will need to set some new registry values. Using the Windows Explorer, go to the C:\STISIM\Tools folder and double click on Analog.Reg. This will set the registry for you. You may also need to change some system settings. This is done using the InsCal32 program in the C:\CB folder. If you are using a system with the optical encoders, then the conflict is probably an IRQ conflict. You will need to check your system to see if another piece of hardware is using IRQ 9 (generally a network card or something similar), and if it is then you will need to resolve the conflict. Review the section in the hardware configuration dealing with I/O and specifically active steering.

Troubleshooting

As was mentioned previously one of the most difficult tasks when owning and operating a Personal Computer is to figure out and remove the various oddities that happen to present themselves. This is not exclusive to an STISIM Drive simulator but instead is a common problem with all Personal Computers. This is illustrated by the number of people who make a living by either repairing personal computers or by writing books on how to repair them. Since there is no magic solution, we at least hope that the remainder of this section will help you identify and eradicate those pesky problems that plague your computer. It should be noted that this discussion pertains (but is not necessarily limited) to the Windows NT operating system. This is because the Windows NT system comes with a more complete set of tools for troubleshooting your computer system.

There are 2 basic steps to any troubleshooting techniques that you employ, identification and extermination. It is hard to determine which of these two steps is the most difficult because they can both require a trial and error approach to solving the problem. For this reason we have included a table of the most common problems that we have seen and potential solutions to solving the problem. Unfortunately, some problems are absolutely machine dependent and the solutions and advice offered here my not work in your particular case. When this happens you will need to employ a little investigative skill in order to slay the beast. Some advice on doing this is presented in the following table which includes all configuration problems that we have encountered:

Problem	Description/Solution
Colors don't match up	On wide field of view systems, multiple display channels are used which means that there will be multiple devices (monitors, projectors) used to display the roadway scene. Therefore there is a chance that the colors will not be the same on each system. The first step is to try and match the color settings on each of the display devices. If this does not provide satisfactory results, turn off the gamma correction for the simulator. If this still does not work, there is a REG file in the C:\STISIM\Tools directory called OB2x_3Dfx_Ref.Reg. This file will set some default properties for the Voodoo cards. Make sure you run it on each system. Finally if this does not work, go to the Display aplet in each system's Control Panel and look to see if there is a tab that allows you to change settings on the Voodoo card. If this exists, activate the tab and look to see if there is an option for overriding the gamma correction. Once again if this override exists, activate it on each machine.
During boot-up a process does not start and an error message is given	This generally means that there is a resource conflict that must be corrected. Sometimes these corrections are easy, and sometimes they are difficult. In any event you will need to find out what the conflict is. This can be done (in NT) by using the Event Viewer program (Start/Programs/Administration Tools/Event Viewer). This will display a list of problems that have occurred during the boot process. The top of the list will display the most recent errors and should list them by date and time. Look for the first occurrence of the Event Log in the listing. All of the listings above the Event Log and the first listing below it apply to the most recent boot-up. If you double click on each error a box will be displayed that provides additional information about the problem. In general 2 problems seem to occur: The Sentinel Service could not be started. This is because the driver for the hardware protection key was not loaded during installation. Review the hardware protection key discussion for details on how to load the driver by hand. The WinRT driver conflicted with some other device and could not be loaded. This is generally caused by an interrupt conflict between the WinRT driver and another system driver. We automatically set the WinRT driver to Interrupt 9 (because it is not generally used), however this interrupt is occasionally used by other hardware and therefore causes a conflict. In order to correct this problem you must change some registry settings. Contact STI for details on how this is done. If the problem persists and the interrupt that is assigned to WinRT is free, the problem may be caused by a conflict in your CMOS settings. In general your CMOS contains the basic configuration of the computer system. Some computer manufacturers set the system up so that some interrupts can not be accessed by an ISA hardware board. Therefore, you may need to look at your CMOS settings (this is generally done during the computer's boot cycle by pressing the Del key or some such operation). Once in the CMOS you will need to examine your systems configuration to see if the desired interrupt is enabled for use with ISA hardware boards. If this is indeed the case, the interrupt is most likely set for PCI operation or PnP operation or some combination. You will want to set it for ISA operation only.
Hardware protection key errors.	In general, any time you receive a message about the hardware protection key or "dongle" it means one of the following 2 things: The hardware protection key is not plugged into the computer's first parallel port. Simply find the hardware protection key and plug the male end of it into the female port. The parallel port is a 25 pin female port and most computers (at least nowadays) have only one. The Sentinel Service could not be started. This is because the driver for the hardware protection key was not loaded during installation. Review the hardware protection key discussion for details on how to load the driver by hand.
No mouse	If you have a wide field of view system and after booting you do not have control of the mouse, reboot the computer. When the machine is booting, DO NOT USE THE SWITCH BOX. At times the switch box becomes confused when you switch between computers while a machine is booting. You do not have to set it to each computer when booting it, just don't change systems while any of the computers are booting.
Program does not run, and no message is displayed	There are many reasons that the program does not run. In most cases an error message will be displayed that gives you some indication of the problem and a direction to head in order to alleviate the problem. However on a rare occasion you may try to run the program and absolutely nothing happens. In these cases it is generally one of three problems: A version of STISIM Drive is already running. Check the task bar to see if STISIM Drive is currently running and if it is, click on the STISIM Drive taskbar icon in order to bring up that version of the program. STISIM Drive will only allow one copy of itself to be running at a time. If an instance of the program is not listed in the task bar, then simultaneously press the Ctrl, Alt and Del keys. This will bring up Windows Task Manager listing all of the processes that are currently running. Go through the list and see if a version of STISIM Drive is listed. If a version is listed, then highlight it by clicking on it and then click on the End Task button. This should end the session and allow you to start a new session. If neither of the above situations are true, then most likely STISIM Drive is having trouble with your graphics driver. When STISIM Drive initializes it polls your graphics driver for some current board information, if for some reason it does not like what it finds, the graphic subsystem shuts down and takes the program with it. Therefore we recommend that you uninstall the current 3DFx drivers that are on your computer system and then re-install them.
Program does not run due to an application error	Of all the problems that we have seen with STISIM Drive and the computer hardware this one is the most puzzling and frustrating. It is almost always caused by a hardware driver that has gone psycho, and almost always occurs after some new hardware/software has been installed on the machine. It can generally be corrected by removing the component that was most recently added and restarting. However, this may not correct the problem because the computer's registry may have become scrambled during the process and now the computer system is unstable. At this point it is almost always best to start from scratch and re-install the system. Specifics for re-installing the system can be found in the hardware configuration section.
Roadway display scene remains blank	Aside from the obvious things, does the monitor have power, is the monitor plugged into the graphics card, etc. Try the following: If you are using only one monitor and the pass through cable that was supplied with your monitor, then the most likely scenario is that everything is fine, you just can't see that the simulation is ready to go. When the monitor switches over to the blank screen, wait about five seconds then try simultaneously pressing the Alt and F2 keys. If the simulator starts then everything is fine, if nothing happens try again, if nothing happens again, then try pressing Alt and F1. If the simulation ends then chances are things are O.K. and you will have to give it a little more time to initialize. From the Windows desktop, right click on an area of the desktop where there is no icon. This will bring up the Display applet that allows you to set the characteristics of your display system. Look to see if there is a tab for your graphics adapter (for example if you have an Obsidian card the tab will be called Obsidian or something close). If there is no tab, check your documentation to see if there should be one, and if there should be one, then reinstall the graphics drivers and try again. If there is a tab, click on the tab. When the display changes choose the Test option and see if the test screen appears. If not then there is a problem with the connection, if it does appear then exit it and check to make sure that the Glide2x.dll file is included in the STISIM Drive directory. If you continue to have trouble, the best way to approach the problem is to use a second monitor. Borrow another monitor and hook one up to the regular VGA card and the other up to the roadway display graphics card. Then try running the program. If you get it working with both monitors, then you can go back and try it with just one and see what happens.
Side system does not start	If you are using a wide field of view system and one of the side systems does not start it usually means one of several things. First, if the program does not startup at all it could be one of the following: If a message appears saying that the network link could not be found, this means that somehow the network connection has been broken and must be re-established. Review the network section of the hardware configuration help section. There may be a previous version of STISIM Drive running, see the trouble shooting section on the program not running and no message is displayed. There were too many collisions across the network and the side system was unable to process the necessary information from the main system. At this point choosing the abort option for all the systems and retrying is your only choice.
Simulation runs but there are no controller inputs	There can be several reasons for this and they all involve whether or not the hardware was configured correctly. No matter what, you should use the CalPot32 utility program to see if you are getting any inputs at all. If not try the following:: The input card has not been properly installed. Check the hardware configuration section for installation instructions. Make sure that the proper input controller has been selected in the I/O Controls configuration tab box. If you have an optical encoder input system, make sure that the controller input axis have been set correctly in the I/O Controls configuration tab box. Make sure that all of the cables are securely fastened to both the controller and the input card. Make sure that the gains for the input controllers have been set in the I/O Controls configuration tab box. There could be an interrupt conflict. Check the Windows NT (Start/Programs/Administration Tools/ NT Diagnostics/Resources and make sure that interrupt 9 is assigned to WinRT, if not then some registry settings will need to be changed. Contact STI before proceeding.
Simulation timing	Since STISIM Drive is a real time driver in the loop simulation, it is affected by the amount of time it takes the computer system to process a single frame of the simulation run. Since it takes a finite amount of time to process each frame, both time and distance are not directly controllable by the program. In general, STISIM Drive tries to run the simulation at an update rate that the user specifies (generally 20 or 30 times a second). Unfortunately, very complex display scenes require more processing time and this frame rate may slip and become longer on certain frames. As long as the frame time does not become outrageous (less than say 10 frames be second), the display scene will look smooth and the driver may not even notice. You probably think great, if the driver can’t tell then there is no problem. Unfortunately, that is not the case. The problem arises when you are trying to collect data at discreet time or distance intervals. Because the time may be slipping, the timing interval may slip also. When the program collects data it checks to see if the criteria (time or distance) has been met or exceeded and then saves the desired data. If the frame time is jumping around, then the data collection time will jump around also. Additionally, if you are collecting data based on distance, it is impossible to collect data at even intervals because the distance that the vehicle has traveled during a single frame will change based on the speed that the vehicle is traveling. There is no exact way to avoid these data collection problems, but you may wish to keep them in mind when analyzing your data. When the program is running, the experimenter's monitor includes a display of simulation parameters. One of these parameters is the current frame time. If you think a scene may be too complex and is slowing the simulator, watch this parameter. If it begins to drop below 15 or 20 then you may need to make the roadway scene less complex.
Texture maps are not displayed in the roadway scene	There are generally 2 reasons this happens: The texture maps directory does not exist or the texture map that is needed does not exist. STISIM Drive keeps all of its textures in one directory called C:\STISIM\Data\Textures, if this directory does not exist or if the texture map that an object is trying to use is not located in this directory, it will generally not be displayed on the object during the simulation run. The rendering engine could not find the texture path. The rendering engine that STISIM Drive uses looks for its texture maps in a common location. This way, no matter where the program is launched, the texture maps can always be found. The texture path is set using an environment variable. The line TXTPATH=C:\STISIM\Data\Textures needs to be set in your computer system's environment. In Windows 95/98 this is done in AUTOEXEC.BAT file using the line SET TXTPATH=C:\STISIM\Data\Textures. In Windows NT you will need to go to the control panel and open the system applet. Next, choose the environment tab, in the Variable text box, enter TXTPATH and in the Value text box, enter C:\STISIM\Data\Textures. Next, click on the "Set" button and then choose "Ok".

The preceding table was a list of things we know about, but this may not be everything that can happen. If you find yourself in the position where you are having a problem and it does not fit into one of the preceding categories, say a little prayer to start and then try some of the following (these only apply to systems using the Windows NT operating system):

1. Almost every problem you will encounter will generate an error message during boot up. Generally the message informs you that a process could not be started. If this happens, you can always get some idea as to what the problem is by reviewing the events log that Windows NT generates when there is a problem starting any of the computer's devices. To access the events log, first click on the "Start" button in the taskbar. When the start menu is displayed, click on the "Programs" option. This will display another menu from which you want to choose the "Administration Tools" option. Finally, within this latest menu is an option for the "Event Viewer". When you choose the event viewer option, a screen similar to the following will be displayed:

As you should be able to tell from the image, each time the system is started and an error occurs, a new occurrence of the EventLog is entered. The date and time that the new log is started is also included. This allows you to easily track past problems as well as the most recent ones. If you look closely at the Event Viewer listing you will see that an event is logged before the EventLog is, this is because the EventLog event is not started unless a problem occurs. Therefore, always look at the entry below the EventLog listing for the first error that occurred. Every other error will be listed above the EventLog entry. If you double click on any of the entries within the Event Viewer listing, a window similar to the following will be displayed:

This screen will provide some initial details about the error that occurred. There are 2 items that you will want to look at. The first is in the upper right hand corner and it is labeled "Source:". To the right of the label will be the name of the service that failed. This is usually a device driver and if you can identify which piece of equipment is associated with this driver, you will have taken a big step to eliminating the problem. In this example, you see that there was a problem with the "Serial" driver meaning that serial port communication was unable to start. The second piece of information is found in the text box in the middle of the screen under the label "Description:". The information contained in this text box provides a more detailed description of why the driver failed to run. In the example shown, we see that there was a conflict between 2 drivers trying to the same IO port range. At this point you will need to make an assessment of what to do next. If you are an experienced Windows NT user you can use the NT Diagnostics to look into resource conflicts and begin to sort out the various problems. However if you are not very experienced with Windows NT, then you will need to get additional help.

2. Another very useful tool that will enable you to help diagnose your system is the "NT Diagnostics" option that is listed in the same "Administration Tools" menu that was discussed above. When this option is chosen, a dialog window similar to the following will be displayed:

As you can see, the NT Diagnostics window provides numerous capabilities, far more than we can touch on here. If you are interested in this, we recommend that you purchase a book on using Windows NT. In general, for the purposes of STISIM Drive, the "Resources" tab is the most important section of the NT Diagnostics option. When you click on the Resources tab, a display similar to the following will be displayed:

Along the bottom of the resource tab, there are a group of buttons that allow you to view the systems IRQs, I/O Ports, DMA, Memory, and Devices. The information contained in these various options can help you debug problems that are occurring. For example, the IRQ listing will display all of the IRQs that are currently being used by the system. By default STISIM Drive uses interrupt 9 for controlling the optical encoder interface and if interrupt 9 is being used by a different process the WinRT driver will not run and an error will be generated. The listing displayed here will show you if another process is using interrupt 9 or not, and if so, then changes will need to be made.

Once again this section was intended to introduce you to potential ways of solving problems and is not a tutorial on solving Windows NT problems. If you continue to have problems, you should consult with an NT expert or purchase a book that discusses NT problem solving.