Two cores in the inverter: your software on one, our motor control on the other

Published October 2, 2026 · Persystems GmbH, Regensburg, Germany

Why application logic belongs on the inverter

Many products need their own logic close to the drive: a control loop that goes beyond pure motor control, a sequence that turns sensor readings into setpoints, or the behavior that makes this particular product what it is. Usually that logic gets a controller of its own – another board, more wiring, a second firmware project and a bus in between that every setpoint has to cross.

With our inverters it is simpler. The controller has two processor cores, and only one of them is reserved for motor control. The second is yours: your software runs there, right next to the control, on the same board and without a detour over a bus. The concept covers the whole inverter family, from the 48 V inverter INV-60V-120A and the GaN inverter INV-120V-40A to the INV-25V-100A currently in development. From 2027 it is included in all our inverters.

Two cores, a clear division of labor

Core 1: motor control. This is where the Persystems firmware runs, just as on every one of our inverters: the field-oriented control, plus telemetry, fault log and the protection functions. The external interfaces – on the INV-60V-120A, for example, PersyCAN, DroneCAN and PWM/PPM – and the configuration tool remain unchanged as well.

Core 2: your application. The second core is freely programmable. What runs there is up to you: your control loop, your sequence logic, your sensor processing or the behavior that defines your device.

In between: the inter-processor interface. This is how your code commands the motor control: it sets setpoints and commands and reads back states and measured values – the same quantities the inverter otherwise receives and reports over CAN. Reference examples show how it is done, so you do not start from scratch.

The motor control always runs

Splitting the work across two cores is more than a convenience. It keeps the motor control independent of your software: your code can neither slow it down nor throw it off its timing, because it runs on a core of its own. Current control and the protection functions – from overcurrent and short-circuit protection to the safe state of the drive – live on the control core and remain the responsibility of Persystems.

That holds during development, too: while you write, test and change your application, the control remains the same proven firmware that we measure on our test bench in Regensburg. You build your product on a motor control that works – from the first prototype on.

What you can build on the second core

The second core suits everything that needs its own logic close to the drive. A few examples:

• Process control on top of the motor control – pressure, flow or pulling force, for instance, controlled right at the drive
• Motion profiles and sequence control, for example for joints and axes in robotics
• Processing of your own sensors and setpoints derived from them, without a detour through a supervisory system
• Product behavior that defines your device – operating modes, limits, reactions to events

Which interfaces and resources your code uses for this is something we agree on together at the start of the project.

How you get there

The dual-core variant is a firmware variant of our inverters. You receive the inverter with the inter-processor interface, reference examples to get started and, on request, the support of our engineering team – from agreeing on the interface and the integration to measuring your drive on our test bench. Hardware adaptations, such as connectors or form factor, are possible as with all variants.

And because the concept is designed for all our inverters, the same architecture is available to you when your drive moves to another voltage or power class.

The concept at a glance

Feature	Implementation
Applies to	all Persystems inverters, included in every inverter from 2027
Controller	two processor cores on the control board of the inverter
Core 1	field-oriented control, telemetry, fault log, protection functions – Persystems firmware
Core 2	freely programmable for your application
Coupling	inter-processor interface: setpoints and commands in, states and measured values back
Reference examples	example code for the interface as a starting point for your application
Protection functions	all protection functions of the inverter and the safe state – on the control core
External interfaces	as on the respective inverter, on the INV-60V-120A for example CAN (PersyCAN, DroneCAN) and PWM/PPM – unchanged
Tools	parameterization, firmware updates and fault diagnosis with the PC software over CAN
Delivery	firmware variant “dual-core customer code”, integration support on request

Where the limits are

The second core does not replace engineering. Computing time, memory and interfaces are finite, and not every application fits. That is why we talk about your requirements before the project – and tell you openly if a controller of your own is the better solution for your product.