Starting Sequence and Batch File Use for ProSim737 Avionics Suite

Splash screen - Prosim737 main module (startup sequence added)

Introduction

A full cockpit simulator that emulates Boeing 737 avionics is far more complex than a desktop flight simulator. A full cockpit simulator integrates multiple hardware components, a complete avionics suite, and several layers of ancillary software. Each component, whether responsible for flight controls, cockpit displays, or system logic must communicate reliably with the others to maintain a seamless and accurate simulation environment.

Because the system’s components are interdependent, the software must be started and shut down in a logical sequence to maintain stability, performance, and consistent behaviour. This is especially important when multiple applications are part of the same workflow, as each component may depend on specific services, configuration states, or background tasks being completed prior to initialisation.

This guide outlines the recommended startup sequence for the ProSim737 avionics suite. It also describes the key components involved and introduces batch files as a practical method for automating the process, ensuring that the flight simulator and its supporting software start and shut down in a controlled and predictable sequence.

Terminology Note: In this article, the terms run, launch and start are used interchangeably.

ProSim737 - Module Instances and Configuration

The ProSim737 avionics suite is designed to operate in both single and multi-computer environments. To support this flexibility, the platform allows a variety of system configurations, including running multiple instances of the same module simultaneously. The only exception is the ProSim737 main module, which must be installed on the server computer running Flight Simulator.

This capability allows individual modules to be tailored to specific functions, providing flexibility in how displays, audio, and other systems are configured. For example, a single display module can be started multiple times to serve different cockpit functions. Four instances can provide the Captain’s and First Officer’s Primary Flight Displays (PFD) and Navigation Displays (ND).

The same principle applies to the audio module. Multiple instances can run in parallel, enabling specific sounds, such as callouts, system alerts, or environmental audio, to be routed to different speakers throughout the simulator.

Typical ProSim737 Setup

A typical Flight Simulator setup will run one or more instances of the following ProSim software:

  • ProSim737 main module.

  • ProSim IOS (Instructor Operator Station).

  • ProSim Display module.

  • ProSim Audio module.

  • ProSim Hardware Connector.

  • ProSim CDU.

  • ProSim Overhead (main panel).

  • ProSim Chrono module (clock and timer).

More complex setups may involve both server and client computers, with multiple instances of the same components running across the network. To ensure proper communication between these modules, the ProSim737 main module must be running and active, as it manages all interactions within the ProSim737 avionics suite.

ProSim737 Module Startup and Communication Logic

The most important module in the ProSim737 family is the ProSim737 main module, which serves as the central controller and must be running and initialised before other modules can communicate.

When run, the ProSim737 main module will:

  • Scan the network for other ProSim modules;

  • Establish communication channels (typically via TCP/UDP);

  • Begin sending and receiving data packets; and

  • Activate the other modules, which ‘wake up’ once communication is established (if in standby mode).

If any other ProSim module is opened before the main module, it remains idle; it processes no flight data, performs no system initialisation, and generates no errors - until a connection with the main module is established. Therefore, running modules in standby mode does not harm the software or corrupt any files.

Although ProSim737 is robust and capable of connecting to its sister modules, starting modules in standby mode before the main module can sometimes cause issues. These may include the main module failing to connect to the server, or individual modules not receiving data or functioning correctly.

For this reason, it is recommended to start the ProSim737 main module first. Once it is running, the remaining modules can be opened to ensure a clean connection and a smooth startup process.

If the main module fails to connect, or if an individual module is not functioning correctly, simply close all ProSim modules and restart them. Flight Simulator and other supporting programs can remain running.

Important Point

  • ProSim737 modules can be started in any sequence. However, for the most logical, reliable, and consistent operation, it is recommended to start the main module first, allow it time to initialise, and then start the remaining modules.

When to Start Flight Simulator and ProSim737

For the ProSim737 avionics suite to operate correctly, it is important to follow a logical startup sequence. Begin by starting Flight Simulator, loading a flight, and positioning the aircraft on the runway with the wheel brakes applied to prevent unintended movement. Once Flight Simulator is running correctly, start the ProSim737 main module. After the main module has opened and the software has initialised, the remaining modules can be started.

Launching modules in the wrong sequence will not damage the software, but following a controlled startup sequence ensures each application has time to initialise, establishes clean inter‑module communication, reduces the risk of conflicts, and allows background services to stabilise before use.

Flight Simulator should be started first because ProSim737 relies on several layers of software hierarchy that must communicate with Flight Simulator before the main module can initialise successfully.

Ancillary Software

Although real‑world testing has shown no issues, it is good practice to start any additional software only after Flight Simulator and ProSim737 are running, unless the additional software’s own manual specifies a different startup sequence.

