Common Samples

Top  Previous  Next

These common sample applications demonstrate the use of the runtime API in varying ways using all available interfaces. The exact syntax for each common sample is different depending on the language and the interface used, but the examples are designed to perform identically across interfaces to showcase how to use each language in an analogous manner.

 

To build and run the sample applications written for the C# interface in Windows, open the solution file (examples.sln) in Visual Studio 2013 and later. Alternatively, building and running the sample applications written for the C/C++ interface in Linux requires you use the GNU C compiler (gcc) to compile the C file for each sample application. The syntax for building each example follows.

 

gcc -ldl <EXAMPLE FILENAME> -o <OUTPUT FILENAME>

 

In addition to being provided for each interface language, the functionality demonstrated in each of these common samples is implemented in similarly-named Matlab m-files using the C# and Java runtime API interfaces to demonstrate how to use the runtime API to control FreeFlyer from within Matlab. Information regarding the configuration of Matlab to work with the C# and Java interfaces is included in readme files in the respective example directories.

 

Jump to an application description in the following table:

 

Example

Generating Output Windows

Running A Mission Plan

Reusing an Engine

Simple Two Engine Asynchronous

 

 

Error Handling

This application shows how Mission Plan diagnostics can be used to handle errors in an application using the runtime API. First, it loads a Mission Plan and sets the semi-major axis of a Spacecraft to 6400 km. Since this SMA is smaller than the equatorial radius of the Earth we expect that the Spacecraft will impact the Earth when it is propagated, thus throwing a runtime error. After the SMA is set the rest of the Mission Plan is executed, as expected an error is thrown and the diagnostic information is reported to the console.

 

Generating Output Windows

This application demonstrates the use of engine constructors to generate output windows using the runtime API. It creates an engine using the necessary constructor arguments and then loads and executes a Mission Plan performing simple coverage and contact analyses. The output workspace created as part of this application will remain open until you press enter on the command prompt.

 

 

The contact analysis performed by the application

The contact analysis performed by the application

 

For more information on the topics covered by this example, see the Using the Runtime API guide.

 

Running A Mission Plan

This application shows very simply how to load a Mission Plan with an engine and then interact with it via the use of varying expressions. It loads a Mission Plan, runs to a point where it requires input from the API as to the initial state of the Spacecraft object, performs some propagation, and then reaches a point where it can provide the propagated state back to the API, where it is then printed to standard output.

 

For more information on the topics covered by this example, see the Using the Runtime API and Expression Handling guides.

 

Reusing an Engine

This application demonstrates using an engine to run two Mission Plans sequentially using synchronous calls by first loading up one Mission Plan, executing it, and then using the results from that first Mission Plan as an input to the second Mission Plan. In this application, the first Mission Plan being run is to generate the magnitude of a burn to be used, and the second Mission Plan actually implements a burn with that magnitude. This is similar to the ground system architecture that many groups use.

 

For more information on the topics covered by this example, see the Using the Runtime API guide.

 

Simple Two Engine Asynchronous

This application uses two engines to run two Mission Plans simultaneously using asynchronous data to coordinate information between the two Mission Plans and synchronization points to synchronize the Mission Plans at different stages to get the data from the first Mission Plan into the second Mission Plan when it needs it. In this application, the first Mission Plan being run is to generate the magnitude of a burn to be used, and the second Mission Plan actually implements a burn with that magnitude. This is similar to the ground system architecture that many groups use.

 

For more information on the topics covered by this example, see the Using the Runtime API and Asynchronous Programming guides.