Introduction

This note described the various ways to implement communication between imperix controllers.


Related notes and applications

A multi-converters system for a micro-grid is presented in AN008: Multi-converters system.

Types of multi-converters control implementation

Different approaches are possible for implementing multi-converter systems on B-Box RCP / B-Board PRO. They are summarized below.

Multi-controller mode (independent)

This is the conventional approach, in which each converter operates independently. They may nevertheless exchange data (such as setpoints, measurements or status information) at a relatively low rate. The typical application is a back-to-back conversion system, which uses one controller for each converter.

Obviously, in multi-controller mode, each controller must execute its own control algorithms. This implies that one control software (C/C++ project, Simulink or PLECS file) must be flashed onto each controller. That said, each controller may be constituted by several - stacked - units, operating in I/O extension mode (master-slave).

Overall, the multi-controller mode takes place between independent controllers, or between independent sets of controllers.

Issue / Need

Solution

Comment

Inter-units communication

CAN or ETH

Max few kHz exchange rate

PWM synchronization

N/A


Operating CPU

1 in each master unit

Slave units can be used in addition to each master (in I/O extension mode)

Control software file

1 for each master CPU

Valid for C/C++, Simulink or PLECS

I/O extension mode (aka master-slave mode)

This mode intervenes by default when several B-Boxes or B-Board are connected together using SFP (optical fibers). It offers configuration-free operation for stacked units, with native synchronization and communication. All I/Os and peripherals that belong to slave units can be easily addressed from the master CPU using a device ID only. The master-slave(s) communication latency is optimized to be extremely low.

As such, in I/O extension mode, only one CPU is operating (inside the master). Therefore, only one control software (C/C++ project, Simulink or PLECS file) must - and can - be used.

Issue / Need

Solution

Comment

Inter-units communication

SFP (imperix RealSync)

Sub-μs latency for up to few units

PWM synchronization

SFP native (imperix RealSync)

Accurate ±6.5ns at units outputs

Operating CPU

1 for the overall control stack

Other units are slaves

Control software file

1 for the overall control stack

Valid for C/C++, Simulink or PLECS

Networked control mode - synchronization only

This mode is planned for release in software version v3.7 (end 2020).

This mode supports all the features mentioned in the independent controllers mode, with the addition of the PWM synchronization across the converters.

This configuration offers the best of the two configurations described above, namely:

  • Distributing the control algorithm on multiple CPU for better computing power

  • Synchronizing PWM across all units

SFP links are used to connect all the units in a single network to benefit from the native imperix RealSync synchronization. However, there is no data exchange between the CPUs once the system is started. The SFP links are only used to synchronize the time-base of the PWMS (CLOCK resources).

In this mode, the user must perform an additional configuration to select which master sends a synchronization signal to which CLK (from C++ or ACG model).

Issue / Need

Solution

Comment

Inter-units communication

CAN or ETH

Max few kHz exchange rate

PWM synchronization

SFP native (imperix RealSync)

Accurate ±6.5ns at units outputs

Operating CPU

1 in each master unit

Slave units can be used in addition to each master (in I/O extension mode)

Control software file

1 for each master CPU

Valid for C/C++, Simulink or PLECS

Networked control mode - fully-distributed control

This mode is planned for release in software version v3.8 (early 2021).

In the fully-distributed control mode, inter-units communication occurs through the SFP links which bring the following advantages over the traditional CAN or Ethernet communication:

  • determinist sub-μs transfer delays for up to a few units

  • up to hundreds of kHz exchange rate

  • data transfers synchronized with the interrupts

Issue / Need

Solution

Comment

Inter-units communication

SFP (imperix RealSync)

Sub-μs latency for up to few units

PWM synchronization

SFP native (imperix RealSync)

Accurate ±6.5ns at units outputs

Operating CPU

1 in each master unit

A master unit can access the I/Os of the units bellow

Control software file

1 for each master CPU

Valid for C/C++, Simulink or PLECS

  • No labels