PSCAD Custom Component Parameters: Field Types, Content Types & Fortran Modeling

Part A — PSCAD Custom Component Parameters at a Glance

Every electromagnetic transient (EMT) study of an inverter-based plant eventually depends on custom components: a plant power controller (PPC) written in Fortran, a vendor-supplied inverter model wrapped in a user-defined component, a protection function, a test harness. The control logic in these components gets the attention. The parameter fields that feed them rarely do — yet the way a parameter is defined decides whether a setpoint can change during a run, whether a mode switch works, whether an array is legal, whether a unit conversion is applied, and whether a careless entry is caught before it silently corrupts a study.

The parameter field types

3.2 Integer fields



Use Integer only for genuinely whole quantities: number of inverters, number of parallel strings, array sizes, indices, discrete step counts. Common pitfalls:

3.3 Worked example: integer arithmetic in a gain

A designer computes a per-inverter share of a plant reactive command:

Qinv = Qplant * (1/Ninv)

If Ninv is an Integer equal to 40, the expression 1/Ninv is evaluated in integer arithmetic and equals 0. Every inverter receives a zero command. The fix is to force real arithmetic:

Qinv = Qplant * (1.0/REAL(Ninv))

In Keentel's illustration (Figure 1, panel 3), the same error in an integral gain written as (1/2)*16 produced Ki = 0, and the voltage controller never acted. The plant's POI voltage settled at 0.896 pu instead of 1.000 pu, with no error message — exactly the kind of silent failure that survives into a study report unless the model is tested systematically.

3.4 Choice fields

Choice fields present a list and pass an integer value to the code. They are ideal for:

• control mode selection (Q, voltage, power factor, voltage droop);
• model variants (grid-following or grid-forming; detailed or average model);
• test options (which disturbance to apply);
• protection settings groups.

Good practice:

3.5 Worked example: mode-dependent behavior

In Keentel's illustration, a 100 MW plant on an SCR 3 grid (X = 0.333 pu on plant base) delivers 1.0 pu active power. The steady-state POI voltage with reactive injection Q satisfies:

A study that runs in the wrong mode — or that does not document the mode — can misstate the plant's voltage support by more than 10%.

3.6 Logical and Boolean fields

Logical fields pass true or false values to Fortran for run-time decisions (for example, enabling an over-voltage ride-through function). Boolean fields are typically used for selections that drive conditional expressions — enabling other fields or graphics layers — at build time. Choose Logical when the code needs the value; use conditions to manage the dialog.

3.7 Text, Complex and Table fields

• Text fields hold strings such as file names for recorded data or descriptive labels. Paths should be relative to the project where possible so models are portable.
• Complex fields are convenient for impedances and phasors but should be documented clearly because users may enter rectangular or polar values inconsistently.
• Table fields hold curves such as reactive capability tables or ride-through characteristics; they must be validated for monotonic input values where interpolation is used.

4. Choosing content types

4.1 Decision table

4.2 Setpoints must usually be Variable

Model validation and grid-code compliance tests require setpoint changes: voltage reference steps, reactive power steps, active power ramps, frequency droop changes. IEEE 2800.2 test procedures, NERC MOD-026 and MOD-027 verification, and ISO/RTO model quality tests commonly include such steps. If the PPC's voltage reference is defined as Literal, each step test requires a model edit, which is error-prone and does not represent the plant's operating behavior.

4.3 Worked example: setpoint step test

In Keentel's model (Figure 1, panel 2), Vref defined as Variable and driven by a sequencer signal steps from 1.00 to 1.02 pu at 12 s. The POI voltage follows within about 0.6 s, with reactive output rising from 0.267 to 0.327 pu. With Vref as Literal or Constant, the same test cannot be performed in one run.

4.4 Constant parameters and build-time computation

Constant content is useful for derived values computed once: base impedances, per-unit conversions, filter coefficients. Moving calculations into the Computations segment rather than repeating them every time step reduces run time and clarifies the code.

4.5 Worked example: computing filter coefficients once

A first-order measurement filter with time constant Tf discretized with the trapezoidal rule at time step Δt has coefficients:

For Tf = 0.02 s and Δt = 50 µs, a = 0.99750 and b = 0.00125. If Tf is Literal or Constant, a and b can be computed once at build time. If Tf is Variable (for tuning during a run), the coefficients must be recomputed when Tf changes — and the code must handle that explicitly.



