Scripting

Intended audience: Advanced developers who want to create new features for their application.

All the features you would expect in a programming language are supported, as well as many more that are unique to VTScada.

From time to time, a new VTScada user (especially one coming from a programming background) will turn directly to script code or expressions to build features. The result is usually that they spend a large amount of time attempting to recreate features that already exist.
As the adage says, "don't reinvent the wheel".

A few notes about the VTScada language:

It is a language that makes it easier to write SCADA software. Every page, widget, tag, and tool that you've used in VTScada was written in that language. The following are a few key facts about this language:

It's an object-oriented, state-based, reactive, programming language.

That sounds like a lot of jargon, but it's not intended as a marketing pitch or to sound intimidating. Once you get the hang of it, the language is quite intuitive to read. It helps you get things done very easily that in other languages would require a lot more awkward setup and code structure.

Object-oriented

The processes that a SCADA system monitors are composed of a lot of physical things that often have similar properties and logic associated with them. For example, similar sensors or pumps. Tags are objects. An object-oriented language is a natural fit for working with physical objects.

State-driven

These objects often have continuous processes associated with them. In VTScada script, those processes match defined states. Therefore, in addition to properties and methods, our objects have a state.

These objects tend to have different behaviors under different conditions. Any object might have a set of states that it can inhabit. For example, a pump may be running or it may be stopped. When a pump is running, you need to worry about different things than when the pump is not running. Starting and stopping might be two more states. Or, a driver may be in the process of connecting to a piece of equipment, it might be fully connected, or it might be unable to connect. This is matched in code by the object inhabiting a different state for each physical circumstance.

In other languages, you may have had objects with a status variable indicating its state. Our states are not just a status variable. What is special about our states, is that each state has its own code and only one state can be active at a time within a module. It just makes things simpler to code.

Reactive

In VTScada script, it is very easy to write code that reacts to an object changing. That is what SCADA systems need to do. You could also call this event-driven, or "report by exception".

Objects in VTScada script seem more like living things compared to other languages. They almost always have a life of their own. They aren't just repositories of properties and methods. They usually are paying attention to the system around them and reacting to it.

Part of the reason for this is that we want to avoid polling. Polling is inefficient and slow. When something changes, we want to react to it as soon as possible rather than wait for a polling interval. That said, there is a lot of hardware that does not support report by exception, so a driver might need to poll that equipment. But from that point on, we can write code that reacts only to changes to that value and does so as soon as possible.

Is the VTScada scripting language weird?

That depends on your point of view. A line of code that begins "IF 1... " might seem unusual until you know how that function works in this language. But it still supports typical imperative, step-by-step code like you see in most other languages. For a lot of problems, most of the code is imperative, and it is also (reasonably) easy to write.