Active Sky

Active Sky (ASFS) is widely used by ProSim737 users because it provides realistic rainfall returns on the weather radar. Hi‑Fi recommends starting Active Sky before launching Flight Simulator so that the desired weather can be viewed and selected prior to loading a flight. However, this is not essential, Active Sky can also be started after Flight Simulator is already running.

Since the ProSim737 main module reads weather information during its startup sequence, it is best to have Active Sky running with the weather already selected (or live weather downloaded and displayed) before starting the main module.

Recommended Starting Sequence

After Flight Simulator and the ProSim737 main module have been started, there is no specific sequence that the remaining modules should be opened. The following is a suggestion:

  1. Flight Simulator.

  2. ProSim737 main module (wait until running and initialised).

  3. ProSim Hardware Connector (if required).

  4. ProSim Display module (Captain and First Officer-side PFD, ND and EICAS - any sequence).

  5. ProSim Audio module (s).

  6. ProSim Chrono module.

  7. ProSim Overhead (main panel).

  8. ProSim other components/displays (if required).

  9. ProSim CDU.

  10. Ancillary Programs.

Note: In this startup sequence, Active Sky (if used) may be started either after Flight Simulator but before starting the ProSim737 main module, or prior to starting Flight Simulator.

Closing ProSim737, Flight Simulator and Ancillary Programs

There is no officially defined shutdown protocol, and depending on your setup, it may be necessary to keep the ProSim737 main module running to use the IOS for closing client computers (For IOS to function, it must maintain a connection with the main module). The following shutdown sequence is therefore recommended:

  1. Close ancillary programs.

  2. Close all ProSim components and displays.

  3. Close ProSim IOS.

  4. Close ProSim737 main module.

  5. Close Flight Simulator.

Batch File Use

Batch files provide an efficient way to automate repetitive tasks within a simulator environment. When configured correctly, they streamline the startup and shutdown of multiple applications, reduce operator workload, and ensure programs run in a controlled, predictable sequence.

This section offers an overview of batch file usage, key concepts, and common syntax relevant to ProSim737 and associated Flight Simulator software.

Function of Batch Files

A batch file is a simple script that executes a series of Windows commands automatically. In a simulation environment, batch files are particularly useful for:

  • Launching, closing, or terminating multiple programs in a defined sequence;

  • Managing timing between application launches;

  • Displaying status messages to the operator; and

  • Reducing manual input and the potential for error.

Batch files can range from very simple (one or two commands) to highly complex scripts containing logic, error handling and console display formatting.

For example, a typical startup batch file used for a simulator session may:

  • Display a formatted header;

  • Launch multiple simulator-related applications;

  • Start programs from specific directories;

  • Display confirmation messages after each command;

  • Insert timed pauses between launches (timeouts);

  • Report success or failure of each operation;

  • Display timestamps or proprietary information; and

  • Automatically close the console window after a defined delay (to allow time to read the console display message).

The batch file may also configure the console display (the pop-up window that appears when it runs) by:

  • Disabling command echoing (@echo off): prevents commands from being displayed;

  • Setting UTF‑8 encoding (chcp 65001): enables support for additional special characters; and

  • Applying custom console colors (color 2F): changes the text and background colors for improved readability.

While the advantages of a startup batch file are clear, a shutdown batch file is equally valuable. Both provide significant time savings and offer a convenient, one‑click method for opening or closing a flight simulator session.

Special Note - Shutting Down Active Sky

Active Sky requires a graceful, timed shutdown. Closing the program without allowing sufficient time can prevent it from shutting down correctly, which may cause it to fail to connect to its server the next time it is started.

If the batch file does not close Active Sky properly, it is recommended to close the program manually. This can be done either by clicking the X in the top-right corner of the window or by right-clicking the Active Sky icon in the Taskbar and selecting Close.

System Stability and Timeouts

Launching multiple programs simultaneously using a batch file can sometimes overload system resources or cause applications to initialise incorrectly, particularly when network connections must be established before proper operation. To prevent this, it is recommended to include a short pause between commands to allow for:

  • Completion of background processes;

  • Graceful initialisation of programs; and

  • Establishment of stable connections for network-dependent modules.

Most ProSim737 modules initialise quickly, and a one-second pause between each module is usually sufficient. However, some modules may require slightly longer delays if additional startup time is needed or if the computer is operating under limited resources. The ProSim737 main module typically takes the longest to initialise; however, a slight overlap during the startup of other modules rarely, if ever, causes issues.

When the main module runs on a server machine and the remaining modules run on a client machine, it should be allowed to fully initialise before starting any client-side modules. This ensures that all dependent components can connect cleanly and helps prevent unnecessary connection errors.