5. Fortran practice for custom components

5.1 State storage

EMTDC calls component code every time step. Values that must persist between steps (integrator states, filter outputs, previous inputs, timers) must be kept in storage arrays allocated with #STORAGE and accessed with the storage pointers, or managed by PSCAD's built-in conventions. Local variables are not preserved between calls.

5.2 Initialization

5.3 Time-step independence

Control code should produce results that do not depend materially on the simulation time step, within a reasonable range. Discretize continuous-time controllers with consistent methods (trapezoidal integration is common in EMTDC), and use the simulation time step variable rather than hard-coded values.

5.4 Worked example: integrator discretization

A PI controller with gains Kp and Ki discretized with the trapezoidal rule:

Anti-windup must limit x when u saturates. A common error is limiting u but not x, which causes overshoot and slow recovery after limits are released — a behavior that shows up as poor fault recovery in ride-through tests.

5.5 Sampled controllers

Real PPCs and inverter controllers run at discrete sample rates (for example, a PPC at 10 to 100 ms intervals with communication delays). Representing the actual sample rate and delays in Fortran — rather than running the controller at the EMT time step — is often essential to reproduce real plant behavior and control interactions.

5.6 Numerical edge cases

5A. Worked example: designing the parameter form for a plant power controller

The following parameter set is typical of a Keentel-built PPC component for a 100 to 300 MW solar or storage plant. It illustrates how field type, content type, units and limits are chosen together.

5A.1 Configuration category

5A.2 Setpoint category

5A.3 Control gains and limits category

5A.4 Rationale

• Mode as Choice makes the agreement-required mode explicit and testable.
• Setpoints as Variable allow validation step tests and operator-style changes during a run.
• Gains as Constant allow them to be computed from other parameters (for example, scaled by SCR) while keeping build-time evaluation and efficiency; a "tuning" variant of the component can expose them as Variable when needed.
• Timing parameters as Literal reflect fixed hardware characteristics.
• Logical enable flags pass directly to Fortran decisions.
• Limits on every field catch unit and sign errors.

5A.5 Mode logic in Fortran

The Choice value drives a SELECT CASE construct in the Fortran segment. In outline:

SELECT CASE ($Mode)  

CASE (1): error = Qref − Qmeas  

CASE (2): error = Vref − Vmeas  

CASE (3): error = Pmeas × tan(acos(PFref)) − Qmeas  

CASE (4): error = (Vref − Vmeas) − Droop × Qmeas  

CASE DEFAULT: report an error through the PSCAD message interface  

END SELECT

The DEFAULT branch matters: if a future revision adds a fifth option but the code is not updated, the model stops with a message instead of silently running in an undefined state.

5B. Multiple instances, storage and naming

Large plants and multi-plant studies often contain several instances of the same custom component. Problems arise when:

Keentel's model reviews always include a test with at least two instances of each custom component operating at different setpoints to catch these issues.

5C. Wrapping vendor black-box models

Many inverter vendors deliver compiled models with a Fortran or C interface. Wrapping them in PSCAD components requires care:

A frequent cause of model rejection is a vendor library that was compiled for a different compiler or PSCAD version than the reviewer's installation. Confirming compatibility early avoids weeks of delay.

5D. Run time and efficiency



EMT studies of large plants and networks can take hours. Parameter and code choices affect run time:

Worked example: execution count

A 20-second study at a 50 µs time step has 400,000 time steps. A PPC that genuinely updates every 20 ms needs only 1,000 executions of its control law; running the full law every time step executes it 400 times more often than necessary. Sampling the controller correctly both improves fidelity and reduces run time.

5E. Time-step sensitivity testing

Results should not change materially when the simulation time step changes within a reasonable range. A practical test runs the same case at, for example, 50 µs, 20 µs and 10 µs and compares key quantities:

Differences usually trace to hard-coded time steps in code, controllers that assume continuous time, or event logic sensitive to exact time values. Parameterizing time-dependent behavior correctly — using the simulation's time step variable and sample-rate parameters — resolves most of them.

6. Parameter validation with Checks and limits

6.1 Minimum and maximum limits

Every Real and Integer field should have limits that catch impossible values. PSCAD warns when entered values fall outside the defined range.

