0% found this document useful (0 votes)
2 views6 pages

QuickScript NET Study Notes

The QuickScript .NET Study Notes provide a comprehensive overview of scripting syntax, execution types, and control structures used in the AVEVA Application Server. Key topics include variable declarations, quality behavior, redundancy considerations, and practical cautions for script writing. The document also includes an exam-focused cheat sheet to aid in quick revision and understanding of essential concepts.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views6 pages

QuickScript NET Study Notes

The QuickScript .NET Study Notes provide a comprehensive overview of scripting syntax, execution types, and control structures used in the AVEVA Application Server. Key topics include variable declarations, quality behavior, redundancy considerations, and practical cautions for script writing. The document also includes an exam-focused cheat sheet to aid in quick revision and understanding of essential concepts.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

QuickScript .

NET Study Notes


AVEVA Application Server | concise review notes from the uploaded lesson text and AVEVA manuals

What this covers: scripting syntax, execution types, triggers, variables, control structures, attribute
quality behavior, relative references, and redundancy-related script behavior.
Prepared for study and quick revision.

Contents
• 1. Big picture
• 2. Script syntax essentials
• 3. Script editor and authoring environment
• 4. Execution types and triggers
• 5. Variables and declarations
• 6. Control structures
• 7. Quality behavior and practical cautions
• 8. Redundancy notes for Startup / Execute / OffScan / Shutdown
• 9. Exam-focused cheat sheet
• 10. Source basis
1) Big picture
QuickScript .NET is the scripting language used in Application Server object scripts and related client
scripting contexts. It supports both simple expression-based logic and more complex procedural logic with
declarations, conditionals, loops, and error handling.
• Simple scripts: assignments, comparisons, math, concatenation, and straightforward calculations.
• Complex scripts: branching and procedural logic using structures such as IF, FOR, WHILE, and
TRY...CATCH.
• Best mindset: use it for object behavior, runtime logic, cleanup, initialization, and controlled reactions to
data or scan-state changes.

2) Script syntax essentials


The syntax is assignment-based and calculator-like. The value of the expression on the right is assigned to
the entity on the left.
React_temp = 150;
ResultTag = (Sample1 + Sample2) / 2;
' This is a single-line comment.
Number = 1;
Setpoint = "Setpoint" + Text(Number, "#");
' Result: Setpoint1
• A single entity must appear on the left side of '='.
• Operands can be constants or variables.
• Each statement ends with a semicolon ';'.
• Keywords and variable identifiers are not case-sensitive, although editor casing is preserved.
• Use spaces and indentation for readability, but do not split identifiers or numbers with spaces or line
breaks.
• Comments: single-line comments start with ' ; multi-line comments are enclosed in { }.
Useful syntax reminders
Rule What to remember
Assignment Left side must be one assignable entity.
Statement ending Every statement ends with ';'.
Concatenation Use '+' to combine text entities.
Comments Single-line: '. Multi-line: { ... }.
Readability Indent with spaces or tab; keep tokens intact.

3) Script editor and authoring environment


• Scripts are authored from the Object Editor Scripts tab.
• The lesson highlights six areas: Scripts, Inherited scripts, Aliases, Declarations, Basics, and Script Editor.
• The editor supports validation to check syntax before deployment.
• Autocomplete is enabled by default and helps with attribute references, methods, parameters, keywords,
and constructs such as try/catch and while/endwhile.
• Ctrl + Space displays available autocomplete options for the current position in the script.

4) Execution types and triggers