Important Point

  • Timeouts are strongly recommended in startup scripts. During shutdown, they are optional but still beneficial, as programs may require time to save data and close gracefully.

Creating a Batch File

  1. Start Notepad.

  2. Enter the file path and desired batch commands.

  3. Save the file: choose Save As - All Files and apply the .bat extension.

  4. Create a desktop shortcut if desired (the shortcut can also be pinned to the Taskbar).

Note: The batch file can be edited at any time by right-clicking the file and selecting Edit.

Because batch syntax is extensive, the most practical way to learn is to adapt an existing working script. Sample batch files are available for download in the file download section (Batch Files ProSim737 Advanced).

If you search the Internet, you will find several methods to create batch files of varying complexity. Often, there are multiple ways to accomplish the same task.

Important Point

  • Long file paths are easy to mistype. To copy a file path accurately:

  1. Hold Shift and right-click the file; and

  2. Select Copy As Path.

The copied path can then be pasted into Notepad along with the appropriate batch command.

Common Batch Commands

There are many batch commands that can be used. Table 1 outlines some of the more common commands used.

TABLE 1: Common batch file commands

My Preferences

I do not use a batch file to start Flight Simulator (MSFS 2020/2024) or Active Sky.

Flight Simulator can take considerable time to load, depending on connection speeds, and it is important that the software starts gracefully without competing processes. I manually start Active Sky from a taskbar shortcut after Flight Simulator is running and the aircraft is stable at the selected airport.

I do use batch files to start the ProSim737 main module and other ProSim components on both server and client computers. A corresponding closure batch file shuts down all programs on the server and client machines.

Sample Batch Files

In the sample closure batch file (see the gallery and download section), several programs are listed; some which may not be running when the batch file is executed. This is intentional, as different programs are often used during testing. In practice, executing a batch file that attempts to close programs not currently running has no effect - Windows simply ignores the command without causing any issues.

Troubleshooting Starting Sequence and Batch File Issues

Startup problems with ProSim737 are most often caused by connection issues between the ProSim737 main module and its associated modules. If errors occur during startup:

  1. Allow sufficient time for the ProSim737 main module to start and initialise. Ensure the module connects to the server and fully initialises before starting any other modules.

  2. If problems persist, especially after installing an update, the recommended approach is to:

  • Uninstall ProSim737 and reinstall the latest full (non-beta) release (including modules).

  • After confirming that version works correctly, you may then update to the latest beta if desired.

Important Point

Many startup problems can also related to batch files, particularly if you are unfamiliar with their syntax or directory paths. If a batch file does not function as expected, check that:

  • All directory paths are correct;

  • Commands are typed accurately; and

  • Appropriate delays (timeouts) are included between module launches (if required).

Additional Information

Final Call

Starting ProSim737 modules in the wrong sequence will not damage the software, but following a logical startup sequence and allowing each application time to initialise helps the system establish clean, reliable communication between modules - particularly the ProSim737 main module. By following this controlled startup approach, the likelihood of conflicts is reduced, background services have time to stabilise, and the environment for running Flight Simulator becomes more stable.

To help maintain this stable environment, batch files automate the sequence: they start and close each program in a consistent, methodical sequence, reinforcing the clean startup conditions the system relies on for stable inter‑module communication.

Gallery

Screenshots of batch file examples, batch file syntax colour table and common batch syntax commands.

Scale ID Annunciation (RW/APP CRS Error)

Scale ID Annunciation display in upper left hand corner of the Primary Flight Display

The Scale ID annunciation (often called the approach reference), displayed in the upper left of the Primary Flight Display (PFD), is one of a suite of displays that comprise the PFD Navigation Performance Scales (NPS) Indications. 

In the image a runway approach course error (RW/APP CRS Error) is being displayed.  The airport is Hobart, Tasmania and the ILS approach is to runway 12.  The error has been generated because the CRS window in the MCP has the incorrect approach course (140 degrees).  If the approach course was correct, the display would be coloured white - not amber with a strike-through line.

The Scale ID Annunciation display provides, the for the selected approach type, the following approach reference information:

  • Airport identifier;

  • Runway approach course;

  • Distance to the runway threshold; and,

  • Approach type.

The display also indicates whether a runway approach course error (RW/APP CRS) has occurred.

Possible approach type displays include:

  • LNAV/VNAV (LNAV and VNAV deviations).

  • LOC/VNAV (Localiser with VNAV deviation).

  • FAC/VNAV (IAN final approach course with VNAV deviation).

  • LNAV/G/S (LNAV deviation and glideslope).

  • LNAV G/P (LNAV deviation with IAN glidepath).

  • ILS (ILS approach).

  • FMC (IAN approach).

  • GLS (GLS approach).