6.2 Checks segment

The Checks segment can enforce relationships between parameters, for example:

• maximum reactive limit greater than minimum reactive limit;
• PF setpoint between 0 and 1;
• filter time constant greater than twice the simulation time step;
• voltage control deadband smaller than the voltage control range.

These checks stop errors at build time rather than letting them produce plausible-looking but wrong results.

6.3 Worked example: catching a units error

A voltage setpoint entered as 138 (intended as kV) into a field expecting per unit would command a voltage of 138 pu. With a maximum of 1.1 pu, PSCAD warns immediately. Without limits, the controller drives reactive output to its maximum, the study shows severe overvoltage, and hours may be spent diagnosing a "control instability" that is really a data entry error.

7. Units and per-unit systems

PSCAD's unit system converts entries with units (for example, kV, MVA, ms) into target units for code. Good practice:

7.1 Worked example: per-unit bases in a 34.5 kV collector

A plant with 40 inverters of 3.0 MVA each (120 MVA total) connects to a 34.5 kV collector and a 34.5/230 kV main transformer. A reactive power command from the PPC in plant per unit must be converted to each inverter's base:

If the plant base were defined as the 100 MW POI rating instead of 120 MVA, the factor would be 100 ÷ 120 = 0.833, and failing to apply it would over-command inverters by 20%.

8. Model quality and US interconnection requirements

8.1 What reviewers check

8.2 Relevant requirements and guidance

8.3 Parameterization as a compliance issue

Model validation compares simulated response with field test data. To do this efficiently, the model's parameters must correspond one-to-one with the plant's actual settings, be adjustable without code changes, and be documented. A model with hard-coded gains or modes cannot be updated when settings change — and settings do change through commissioning and firmware updates.

8A. Keeping PSCAD and positive-sequence parameters consistent

US planning studies use positive-sequence models such as the WECC second-generation renewable models (REGC, REEC and REPC families) in PSS®E and PSLF, while EMT studies use PSCAD. Transmission providers increasingly compare the two. A custom PSCAD plant controller should expose parameters that map directly to the positive-sequence plant controller where the functions correspond.

Worked example: comparing a voltage step

A 2% voltage reference step is simulated in both the positive-sequence model and the PSCAD model of the same plant on the same Thevenin equivalent. If the PSCAD response settles in 2.5 s and the positive-sequence model in 1.2 s, the first suspect is a parameter mismatch rather than a modeling difference. Common causes are a gain entered on a different base (for example, plant MVA versus POI MW), a measurement filter time constant entered in milliseconds in one model and seconds in the other, or a communication delay represented only in PSCAD. Exposing these as clearly documented parameter fields with units makes such mismatches easy to find.

8B. Automated parameter sweeps

Well-designed parameters make systematic sensitivity studies practical. A typical weak-grid screening sweep for a plant controller might cover:

The full factorial set has 4 × 3 × 3 × 3 = 108 runs. Run manually, this is impractical; with an automation script that sets parameter values, runs each case and extracts damping and settling metrics, it becomes an overnight job. The results identify parameter combinations that produce poorly damped or unstable responses before they appear in an interconnection review — exactly the kind of evidence transmission providers increasingly expect for plants in low-strength areas.

Worked example: deciding which parameters to expose

A component designer must decide which internal constants to expose as parameters. Exposing too few makes the model inflexible; exposing too many invites incorrect entries. A practical rule:

8C. Worked example: units and bases in the Computations segment



Suppose a protection function inside a custom component uses an overvoltage threshold entered as 1.20 pu and a POI voltage measured in kV. The Computations segment can convert once at build time:

for a phase-to-neutral RMS comparison, or without the √3 factor for line-to-line comparison. For a 345 kV POI and 1.20 pu, the line-to-line threshold is 414 kV and the phase-to-neutral threshold is about 239 kV. Choosing the wrong form — a frequent error — shifts the trip level by a factor of 1.73, which would make an overvoltage element either useless or prone to tripping during normal operation. Computing the threshold once in Computations, with the formula documented in the help text and the result displayed on the component graphic, removes the ambiguity.

9. Testing custom components

9.1 Unit tests

9.2 System tests

9.3 Automation

