In short: OpenSTAAD is the programming interface that ships with STAAD.Pro. With a few lines of C# you can read nodes, members, sections and results from an open model, and write geometry and loads back into it. This OpenSTAAD tutorial walks you from an empty project to a working script that exports support reactions.

If you have ever copied support reactions from STAAD.Pro into Excel one load case at a time, you already know why OpenSTAAD exists. It turns STAAD.Pro into something you can talk to from code, so the boring parts of modelling and post-processing can run in seconds instead of hours.

What OpenSTAAD actually is

OpenSTAAD is a COM (Component Object Model) library installed with STAAD.Pro. Any language that can talk to COM can use it: VBA inside Excel, Python, and C#. When STAAD.Pro is running with a model open, your program connects to that running instance and calls functions on it.

The functions are grouped into a few objects you will use constantly:

  • Geometry: nodes, members, plates, their coordinates and connectivity.
  • Property: section names and properties assigned to members.
  • Load: load cases, combinations and the loads inside them.
  • Output: analysis results such as displacements, member forces and support reactions.
  • Support and Design: support conditions and design parameters.

Everything you see in the STAAD.Pro editor and output viewer is reachable through these objects. The exact list of functions depends on your STAAD.Pro version, so keep the OpenSTAAD reference that ships with your installation open while you work.

Why C# rather than VBA or Python

VBA inside Excel is where most engineers start, and it works. But it becomes painful as soon as a macro grows beyond a page: no proper debugging, no packaging, and fragile references.

C# gives you:

  • A real editor and debugger. Visual Studio Community is free and lets you step through code line by line while STAAD.Pro is open.
  • Strong typing. Mistakes like passing a member number where a load case was expected are caught before you run anything.
  • Distributable tools. A C# project can become an installer you hand to your whole team, which is how most commercial STAAD.Pro add-ins are built.
  • One language for many APIs. The same skills carry over to the ETABS/SAP2000 API, Revit, Tekla, AutoCAD and Excel automation.

Python is a fine choice too, especially for quick analysis. If you plan to build tools other people will install and use daily, C# is the more practical path.

Setting up the project

  1. Install Visual Studio Community with the ".NET desktop development" workload.
  2. Create a new Console App (.NET Framework) project targeting .NET Framework 4.8. COM interop with running applications is simplest on .NET Framework; newer .NET versions need extra work to attach to a running instance.
  3. Add a reference to the OpenSTAAD type library: Project → Add Reference → COM, then find the OpenSTAAD entry installed by STAAD.Pro. Visual Studio generates the interop types for you.
  4. Open STAAD.Pro, load a model that has been analysed, and leave it open.

Connecting to the running STAAD.Pro

The first job of any OpenSTAAD program is to attach to the instance that is already open:

using System;
using System.Runtime.InteropServices;

class Program
{
    static void Main()
    {
        // Attach to the STAAD.Pro session that is already running.
        dynamic staad = Marshal.GetActiveObject("StaadPro.OpenSTAAD");

        string file = "";
        staad.GetSTAADFile(ref file, true);
        Console.WriteLine($"Connected to: {file}");
    }
}

Using dynamic keeps the first steps simple. Once your script works, switch to the generated interop types so Visual Studio can autocomplete function names and check argument types.

If GetActiveObject throws, STAAD.Pro is either not running or was started with different user permissions from Visual Studio. Run both normally (or both as administrator) and try again.

Reading the model: nodes and members

With a connection in hand, reading geometry is a loop:

dynamic geometry = staad.Geometry;

int nodeCount = geometry.GetNodeCount();
int memberCount = geometry.GetMemberCount();
Console.WriteLine($"{nodeCount} nodes, {memberCount} members");

int[] members = new int[memberCount];
geometry.GetBeamList(ref members);

foreach (int m in members)
{
    int start = 0, end = 0;
    geometry.GetMemberIncidence(m, ref start, ref end);
    double length = geometry.GetBeamLength(m);
    Console.WriteLine($"Member {m}: {start} → {end}, L = {length:F3}");
}

Pay attention to units. OpenSTAAD returns values in the model's base units, which may not be the units you see in the editor. Decide on a unit convention at the start of your program and convert once.

Reading results: support reactions

Now the part that saves real time. For each support node and each load case, ask the Output object for the six reaction components:

dynamic output = staad.Output;

int[] supportNodes = { 1, 2, 3, 4 };   // replace with your support list
int[] loadCases = { 101, 102, 103 };   // replace with your combinations

foreach (int lc in loadCases)
{
    foreach (int node in supportNodes)
    {
        double[] r = new double[6];   // FX, FY, FZ, MX, MY, MZ
        output.GetSupportReactions(node, lc, ref r);
        Console.WriteLine($"LC {lc}, node {node}: FY = {r[1]:F2}");
    }
}

From here, writing the numbers into a formatted Excel workbook (with ClosedXML or EPPlus) is a small step. That is essentially what a reactions exporter does, plus a proper interface and error handling.

Writing to the model

OpenSTAAD is not read-only. The same Geometry and Load objects let you add nodes and members, assign properties and create load cases. A common pattern for repetitive structures:

  1. Generate the grid of nodes from a few parameters (bays, spans, heights).
  2. Connect them with members in a loop.
  3. Assign sections and supports.
  4. Create load cases and apply loads.

Always work on a copy of the model while you develop a writing script, and save before running it. A bug in a loop can add thousands of members in a second.

Mistakes to avoid

  • Hard-coding member and node numbers. Read them from the model instead, or from the user's current selection, so the tool works on any model.
  • Assuming results exist. Check that the model has been analysed (and that the analysis is current) before reading output.
  • Ignoring units and sign conventions. Confirm your numbers against the STAAD.Pro output viewer for one node and one load case before trusting a full export.
  • Building everything at once. Get one small, useful script working end to end. Then improve it.

Where to go next

Once you can connect, read and write, the useful projects follow quickly: exporting reactions and member forces, generating repetitive frames, assigning design parameters to groups of members, and producing take-offs. Each one removes a task you currently do by hand.

If you prefer a structured path, our course on AI + OpenSTAAD walks through these scripts step by step, including using an AI assistant to write and debug the code with you. And if you just want the result without writing code, the tools in our store do exactly these jobs out of the box.