Airport Identifier and Display Colour

The airport identifier comprises the identifier and airport name (abbreviated).  The identifier will change depending upon the approach type.  For an ILS (and IAN approach) the identifier will be the letter I followed by the airport abbreviation.  For example, Hobart airport is YMHB.  In this case for an ILS approach the airport identifier will be IHB.

The identifier is displayed in two colours: white and amber; amber being cautionary.  The later also incorporates a strike-through line (this line dissects the airport identifier and approach course).

White indicates that all the parameters required for the approach have been completed correctly.  An amber colour/strike-through indicates that one or more of the required parameters have not been met.

Colour Combinations

The following colour combinations can be observed (further information is discussed later in the article). 

  • Frequency and approach course displayed in white:

When the navigation radio is tuned to the ILS frequency, the identifier will initially display the ILS frequency (109.90) for the approach.  The frequency will then change to display the airport identifier (IHB).  Whether the colour displayed remains white or changes to amber will depend on whether both navigation radios and CRS course windows are set to the correct ILS approach.

If either display is coloured amber it indicates a RW/APP CRS error has occurred.

  • Airport Identifier displayed in amber:

One navigation radio is tuned to the ILS frequency.  Tuning the second radio to the same frequency will cause the display to change from amber to white.

  • Approach course displayed in amber:

One or both courses in the CRS course windows (MCP) is not set to the correct ILS approach course.

  • DME and approach type:

The DME and approach type (ILS) are always displayed in white.  The DME will display the distance to the runway when the glideslope is captured by the aircraft.

Pre-Approach Tasks

Prior to commencing an approach, the following should be carried out:

  • The correct frequency entered into to the navigation radios (NAV 1 & NAV 2);

  • The correct approach course (for the runway selected) entered into the Captain and First Officer side CRS course windows in the MCP;

  • An appropriate approach selected from the FMS database (depends on the approach type being used); and,

  • The approach course for the runway entered into the heading window in the MCP.

Delay

The logic controlling the scale ID annunciation periodically interrogates that data entered into the navigation radios and MCP.  This means that a delay is often observed between the annunciation changing colour from white to amber or back again.  I am unsure of the timing.

Discussion

The indication that a RW/AP CRS error has been triggered doesn’t alwasy preclude an approach from being carried out (although it’s not recommended).  The annunciation indicates that, for the selected approach, something hasn’t been completed with regard to the configuration of the avionics.  It's rarely the case that the frequency hasn't been correctly entered into to the navigation radio; more often than not the cause of the annunciation is a CRS course discrepancy, or failure to configure the second navigation radio to the same frequency as the controlling navigation radio.   

Using the ILS approach as an example.  To correctly configure the instruments for an ILS approach and not receive a cautionary warning, the following must be completed:

  • Enter the correct ILS frequency into the BOTH navigation radios; and

  • Enter the correct approach course into BOTH the CRS course windows in the MCP.

It’s also recommended, but not mandatory to:

  • Enter the approach course into the heading window in the MCP; and

  • Enter an appropriate approach into the CDU/FMC.

If you enter the ILS frequency into the controlling navigation radio, and enter a different frequency into the other navigation radio, an amber-coloured RW/APP CRS annunciation will be generated.  Likewise, a caution will occur if the Captain-side and First Officer side CRS windows don’t display the identical ILS approach course.

IMAGE A-1: ILS approach into runway 12 for Hobart, Tasmania (IHB).  The approach course for this approach is 120 degrees.  The controlling navigation radio (Captain-side/not shown) has been set to the correct ILS frequency (109.90).  The heading that the aircraft is flying is 120 degrees, and the compass rose is offset to the course direction that is displayed in the Captain-side CRS window (140 degrees)

Example (Hobart, Tasmania IHB)

Image A-1 shows an ILS approach into runway 12 for Hobart, Tasmania (IHB).  The approach course for this approach is 120 degrees.  The controlling navigation radio (Captain-side/not shown) has been set to the correct ILS frequency (109.90).  The heading that the aircraft is flying is 120 degrees, and the compass rose is offset to the course direction that is displayed in the Captain-side CRS window (140 degrees).

In the example, a RW/APP CRS annunciation has been triggered for an ILS approach.  The airport identifier and approach course are coloured amber with a strike-through line.   The DME is 9.4 miles and is coloured white (correct data).