The Script Editor exposes five execution types. Their main difference is when they run and what data is
safely available at that moment.
Type When it runs Main use / caution
Startup When object loads into memory Use for creating COM/.NET
during deployment, platform start, objects. Off-object attributes may
or engine start. not be available; assignments
can fail under load.
OnScan First execution after scan state Good for initializing local object
changes to OnScan. values and object creation. Off-
engine attributes are not
available.
Execute Each scan while object is Primary runtime method; use for
OnScan. most operational logic because
attributes and values are
available.
OffScan When object is taken OffScan. Use for cleanup. Long-running
async logic should honor
shutdown indication.
Shutdown When object is about to be Use to destroy COM/.NET
removed from memory, usually objects and free memory.
because AppEngine is stopping.
Execute trigger behavior
• Periodic: runs when elapsed time evaluates true.
• Data Change: runs when value or quality changes between scans.
• OnTrue: runs when expression transitions false -> true between scans.
• OnFalse: runs when expression transitions true -> false between scans.
• WhileTrue / WhileFalse: evaluated each scan based on the expression state at the beginning of the scan.
• Trigger period 0 means execute every scan.
• Time-based execution uses the timestamp of the previous execution, not a continuously accumulating
elapsed-time counter.
• A system clock adjustment can change the real interval between executions even if the nominal trigger
period stays the same.
Practical meaning
• Prefer Execute for normal runtime logic.
• Keep Startup and OnScan lightweight, especially in large deployments or redundant systems.
• Treat OffScan and Shutdown as cleanup hooks, not places for heavy business logic.

5) Variables and declarations


Variables must be declared before use. Declarations may appear in the script body, but they must come
before first use. Variables declared in the Declarations area persist for the lifetime of the object.
DIM LocVar1;
DIM Total AS Float;
DIM Msg AS String;
DIM Values(100) AS Integer;
• Each variable needs its own separate DIM statement.
• If AS <data_type> is omitted, the default datatype is Integer.
• Supported built-in types include Boolean, Integer, ElapsedTime, Float, Double, String, Time, and
InternationalizedString.
• Variables can also use .NET types or types from imported script libraries.
• Array lower bound is always 1; up to three dimensions are supported.
• Variable names cannot contain dots.
• If a local variable conflicts with another named entity, the local variable takes precedence.
• Variables declared inside the script body lose their value after the script finishes.
• Variables in the Declarations area retain value across executions for that object.
Important cautions
• Do not cascade DIM statements; declare each variable separately.
• Using a variable on the right side of an expression treats its quality as Good for propagation purposes.
• You can assign null to indicate no current object reference, but using a null-valued variable causes script
termination; test for null before use.
• Attributes cannot be passed directly as parameters for some system objects; use a local variable as an
intermediary or convert explicitly to string if needed.
• Float constant overflow is validated when assigned beyond supported range.

6) Control structures
QuickScript .NET supports the main flow-control structures needed for procedural logic.
IF ... THEN ... ELSEIF ... ELSE ... ENDIF
• Use for conditional branching.
• Boolean expressions can be true/false directly, or derived from numeric values where 0 = False and non-
zero = True.
• String, Time, ElapsedTime, InternationalizedString, and BigString cannot be mapped into Boolean
expressions for IF conditions.
IF value == 0 THEN;
Message = "Value is zero";
ELSEIF value > 0 THEN;
Message = "Value is positive";
ELSEIF value < 0 THEN;
Message = "Value is negative";
ELSE;
Message = "Unexpected";
ENDIF;

FOR ... TO ... STEP ... NEXT


• Repeats a block a known number of times.
• Loop variable must be Integer, Float, or Double.
• STEP can increment or decrement.
• EXIT FOR allows an early break from the loop.
• If STEP is omitted, the loop uses default increment/decrement logic based on start and end.
FOR EACH ... IN ... NEXT
• Used only with collections exposed by OLE Automation servers.
• Requires an object variable and a collection object.
• EXIT FOR can also be used here for early exit.
TRY ... CATCH
• Wraps code that may throw runtime errors so the script can handle exceptions instead of terminating
outright.
• The reserved ERROR object is a .NET [Link] from the try block.
• Common pattern: log the error, then continue cleanup such as closing readers or connections.
WHILE ... ENDWHILE
• Repeats while the Boolean expression remains true.
• EXIT WHILE allows early exit.
• Nested loops are possible, subject to memory and resource limits.

7) Quality behavior and practical cautions