Automation libraries allow scripting of PSCAD runs, parameter sweeps and results extraction. Combined with well-designed parameters (Variable setpoints, Choice modes, explicit test options), automation turns model testing from a manual exercise into a repeatable test suite — which is essential when a model must be re-verified after every vendor firmware update.

9A. Debugging a misbehaving custom component

When a custom component produces unexpected results, Keentel works through a structured checklist before changing control logic:

Most problems are found in steps 1 to 3 — in the parameter layer, not the control algorithm. That is why careful parameter design pays for itself many times over: it moves errors from late-stage study review, where they are expensive, to build time, where they are cheap.

Worked example: hand-checking a step response

For a voltage controller with integral gain KiV, a reactive power plant response lag of 0.1 s, and a network voltage sensitivity of about 1/SCR pu voltage per pu reactive power, the closed-loop voltage response behaves approximately like a first-order system with time constant:

For SCR = 3 and KiV = 8, τ ≈ 0.375 s, so the voltage should settle (within about 2%) in roughly 4τ ≈ 1.5 s, ignoring the plant lag. Keentel's illustrative model settles in about 0.6 to 1 s after a step, of the same order, confirming that gains and bases are consistent. If a PSCAD model of the same plant took 10 s, a factor-of-ten base or units error would be the first suspect.

10. A practical parameter design checklist

1. Inventory every parameter the model needs, with source documents for each value.
2. Choose the field type that matches the quantity (Real, Integer, Choice, Logical, Text, Complex, Table).
3. Choose the content type by asking whether the value must change during the run.
4. Set units, limits and default values for every field.
5. Write help text that states definition, units, base and typical range.
6. Use Choice fields for modes with explicit integer values and complete code handling.
7. Enable fields conditionally so only relevant parameters are editable.
8. Compute derived constants in Computations.
9. Write Checks for inter-parameter relationships.
10. Show key settings on the graphic.
11. Test each parameter's effect with automated runs.
12. Document the parameter set and its relationship to as-built plant settings.

10A. Documenting a custom component

Every custom component delivered for an interconnection study should be accompanied by documentation that allows a reviewer to understand and reproduce its behavior.

Good documentation shortens review cycles with transmission providers and makes models maintainable when the original developer is no longer available.

10B. Change control

Custom components evolve. Firmware updates, setting changes during commissioning and corrections after review all require model changes. A disciplined change process includes:

1. version numbering visible on the component graphic;
2. a change log in the component's Comments segment and in project documentation;
3. regression tests that rerun the standard test suite after every change;
4. comparison of key results before and after the change;
5. resubmission to the transmission provider when changes affect study conclusions or interconnection agreement settings.

11. Common misconceptions corrected

12. Key takeaways

1. Field type and content type are engineering decisions.
2. Use Real for gains and setpoints, Integer only for whole quantities.
3. Use Variable content for setpoints that must be tested or changed during runs.
4. Use Choice fields for modes with explicit, fully handled integer values.
5. Protect models with units, limits, Checks and help text.
6. Test parameters systematically with automated runs.
7. Model quality is a compliance requirement for US interconnections.

13. How Keentel Engineering helps



Keentel Engineering develops, reviews and validates EMT models for solar, wind, storage, hybrid, HVDC and FACTS projects, supporting developers, utilities and equipment vendors across US interconnection processes.

Why clients choose Keentel Engineering

• EMT depth: detailed PSCAD modeling from component code to full-plant studies.
• Control-aware engineering: we understand inverter and plant controller behavior, not just the network.
• Interconnection experience: model requirements of ERCOT, MISO, SPP, PJM, CAISO, NYISO and ISO-NE.
• Quality-first practice: structured parameter design, checks and automated testing.
• Licensed professional engineering: a Florida-registered firm with offices in Tampa, Austin, Sacramento and Baltimore, supporting projects nationwide.

Need a PSCAD model built, reviewed or validated for an interconnection study? Talk to Keentel Engineering at (813) 389-7871, contact@keentelengineering.com, or book a 15-minute scoping call at calendly.com/keentel-engineering/15min.

Part C — Case Studies

The following are illustrative scenarios based on conditions typical of US EMT modeling projects. They show how Keentel Engineering approaches custom component quality; site details are generalized and figures are rounded.

Case Study 1 — 200 MW solar plant at 230 kV: a frozen plant controller

