Programming Concepts in NSC Systems

Event-Driven Programming

NSC systems use an event-driven execution model, where logic is triggered by events such as:

• Input signal changes (rising or falling edges, status change)
• Output transitions
• Timer expirations
• Button clicks or long presses
• Remote RPC calls from other devices (public events)

Unlike traditional PLCs that continuously cycle through a program, NSC firmware reacts only when something happens, resulting in faster and more efficient behavior in complex distributed setups.

A Different Paradigm

Unlike with a PLC you should not check for the status of a contact/input, even less if this is not local to the device!
Instead use events to detect when something changes and then operate the required actions accordingly. If you still need to test the status of an input you can use a Ladder expression.

If you have to test the status of a remote input, instead of checking it via remote polling use a flag (merker). Link the change of the input status event of the remote unit to a flag (or a virtual output) into the local unit, then check this local flag or virtual output in your Ladder expression. In other words you use a flag to mirror the state of a remote input or output, or any other event.

Cooperative Multitasking

The NSC OS is a cooperative multitasking system. This means that as long as an event is kept busy the device will be unresponsive. This can be easily avoided preventing loops inside events. Instead use the event system or use timers.

Some core events are fired anyway, like interrupt-driven events, the internal real time clock and timers.

Error Management

The interpreter included in the standard NSC devices can detect errors in the program. If an error is detected the error code and the position in the program that caused the error is registered, then the unit is stopped in protection mode. The device is still responsive and can be remotely tested, diagnosed and restarted or reprogrammed, guaranting a safe behavior.

Input/Output Mapping

Each NSC device typically provides up to 16 logic inputs and 16 logic outputs, along with analog inputs and one-wire support. Inputs and outputs can be directly linked to logic events and actions through MaticStudio’s visual panels.

When an input changes, it can directly trigger an output action, a function activation, or a call to another device — all without writing low-level code.

Logic Actions

Each event in the system can trigger one or more of the following actions:

• Set / Reset Output — turn a digital output on or off
• Toggle Output — switch the state of an output
• Activate Function — run a virtual component (e.g. counter or scheduler)
• Start / Stop Timer — execute delayed or repeating tasks
• Remote Call (RPC) — trigger an event or action on another device

Distributed Logic

With NSC, logic can be spread across devices as if it were running on a single controller. MaticStudio automatically generates and links the necessary Remote Procedure Calls (RPCs) to synchronize devices.

This allows inputs on one unit to directly influence outputs or functions on another — with no manual networking logic needed.

Virtual Components

NSC supports modular logic through Virtual Components — reusable logic blocks distributed as COB files. These components can implement:

• Internal logic (e.g. counters, timers, flip-flops)
• Custom user interface for SCADA panels
• Web-based visual elements and configuration

Virtual Components enhance logic clarity, promote reuse, and support complex scenarios without scripting.

Timers and Tasks

Each device supports multiple timers that can be triggered by events and optionally loop at specified intervals. Timers can be linked to any logic action or component.

The NSC operating system uses cooperative multitasking to execute tasks in a deterministic and efficient manner. This significantly reduces the risk of race conditions compared to preemptive systems. However, in distributed contexts — especially where remote procedure calls (public events) are involved — certain timing interactions may still lead to non-deterministic outcomes. Developers should design logic with awareness of event propagation delays and possible overlaps when using RPCs across devices, in particular when public events are chained.

Comparison with Traditional PLCs

Next Steps

• Features of MaticStudio
• Getting started with MaticStudio