Attribute quality matters. A script can copy values, propagate quality, or skip logic depending on bad-quality
inputs.
• Assigning one attribute to another of the same type copies both value and quality.
• Using .value also copies the value while keeping the quality logic tied to the source attribute context.
• If you want only the value and not bad quality propagation, first copy to a temporary local variable, then
write the local variable to the destination attribute.
• Comparisons against BAD-quality attributes may not behave as expected; statements inside IF blocks may
not execute.
• Safer pattern: check quality first using IsBad(attribute) before comparing or copying.
IF IsBad(me.Attribute1) THEN;
LogMessage("Attribute1 quality is bad; value not copied.");
ELSE;
IF me.Attribute1 <> me.Attribute2 THEN;
me.Attribute2 = me.Attribute1;
ENDIF;
ENDIF;

Relative references
• Relative references such as Me and container-relative paths are valid and especially useful in templates.
• They make scripts reusable because template logic does not depend on a hard-coded absolute object
path.
• Example idea: <[Link]> lets the same template logic resolve correctly within each
instance.

8) Redundancy notes for Startup / Execute / OffScan / Shutdown


The 2023 scripting reference adds important behavior for redundant AppEngines. These notes are
especially useful for exam questions and design decisions.
• Deployment scripts matter: heavy Startup or OnScan logic can slow deployment and even hurt failover
performance.
• The selected redundancy mode does not change Execute or OffScan behavior.
• Startup and Shutdown behavior can differ between Legacy mode and Run Warm mode.
• In Run Warm mode, the standby engine starts earlier and Startup/Shutdown implications differ from
Legacy mode.
Execute scripts in redundancy
• Active engine is triggered on Execute; standby engine is not triggered on Execute.
• After failover, Execute runs on the new active engine at the next scheduled scan period.
• Execute does not run during undeploy.
• Graceful shutdown of the active engine does not cause Execute to run during the shutdown transition.
OffScan scripts in redundancy
• When failover occurs, OffScan scripts are triggered when the active engine goes OffScan.
• OffScan scripts are not triggered when the standby engine goes OffScan.
• They do not run on hard shutdown events.
• They do run during undeploy when the active engine goes OffScan before shutdown.
Shutdown scripts in redundancy
• Shutdown is mainly for destroying COM/.NET objects and freeing memory.
• In Legacy mode, standby is not started until failover; therefore some standby-side shutdown cases do not
execute.
• In Run Warm mode, both engines may already be started, so graceful shutdown of server 2 can execute
Shutdown scripts.
• Hard shutdown scenarios do not execute Shutdown scripts.
Best-practice takeaway
• Keep Startup and OnScan lean.
• Put primary runtime logic in Execute.
• Write OffScan and Shutdown as safe cleanup handlers.
• When redundancy matters, test behavior against the chosen mode: Legacy vs Run Warm.

9) Exam-focused cheat sheet


Question idea Fast answer
Where should most runtime logic go? Execute.
Can Startup use off-object attributes? No; off-object attributes are not available.
Can OnScan use off-engine attributes? No; off-engine attributes are not available.
What ends every statement? A semicolon ';'.
Are keywords case-sensitive? No.
Default datatype if AS is omitted? Integer.
How do you comment one line? Start with '.
How do you handle runtime errors? TRY ... CATCH.
What to do before comparing/copying a possibly Check quality first, e.g., IsBad().
bad-quality attribute?
Best reference style in templates? Relative references such as Me / container-relative
paths.

10) Source basis


These notes were distilled from the uploaded QuickScript .NET lesson text plus AVEVA Application Server
manual content available in the conversation.
• Uploaded lesson text: Scripting Environment, Syntax, and Execution Types; Variable and Control
Statement Usage.
• AVEVA Application Server 2023 manual / scripting reference: redundancy behavior for Execute, OffScan,
and Shutdown scripts.
• Older Application Server manual snippets were used only to cross-check consistency of the core scripting
behavior.
Study tip: memorize the role of each execution type first, then practice short examples for DIM, IF, FOR, TRY...CATCH, and
quality-safe copying.

You might also like