This approach can be flown despite the discrepancy between the four courses (120, 180, 130 & 140 degrees) and a RW/APP CRS annunciation.  This is because the ILS approach course (120 degrees) is coupled to the ILS frequency set in the controlling navigation radio  – not the course as indicated in the CRS windows in the MCP. 

In the example you can see that the localiser has been captured (this is identified by the magenta-coloured course deviation line being centered/in-line with the course pointer) despite the CRS window displaying a course of 140 degrees.  Once the aircraft has captured the localizer it will fly the localiser heading no matter what course is displayed in the CRS window (provided it does not exceed 90 degrees).

While this example holds true for an ILS approach other approach types may behave differently.

Important Points:

  • The scale ID annunciation is an amber-coloured display that annunciates when the avionics have not been correctly configured for the selected approach.  The display is a cautionary.

  • The approach cannot be flown If the CRS course discrepancy is greater than 90 degrees from the ILS approach course.  This is because the aircraft will follow the direction of the course set in the CRS window (if greater than 90 degrees).

ProSim-TS

The ProSim737 avionics suite replicates the RW/APP CRS logic used in the real aircraft. 

Database Inconsistencies

In some instances the annunciation is displayed despite entering the correct information.  A possible reason for this is a scenery navigation database inconsistency. 

In older scenery designs the physical location of the localiser beacons was part of the scenery file and this information is what the simulator referred to.  With the advent of up-to-date navigational points (supplied by Navigraph) the simulator now refers to a navigational database rather than a scenery database.  An inconsistency will occur if there is a discrepancy between the location of the localiser beacons in the scenery and the information recorded in the navigational database.

Final Call

The RW/APP CRS annunciation, although confusing to the uninitiated, does not necessarily mean that an approach cannot be carried out.  However, it’s prudent before flying the approach to understand why the RW/APP CRS error has been displayed. 

In more cases than not, the reason for the cautionary annunciation is a failure to configure the navigation radios to the same frequency and/or enter the same ILS approach course into both the CRS course windows in the MCP.

ProSim737 IOS - Unconventional Settings

The user interface in the Instructor Operator Station (IOS) allows the user to customise several functions, in addition to enabling or disabling specific options.  Whilst most of the functions are straightforward, there are several options that are unconventional and therefore, probably not clearly understood.

Read More

Hour Meter Records Service Life of Simulator Components

Analogue meter mounted to the lid of the Throttle Interface Module (TIM).  The meter, powered by 12 volts, records whenever power travels through the 12 volt system to the module

How many times have you underestimated the use of an item, to discover that the last time you changed the oil in the lawn mower was 15 years ago!

Aircraft, boats, heavy machinery and many other items, that require regular servicing, have an hour meter to provide an accurate time that a piece of equipment, such as an engine has been operating.

A flight simulator is made from many components.  Some components will last for many hundreds, if not thousands of hours use, however, other parts have inbuilt obsolescence and will eventually fail.

Failing Power Supply

Recently, I had a problem whereby the internal hub in the Throttle Interface Module (TIM) would intermittently disconnect.  The cause of the problem was the fluctuating output of the 5 volt mini power supply (MeanWell RS-15-5 Volt 3 amp) that amongst other things, powers the hub. 

I was perturbed by the failure as I was sure the power supply was only a few years old.  However, after consulting the service booklet I maintain for the simulator, I noted the unit had been installed 5 years ago and had been operating for 2054 hours.  The part had, in my opinion, well and truly provided excellent service life considering the hours it had been operational.

Hour Meter

At the onset, when I designed the framework upon which the simulator would operate, I included two hour meters that would 'tick on endlessly' whenever power was turned on to the simulator or to specific systems within the simulator.

One meter resides in the Throttle Interface Module (TIM) and records the hours of use for the interface cards, motor controllers, power supplies, relays and other components that operate the throttle and autothrottle system.   A separate, but similar meter records the overall use of the simulator (the time that the simulator has been receiving power).

An hour meter is straightforward to install and can be connected directly to a 12 volt power supply (or busbar) that is always receiving power.  The meter (s) can easily be mounted anywhere on the simulator, whether it be inside the center pedestal, the rear of the Main Instrument Panel (MIP), or to a standalone module. 

The meters I am using are analogue, however, digital meters can also be purchased.  The downside of using an analogue meter is that as each increment moves through its cycle it generates a clicking sound; depending upon the location chosen to mount the meter the clicking sound may be annoying.  However, an advantage of an analogue meter is that once the hours have been recorded on the meter, the information cannot be lost; a digital meter can loose the information if, for example, the backup battery fails.

Final Call

Memory for the most part is fickle, and unless trained, most people underestimate the  time that a component has been used.  An hour meter connected to the simulator, enables an accurate record to be kept to how long specific parts have been operating.