Situation. A developer submits a PSCAD model of a 200 MW solar plant at a 230 kV POI. The transmission provider's review finds that the plant provides no voltage support during disturbances, contradicting the positive-sequence model and the vendor's documentation.

Analysis. Keentel reviews the plant controller component and finds that the voltage-control integral gain is computed from Integer parameters in an expression equivalent to Ki × (Nactive/Ntotal). With both quantities integers and Nactive smaller than Ntotal, the scaling evaluates to zero. The controller compiles and runs without error, but never acts.

Engineered solution. Keentel corrects the arithmetic to real division, converts gain-related fields to Real, adds Minimum and Maximum limits, and adds a Checks segment that warns if any computed gain is zero while voltage control is selected.

Outcome. The corrected model reproduces vendor test results and the positive-sequence model, and the transmission provider accepts the resubmission.

Case Study 2 — 150 MW battery plant at 138 kV: setpoint tests that could not be run

Situation. A battery storage plant connected at 138 kV must provide model validation results comparing simulated and measured responses to voltage and active power setpoint steps. The vendor's PSCAD model defines all setpoints as Literal values.

Analysis. Keentel finds that each setpoint step would require a separate model edit and run, and that sequenced tests (for example, a voltage step followed by a frequency event) are impossible. Hand-edited models create a risk that the validated model differs from the submitted one.

Engineered solution. Keentel works with the vendor to redefine operational setpoints as Variable parameters driven by a test sequencer component, retaining design constants as Literal. Choice fields select test scenarios, and an automation script runs the full validation test set.

Outcome. The full validation test suite runs automatically, results match field measurements within acceptance criteria, and the same harness is reused after a later firmware update.

Case Study 3 — 300 MW wind plant at 345 kV: mode documentation in a weak-grid study

Situation. An EMT study for a 300 MW wind plant at a 345 kV POI in a low-strength area shows marginal voltage recovery after faults. The transmission provider questions the results because the plant's interconnection agreement specifies voltage control at the POI.

Analysis. Keentel finds that the plant controller component's Choice field for control mode defaulted to Q control, and the study had been run in that mode. The study report did not state the mode.

Engineered solution. Keentel reruns the studies in voltage-control mode with the agreement's voltage schedule, changes the component's default to the agreement mode, displays the selected mode on the component graphic, and adds a configuration table to the study report.

Outcome. Voltage recovery meets criteria in the correct mode, and the transmission provider accepts the study.

Part D — Technical FAQ: PSCAD Custom Component Parameters

References and Further Reading

Links were current at publication (October 2026).



• Manitoba Hydro International, PSCAD User Guide and online help: Component Design, Parameters Section, Script Section (Segment Types, Directives, Substitutions). pscad.com.
• NERC Reliability Guideline, Electromagnetic Transient Modeling for BPS-Connected Inverter-Based Resources. North American Electric Reliability Corporation.
• NERC Reliability Standards MOD-032, MOD-026, MOD-027, PRC-024 and PRC-029. North American Electric Reliability Corporation.
• IEEE Std 2800-2022 and IEEE 2800.2, Interconnection and Interoperability of Inverter-Based Resources and associated test and verification procedures. IEEE.
• FERC Order No. 2023, Improvements to Generator Interconnection Procedures and Agreements. Federal Energy Regulatory Commission.
• H. W. Dommel, EMTP Theory Book. Bonneville Power Administration and Microtran Power System Analysis Corporation.
• ISO/International Fortran standard (ISO/IEC 1539) on intrinsic data types and arithmetic.
  

Disclaimer

This article is general technical information for educational purposes. It is not engineering advice for any specific project and does not create a professional relationship. PSCAD features described reflect publicly available documentation and may differ between versions; users should consult the documentation for their installed version. Keentel Engineering's illustrations use simplified reduced-order models with assumed parameters and are not PSCAD simulation results of any specific plant. Interconnection models must follow current NERC, IEEE, FERC and transmission provider requirements and project-specific engineering analysis, sealed by a licensed professional engineer where required.

Case studies are illustrative scenarios based on typical project conditions, not records of specific client projects. Figures are rounded and indicative.

PSCAD™ is a trademark of Manitoba Hydro International Ltd. IEEE, NERC, FERC and other names are the property of their respective owners. Keentel Engineering is not affiliated with or endorsed by these organizations or any software or equipment vendor.