• Non ci sono risultati.

Simulazione e Test HiL del Controllo di Azionamenti Elettrici in ambienti Matlab e PLECS = Simulation and HiL Testing of Electrical Drives Control in Matlab and PLECS

N/A
N/A
Protected

Academic year: 2023

Condividi "Simulazione e Test HiL del Controllo di Azionamenti Elettrici in ambienti Matlab e PLECS = Simulation and HiL Testing of Electrical Drives Control in Matlab and PLECS"

Copied!
102
0
0

Testo completo

(1)

Corso di Laurea in Ingegneria Elettrica

Tesi di Laurea Magistrale

Simulazione e test HiL del controllo di azionamenti elettrici in ambienti

MATLAB e PLECS

Relatore

Prof. Gianmario Pellegrino

Candidato

Emanuele Giamello

(2)
(3)

Questa tesi di laurea ha come obiettivo principale quello di confrontare e valutare l’efficienza e la precisione di due programmi di modellistica e simulazione: Simu- link (MathWorks) e PLECS (Plexim) utilizzati per la simulazione del controllo di

azionamenti elettrici.

Il lavoro di tesi è suddiviso in due parti: la prima parte si concentra su un confronto tra i due ambienti citati e tra i diversi componenti disponibili. A partire da dei modelli Simulink forniti durante il corso "Controllo digitale di convertitori e azionamenti"

vengono sviluppati dei modelli con diverse caratteristiche di convertitore su entrambi i software con un confronto finale in termini di risultati e tempi di calcolo con l’obiettivo di determinare i vantaggi e gli svantaggi di un determinato modello o ambiente anche in un’ottica didattica.

Nella seconda parte viene introdotto un modello Hardware-in-the-loop sviluppato a partire dai dati raccolti da un motore sincrono a magneti permanenti ad oggi utilizzato per le esercitazioni del corso già citato. In particolare viene presentato il simulatore real time "RT Box" di proprietà Plexim, progettato quindi per lavo- rare con il software PLECS. Sul simulatore viene caricato un modello contenente le componenti di potenza (inverter e motore) mentre il codice C di controllo è implementato su un microcontrollore STM connesso alla RT Box.

(4)
(5)

Ed eccomi giunto ai ringraziamenti, l’ultima pagina di un percorso che per me è iniziato quattordici anni fa quando la maestra in quinta elementare mi chiese: "cosa vuoi fare da grande?". La mia risposta fu, ovviamente: "l’ingegnere".

Iniziando dai ringraziamenti ufficiali ringrazio il mio relatore, il professor Pelle- grino, per il tempo dedicatomi durante lo svolgimento di questo progetto.

Un ringraziamento speciale va poi alla mia famiglia, ed in particolare ai miei genitori che mi hanno sempre sostenuto ed incoraggiato; se oggi sono qui è in gran parte merito loro.

Ringrazio gli amici, quelli di sempre, i pochi rimasti dal liceo e che ancora oggi sono qui al mio fianco ma anche i nuovi amici e le persone che sono entrate da poco nella mia vita ma l’hanno resa subito speciale.

Ringrazio quegli amici che con me hanno condiviso le gioie e i dolori del Politecnico, con i quali e grazie ai quali ho imparato tanto...persino un po’ di pugliese.

Le ultime righe di questi ringraziamenti vanno ad una persona per me speciale, una persona che dal mio primo giorno di università mi ha chiamato con orgoglio

"ingegnere" e che più di tutti vorrebbe essere al mio fianco oggi. Le ultime righe di questi ringraziamenti vanno a mio nonno Mario a cui dedico questa tesi.

(6)
(7)

Elenco delle tabelle ix

Elenco delle figure x

1 Introduzione 1

1.1 PLECS . . . 2

2 Modelli e simulazioni 5 2.1 Modelli Benchmark . . . 6

2.1.1 Modello benchmark SPM . . . 6

Inverter . . . 8

Controllo digitale . . . 9

Risultati Simulazione . . . 14

2.1.2 Modello Benchmark IM . . . 15

Risultati simulazione benchmark . . . 17

2.2 Modelli circuitali . . . 18

2.2.1 Modello fisico SPM . . . 18

Perdite Meccaniche . . . 21

2.2.2 Modello fisico IM . . . 23

2.2.3 Modello Average Inverter . . . 27

2.2.4 Modello Logico Inverter . . . 30

2.2.5 Modello Fisico Inverter . . . 33

2.3 Confronto risultati simulazione . . . 35

2.3.1 Tempi di calcolo . . . 48

3 Hardware-in-the-loop 53 3.1 Cos’è l’Hardware-in-the-loop? . . . 54

3.1.1 Simulatore Real-Time: RT Box . . . 56

3.2 Configurazione Hardware . . . 57

Microcontrollore . . . 57

Inverter . . . 59

Microphase S140-2B353 . . . 60

(8)

3.4 Implementazione passo passo modello RT Box . . . 63

DAC . . . 65

ADC e PWM Capture . . . 67

Open Loop . . . 71

3.5 Modello HiL Motore Microphase . . . 74

3.5.1 Parametri motore . . . 75

Identificazione KE . . . 76

Identificazione inerzia e componenti d’attrito . . . 78

3.5.2 Risultati . . . 83

4 Conclusioni 87

(9)

2.1 Parametri modello IM . . . 24

3.1 Principali parametri Motore Microphase S140-2B353 . . . 60

3.2 Parametri e riferimenti controllo motore . . . 62

3.3 Parametri meccanici stimati . . . 80

(10)

2.1 Modello Benchmark Motore SPM . . . 6

2.2 Controllo in anello chiuso di velocità . . . 7

2.3 Impostazioni inverter e dead-time . . . 9

2.4 Digital Control . . . 10

2.5 Parametri Script . . . 11

2.6 Code Declaration . . . 12

2.7 Start Function Code . . . 12

2.8 Update Function . . . 13

2.9 Code Declaration . . . 13

2.10 Modello Benchmark SPM . . . 14

2.11 Modello benchmark IM . . . 15

2.12 Controllo scalare V/Hz . . . 16

2.13 Modello Benchmark IM . . . 17

2.14 Modello motore SPM . . . 19

2.15 Impostazioni SPM . . . 20

2.16 Schema encoder assoluto . . . 21

2.17 Modello motore asincrono . . . 23

2.18 Curve ψm - im . . . 25

2.19 Impostazioni IM . . . 26

2.20 Inverter Average Simulink . . . 27

2.21 Confronto tra segnale originale e campionato. Figura tratta da [1] . 28 2.22 Inverter Average PLECS . . . 29

2.23 Inverter ideale . . . 30

2.24 Impostazioni inverter ideale . . . 31

2.25 Impostazioni symmetrical PWM . . . 32

2.26 Generazione comandi di gamba . . . 32

2.27 Modelli inverter fisico . . . 33

2.28 Impostazioni inverter . . . 34

2.29 On Delay Simulink . . . 35

2.30 Impostazioni solver variable step . . . 36

2.31 Velocità e coppia modelli SPM . . . 37

2.32 Duty Cylce modelli SPM . . . 38

(11)

2.34 Tensioni assi dq modelli SPM . . . 40

2.35 Flussi modelli SPM . . . 41

2.36 Velocità e coppia modelli IM . . . 42

2.37 Duty Cylce modelli IM . . . 43

2.38 Correnti modelli IM . . . 44

2.39 Tensioni trifase modulate modelli IM . . . 45

2.40 Flussi modelli IM . . . 46

2.41 Tempi di calcolo SPM . . . 49

2.42 Tempi di calcolo IM . . . 50

3.1 Sistema Hardware-in-the-loop di un azionamento elettrico . . . 53

3.2 Hardware-in-the-loop. RT Box e scheda Nucleo . . . 54

3.3 RT Box Hardware. Immagini tratte da [16] . . . 56

3.4 Schema configurazione hardware . . . 57

3.5 Scheda Nucleo STM32. Immagine tratta da [18] . . . 58

3.6 Software . . . 58

3.7 Scheda X-NUCLEO-IHM08M1. Immagine tratta da [20] . . . 59

3.8 Microphase S140 e S160 . . . 60

3.9 Controllo vettoriale I-Hz . . . 62

3.10 Schema HiL - RT Box . . . 63

3.11 Coder Options . . . 64

3.12 Schema DAC . . . 65

3.13 Impostazioni Analog Out . . . 66

3.14 Forma d’onda tensione . . . 66

3.15 Schema PLECS ADC e PWM Capture . . . 68

3.16 Configurazione connessioni . . . 68

3.17 Impostazioni Analog Input . . . 69

3.18 Correnti abc . . . 69

3.19 PWM Capture . . . 70

3.20 Modello RT Box Motore Asincrono . . . 71

3.21 Impostazioni Incremental Encoder . . . 72

3.22 Connessione Nucleo e RT Box. Controllo V/Hz . . . 73

3.23 Correnti iabcs . . . 73

3.24 Pulsazione ed angolo meccanici . . . 73

3.25 Modello per RTB Microphase S140-2B353 . . . 74

3.26 Schema connessione HiL . . . 75

3.27 Configurazione Motore BLDC HiL . . . 76

3.28 Duty Cycle a regime, 400 rpm . . . 77

3.29 Gradino di corrente, S140-2B353 . . . 78

3.30 Subsystem perdite meccaniche . . . 80

3.31 Test inerzia, onda quadra di corrente . . . 81

3.32 Rampa di velocità da 0 a 100 rpm . . . 84

(12)

3.34 Correnti a regime 400 rpm . . . 86

(13)

Introduzione

L’idea alla base di questa tesi è quella di confrontare e verificare l’efficacia, intensa in termini di qualità e di velocità, di due ambienti di modellistica e simulazione nell’ambito del controllo degli azionamenti elettrici. I due software sono Simulink di proprietà Mathworks, probabilmente più noto nell’ambiente ingegneristico e pensato per modellare e simulare una vasta gamma di sistemi non necessariamente elettromeccanici e PLECS di proprietà Plexim progettato con una particolare attenzione per il mondo degli azionamenti elettrici.

L’obiettivo di questa tesi è principalmente didattico, il confronto dei due ambienti di simulazione e la successiva integrazione di un sistema Hardware-in-the-loop sono effettuati a partire da modelli di azionamenti e sistemi di controllo utilizzati durante il corso "Controllo digitale di convertitori e azionamenti" tenuto dal Professor.

Pellegrino per il corso di laurea magistrale in Ingegneria Elettrica del Politecnico di Torino; sono presentati dei modelli alternativi a quelli ad oggi utilizzati con lo scopo di valutare i pro e i contro di un ambiente o di un determinato tipo di modello; questa tesi non è però esclusivamente rivolta al mondo didattico, l’utilizzo di questi software è sicuramente radicato nel mondo universitario ma ritengo che anche nel mondo industriale la possibilità di modellare e simulare in modo accurato la realtà stia diventando sempre più importante, in particolare per esempio grazie ai sistemi Hardware-in-the-loop, anche e soprattutto quando l’obiettivo principale può diventare la velocità o il contenimento dei costi di realizzazione di un progetto.

Ritengo quindi che capire ed analizzare quali siano le potenzialità o i vantaggi di questi software ma anche la loro accessibilità e facilità di utilizzo sia un obiettivo utile e attuale anche in quel mondo industriale che negli ultimi anni si è definito

"Industry 4.0".

La prima parte dell’elaborato è quindi dedicata al confronto dei due ambienti e delle componenti fornite dalle rispettive librerie utili alla realizzazione di un modello di azionamento elettrico. In particolare viene analizzato il comportamento di diversi modelli di convertitore, a partire da un inverter ai valori medi fino ad introdurre un modello realizzato con interruttori "reali".

(14)

Nella seconda parte della tesi viene invece presentato un modello Hardware- in-the-loop. Anche in questo caso il punto di partenza è didattico: viene infatti realizzato e simulato in real-time il modello di un azionamento di un motore sincrono a magneti permanenti attualmente utilizzato dagli studenti per realizzare e testare gli algoritmi di controllo introdotti durante il corso del Prof. Pellegrino. La simulazione è realizzata grazie al real-time computer RT Box prodotto dalla Plexim ed ovviamente compatibile con il loro ambiente di modellistica PLECS e, grazie ad una serie di Input/Output analogici e digitali, con un qualunque microcontrollore (MCU), in questo caso il codice di controllo è implementato sulla scheda Nucleo

STM32.

1.1 PLECS

Prima di procedere viene presentato brevemente l’ambiente PLECS. Citando lette- ralmente il sito del produttore, il software viene descritto come: "the tool of choice for high-speed simulations of power electronic systems" [16].

L’idea alla base di PLECS è infatti quella di creare un programma di modelli- stica e simulazione specificatamente progettato per il mondo elettrico/elettronico, riconducendo il processo di modellistica il più possibile ad uno schema circuitale.

La libreria inclusa nel software consente di modellare tutti gli aspetti dei sistemi di power elettronics e del loro controllo. Troviamo infatti componenti essenziali per il mondo elettrico ma anche magnetico, termico e meccanico; il tutto presentato tramite una finestra drag and drop ed un editor schematico.

La libreria più fornita è ovviamente quella elettrica: PLECS offre una vasta gamma di componenti a partire da quelli passivi fino ad una serie di circuiti di potenza basati su componenti ideali ma anche in grado di includere specifiche di produzione di componenti reali in modo da simulare correttamente i fenomeni parassitici e termici. É inoltre presente una collezione di modelli di macchine elettriche con vari gradi di dettaglio e tutti interamente modificabili. Sono presenti anche componenti non lineari ed una serie di modelli di trasformatori pronti all’uso.

Anche per quanto riguarda la modellistica termica e magnetica viene riproposto lo schema circuitale tramite l’utilizzo di circuiti equivalenti. Viene infine fornito un insieme di componenti meccaniche progettato per esempio per interagire facilmente con i modelli delle macchine elettriche in modo da modellare e simulare un sistema di controllo completo. Inoltre, grazie all’utilizzo di blocchi appositamente progettati per il controllo dei convertitori di potenza e soprattutto grazie al blocco C-Script che consente di implementare direttamente in PLECS degli algoritmi di controllo in ANSI-C è facilmente possibile realizzare qualunque schema di controllo digitale.

Esistono due versioni del software: "PLECS Blockset" e "PLECS Standalone".

Entrambe presentano la stessa libreria con componenti compatibili tra loro. La versione "Blockset" è integrabile con Simulink/MATLAB e consente di usare i modelli e i componenti di PLECS con il solver, i blocchi di controllo e lo Script

(15)

Editor di Simulink. Al contrario la versione "Standalone" si presenta come un piattaforma di simulazione indipendente con un solver proprietario e ottimizzato.

Durante lo svolgimento di questa tesi è stata utilizzata la versione "Standalone".

La Plexim produce anche un simulatore real-time chiamato "RT Box" che può essere programmato e utilizzato direttamente da PLECS tramite l’utilizzo di un apposita libreria facilmente integrabile con le componenti e i modelli già citati [16].

Le caratteristiche e le specifiche del simulatore sono approfondite nella seconda parte di questo elaborato.

(16)
(17)

Modelli e simulazioni

La prima parte di questa tesi è, come già detto, dedicata alla presentazione di diversi modelli di due controlli di azionamenti elettrici. In particolare, nelle prossime pagine sono analizzati e confrontati dei modelli di controllo di un motore sincrono a magneti permanenti e di un asincrono realizzate su Simulink e PLECS. Lo scopo è quello di valutare la convenienza di un determinato modello o software rispetto al modello benchmark già citato nell’introduzione e presentato poco più avanti.

Verranno confrontati l’accuratezza della simulazione e la sua precisione ma anche la velocità di calcolo.

In particolare vengono presentati tre modelli diversi dal punto di vista dell’inverter:

il primo modello è definito "Average", il secondo "Logico" ed infine un modello

"Fisico". I modelli Average e Logico non includono il deadtime o le cadute di tensione delle componenti elettroniche di potenza che sono quindi eliminati anche dal modello benchmark durante il confronto; bisogna inoltre disattivare la compensazione delle cadute di deadtime all’interno del codice di controllo. Sia le impostazioni all’interno del blocco inverter sia la compensazione del deadtime tramite codice sono ripristinate per il confronto con i modelli Fisici.

Durante il corso "Controllo digitale di convertitori e azionamenti" per la simula- zione dei modelli benchmark è stato utilizzato un solver di tipo Fixed-step, quando possibile in questo elaborato viene introdotto anche un solver Variable-step. Un solver di tipo fixed utilizza per tutto l’intervallo simulato lo stesso valore temporale per gli step di simulazione, un solver variable al contrario è in grado di adattare l’ampiezza del passo in funzione della rapidità degli eventi simulati, se non avvengono cambiamenti rapidi lo step size viene incrementato mentre viene ridotto qualora sia necessario simulare eventi che si sviluppano su tempi minori del passo di simulazione;

ovviamente questo implica la necessità di una maggiore potenza di calcolo ma può anche portare ad un minor numero di step complessivi. Diventa quindi interessante confrontare l’impatto del solver in termini di tempi di calcolo.

(18)

2.1 Modelli Benchmark

In questa sezione sono presentati i componenti e i risultati di simulazione dei modelli benchmark sulla base di cui vengono poi sviluppati i tre "nuovi" modelli. Come già detto i motori modellati sono due: uno sincrono a magneti permanenti (SPM) e uno asincrono (IM).

2.1.1 Modello benchmark SPM

vs* dq 1-u(1)

toggle

speed control

is alpha,beta duty

Vdc dc-link

current control va

vb

vc

Tload iabc Tem Fdq Fab omegar thetar Motor ModelSPM

RCV_6_4 PWM Interrupt

Observed Flux

Load dutyABC vdc

iABC

enable vAn

vBn

vCn Inverter Average Model

[Te]

[dutyABC]

[speed_control]

[Fab]

[iabcs]

[Fdq]

[iq_ctrl]

[Fr_obs]

[Fr_est]

[id_ctrl]

[is_ab]

[vs_ref]

[vdc]

[id_ctrl]

[vdc]

[speed_control]

[iabcs]

[is_ab]

[vs_ref]

[dutyABC]

[iq_ctrl]

[iabcs]

[Fdq]

[Fr_obs]

[Fr_est]

[vdc]

[dutyABC]

[iabcs]

Estimated Flux iabcs

vdc

posCount

n *

Commands

duty_abc pwm_stop n*,n vs* dq is alpha,beta id ctrl iq ctrl rotor flux obs rotor flux est th0_comm Digital Control

Currents 1500

ref [rad]

-K- [n]

rad2rpm [rad]

[rad]

posCount

out Absolute Encoder

enc1

Flux [Fdq]

[Fab]

[Fdq]

[n]

[Te]

thetar Res

Go Tref

phase currents

torque

dq motor flux alpha beta motor flux

Reset

Go

Go Go

Figura 2.1: Modello Benchmark Motore SPM

Il modello benchmark del motore SPM si basa sui valori riportati nel codice 2.1 che viene richiamato ad inizio simulazione. I valori elettrici e meccanici sono ottenuti a partire dalle misure effettuate sul motore RCV 6_4 [13].

Per il motore SPM è stato implementato un controllo in anello chiuso di velocità riassunto nello schema a blocchi di Figura 2.2 [3, p. 449].

(19)

Figura 2.2: Controllo in anello chiuso di velocità

% PWM and sampling time

Tsw = 100e−6; % control task [s] = PWM task

% dc link voltage Vdc = 310;

% mechanical quantities encOffset = 1.0472;% rad th0 = (pi/4)−pi;

J = 1.0e−3; % (not measured)

% motor data

Rs = 1.5; %

p = 2;

Rfe = inf;

Fm = 0.261; % PM flux (Vs)

Leq = 0.0046;% average inductance (H) Ld = Leq;

Lq = Leq + 2 ∗ dLeq;

%Lookup table magnetic model fd = linspace(0,Fm+Leq∗20,40);

fq = linspace(−Lq∗20,Lq∗20,20);

ID_dato_fd_fq = (fd−Fm)/Ldpos;

ID_dato_fd_fq(fd<Fm) = (fd(fd<Fm)−Fm)/Ldneg;

IQ_dato_fd_fq = (fq)/Lq;

% Mechanical losses torque = Tmec_a0 + Tmec_a2 ∗ w^2 P0 = 10; % ventilation loss at nmax (W)

nmax = 6000; % maximum operating speed (rpm) Bm = 0; % damping constant (Nm/(rad/sec)) Tc = 0.1; % friction loss (Nm)

Kv = P0/(nmax∗pi/30)^3;% ventilation loss coefficient (W/(rad/s)^3 = Nm/(rad/s)^2)

Codice 2.1: Inizializzazione Motore SPM. File: "init_SPM.m"

(20)

Inverter

L’inverter è lo stesso in entrambi i modelli benchmark ed è basato su un modello ai valori medi scritto in linguaggio C che riceve in ingresso la tensione al DC Link, i duty cycle direttamente dal controllo e le correnti iabc del motore. Come evidente in Figura 2.3a è possibile selezionare, per entrambi i componenti elettronici, un modello a due o cinque parametri. Il modello a 5 parametri inserisce una soglia di corrente (Iknee) al di sopra della quale cambiano i valori di Ron e Vf; il modello a 2 parametri invece utilizza solamente un valore di Ron e Vf (vedi il codice 2.2 per i valori numerici) per tutto il range di correnti ammesso. Siccome né in Simulink né in PLECS viene fornito un inverter circuitale con il comportamento a 5 parametri il modello didattico viene utilizzato con il modello a 2 parametri. Come già detto per il confronto con i modelli AVG e Fisico bisogna disattivare il dead-time e le cadute di tensione, per fare ciò è sufficiente aprire la maschera del blocco inverter e togliere la spunta vicina ai due parametri appena citati. Bisogna inoltre disattivare la compensazione degli effetti del deadtime all’interno del codice di controllo; è sufficiente impostare a zero il valore di "amp_dt" nella maschera del blocco Digital Control (Figura 2.3b), in modo tale che la compensazione del duty cycle sia nulla (vedi codice 2.3).

% Converter

V0 = 1; % power semiconductors ON treshold [V]

Rd = 0.1e−3; % power semiconductors resistance [Ohm]

dT = 1e−6; % dead time [s]

Codice 2.2: Parametri Inverter

void DTComp(Xabc ∗isabc,Xabc ∗duty_abc, float amp_dt) { if ((∗isabc).a>0) (∗duty_abc).a+=amp_dt;

else (∗duty_abc).a+=−amp_dt;

if ((∗isabc).b>0) (∗duty_abc).b+=amp_dt;

else (∗duty_abc).b+=−amp_dt;

if ((∗isabc).c>0) (∗duty_abc).c+=amp_dt;

else (∗duty_abc).c+=−amp_dt;

}

Codice 2.3: Compensazione Deadtime

(21)

(a) Impostazioni inverter Benchmark (b) Compensazione dead-time

Figura 2.3: Impostazioni inverter e dead-time

Controllo digitale

L’ultimo componente da presentare è denominato nel modello benchmark "Digital Control, il suo scopo è quello di simulare il comportamento di un microcontrollore e contiene quindi l’algoritmo di controllo scritto in linguaggio C. Questo è l’unico blocco che rimarrà sempre invariato, cambiando ovviamente il codice di controllo in base al tipo di motore, per ogni modello analizzato. Siccome a partire dal benchmark sono realizzati altri modelli, sia in Simulink che in PLECS, in questa sottosezione vengono presentati il blocco di controllo del modello benchmark (e di tutti gli altri modelli Simulink) e la sua componente duale realizzata in PLECS. Le impostazioni qui riportate sono riferite al motore SPM ma sono speculari nel caso dell’asincrono.

I blocchi “Reset”, “Go” e “PWM Interrupt” di PLECS sono esattamente speculare ai loro corrispettivi Simulink e non richiedono approfondimento data la semplicità realizzativa. Il blocco “Digital Control” è stato strutturato in modo analogo a quello di Simulink usando il blocco “C-Script” duale alla “S-Function” (Figura 2.4c).

(22)

(a) Digital Control Simulink

(b) Digital Control PLECS

(c) Digital Control S-Function10

(23)

(a) Maschera Digital Control Simulink (b) Maschera Digital Control PLECS

Figura 2.5: Parametri Script

La pagina di impostazione del blocco C-Script è simile a quella della S-Function, viene inoltre richiesto il numero di input/output e un sample time. Quest’ultimo è impostato a -1 e corrisponde ad un sample time “inherited” ossia il cui valore viene

"ereditato" dai blocchi a cui è connesso il C-Script. I parametri presenti nelle due pagine di impostazione corrispondo alle variabili il cui valore numerico può essere impostato direttamente dalla maschera senza necessità di intervenire sul codice.

La differenza tra i due programmi è netta, almeno a livello strutturale, nel modo di implementare il codice C. In Simulink la S-Function richiama un file .c (in questo esempio il file: “PMSM_ctrl.c”) che racchiude al suo interno la definizione di input/output, la lettura delle variabili passate tramite maschera e ovviamente il richiamo della routine di controllo motore. In PLECS queste funzioni devono essere scritte nell’apposita function selezionabile tramite il pannello “Code” del blocco C-Script (Figura 2.5b). Le varie functions sono descritte all’interno dell’help di PLECS [6] e sono:

• Code declaration;

• Start function code;

• Output function code;

• Update function code;

• Derivative function code;

• Terminate function code;

(24)

Il codice contenuto nella S-function del modello benchmark è stato quindi suddiviso come segue:

• Code declaration In questa sezione vengono inclusi i file e le librerie necessarie al funzionamento del codice e le definizioni dei parametri passati da maschera tramite l’apposita macro ParamRealData(int i, j).

(a) Definizione parametri Simulink (b) Definizione parametri PLECS

Figura 2.6: Code Declaration

• Start Function Code Nella start function vengono riportati i parametri da inizializzare all’avvio della simulazione ossia quelli che in Simulink vengono impostati nelle function mdlInitializeSizes e mdlInitializeConditions.

(a) Inizializzazione parametri Simulink (b) Inizializzazione parametri PLECS

Figura 2.7: Start Function Code

• Update Function Code Il codice riportato in questa function serve per scrivere i valori dei parametri passati tramite maschera e gli input provenienti dagli altri blocchi (macro Input()) in apposite variabili, viene infine richiamata la motor control routine ossia la parte di codice contenente l’algoritmo di controllo del motore.

• Output Function Code Infine vengono definiti i valori di output tramite la macro Output():

(25)

(a) Update parametri Simulink (b) Update parametri PLECS

Figura 2.8: Update Function

(a) Output Simulink (b) Output PLECS

Figura 2.9: Code Declaration

(26)

Risultati Simulazione

(a) Velocità e coppia (b) Duty Cicle

(c) Correnti assi dq (d) Tensioni assi dq

(e) Flussi assi dq e αβ

Figura 2.10: Modello Benchmark SPM

(27)

2.1.2 Modello Benchmark IM

vs* alpha,beta 1-u(1)

speed control

is alpha,beta duty

Vdc dc-link

current control PWM Interrupt

lambdaR_VI

Load Torque dutyABC vdc iABC enable

vAn

vBn

vCn Inverter Average Model

[Te]

[n]

[StatorFlux]

[Lm]

[dutyABC]

[speed_control]

[iabcs]

[MagnFlux]

[RotorFlux]

[thetar]

[vs_ab]

[iq_ctrl]

[Fr_VI]

[Fr_Iw]

[id_ctrl]

[is_ab]

[vs_ref]

[Pmec]

[vdc]

[iabcs]

[is_ab]

[vs_ref]

[dutyABC]

[n]

[id_ctrl]

[vdc]

[speed_control]

[Te]

[iq_ctrl]

[iabcs]

[RotorFlux]

[RotorFlux]

[Fr_VI]

[Fr_Iw]

[thetar]

[vs_ab]

[vdc]

[dutyABC]

[iabcs]

lambdaR_Iw Encoder

iabcs

vdc

ThetaMec

n* o T*

isd*

Commands

duty_abc pwm_stop n*,n vs* alpha,beta is alpha,beta id ctrl iq ctrl rotor flux VI rotor flux Iw sin cos FOC State Digital Control

Currents

vas

vbs

vcs

Tload

iabcs lambdas lambdar lambdam Lm wr_rpm Te Pmec_out ThetaMec vs_ab IM model

CIM_255_132/ZN1

Buttons + State

vaN

sin cos FOC 3

isd*

ref measTload Speed Control

Load Speed 3000

nref or Tref

Res Go

Flux1 [StatorFlux]

[RotorFlux]

-T- -T- State

phase currents

torque

id iq

iq Reset

Go Go

Go

Figura 2.11: Modello benchmark IM

Il modello benchmark del motore asincrono si basa sul motore C.e.SET CIM 2/55 132/ZN , su questo motore sono state effettuate delle prove a vuoto e a rotore bloccato, i dati ottenuti da questi test (come ad esempio le induttanze di statore e rotore) sono stati raccolti in un file .mat denominato Ceset700W_TestData.mat e caricato dal software quando viene lanciato il file di inizializzazione il cui codice è riportato al 2.4 [14]. L’inverter ed il blocco di controllo sono gli stessi presentati per il motore SPM.

Per il motore asincrono è stato implementato il controllo scalare V/Hz riportato in Figura 2.12 [3, p. 339].

% PWM

Tsw = 500e−6; % control task [s] = PWM task

%dc link voltage

Vdc = 310; % dc link voltage

% MOTOR DATA

% Motor name: CESET CIM2/55−132/ZN

% Ratings: 700W, 220 V line @ 83.3 Hz, 3A, 300 Hz max

% 1.8 Nm, 4820 rpm, sn = 3.6%

% No−load test run at 100Hz, Locked rotor test run at 20 Hz

(28)

Figura 2.12: Controllo scalare V/Hz

load Ceset700W_TestData % no load and short circuit test data Vnom = 220; % (V rms − line)

Inom = 3; % (A rms) fnom = 83.3; % (Hz)

Fnom = Vnom∗sqrt(2/3)/(2∗pi∗fnom); % k factor (Vs)

% other data

Rs = 3.25; % stator resistance (Ohm) Rr = 1.64; % rotor resistance (Ohm) Rfe = 1000; % Iron loss resistance (Ohm) J = 0.002; % total inertia (kgm^2)

flag_sat = 1; % magnetic saturation [if flag_sat == 0 Sat.= OFF];

flag_pfe = 0; % iron loss [ if flag_pfe == 0 Rfe = inf];

% Mechanical loss Nm = Tmec_a0 + Tmec_a2 ∗ w^2 P0 = 10; % ventilation loss at nmax (W) nmax = 6000; % maximum operating speed (rpm) Bm = 0; % damping constant (Nm/(rad/sec)) Tc =eps; % friction loss (Nm) [eps=2.2204e−16]

Kv = P0/(nmax∗pi/30)^3;% ventilation loss coeff. (W/(rad/s)^3 = Nm/(rad/s)^2)

Codice 2.4: Inizializzazione Motore IM. File: "init_sim.m"

(29)

Risultati simulazione benchmark

(a) Velocità e coppia (b) Duty Cicle

(c) Correnti assi abc (d) Tensioni assi αβ

(e) Flussi assi dq e αβ

Figura 2.13: Modello Benchmark IM

(30)

2.2 Modelli circuitali

I modelli che sono presentati in questa sezione sono basati su componenti circuitali di inverter e motore provenienti dalle librerie Simulink e PLECS. I blocchi fisici dei motori sono presentati nelle pagine seguenti mentre per quanto riguarda l’inverter sono presentati tre diversi modelli:

• Inverter Average

• Inverter Logico

• Inverter Fisico

2.2.1 Modello fisico SPM

In Figura 2.14 sono riportati i blocchi utilizzati per il motore SPM, entrambi gli ambienti forniscono un modello di motore sincrono a magneti permanenti denominato

“Permanet-Magnet Synchronous Machine”. In Figura 2.15 vengono riportate le pagine di configurazione dei motori nei due programmi. I dati utilizzati per il motore provengono dal file init_SPM.m del modello benchmark riportati nel paragrafo dedicato al SPM nella sezione 2.1. Il controllo del motore SPM richiede l’utilizzo di un encoder assoluto, i modelli Simulink utilizzano lo stesso encoder utilizzato nel modello benchmark, in PLECS viene replicata la stessa struttura. In Figura 2.16 vengono riportati i due schemi, l’unica differenza è data dal C-Script nel modello PLECS (fig. 2.16b), quest’ultimo serve per saturare tra zero e 2π il valore riportato nei grafici e utilizza il codice 2.5 cosa che in Simulink viene effettuata nel momento in cui vengono rappresentati i risultati.

posMot =InputSignal(0,0);

posEnc =InputSignal(0,1);

if (posMot<0) posMot+=(2∗pi);

if (posMot>(2∗pi)) posMot−=(2∗pi);

if (posEnc<0) posEnc+=(2∗pi);

if (posEnc>(2∗pi)) posEnc−=(2∗pi);

Codice 2.5: C-Script Encoder

(31)

(a) SPM - Simulink

(b) SPM - Plecs

Figura 2.14: Modello motore SPM

(32)

(a) Impostazioni Motore - Simulink

(b) Impostazioni Motore - Plecs

Figura 2.15: Impostazioni SPM

(33)

(a) Encoder Assoluto Simulink

(b) Encoder Assoluto PLECS

Figura 2.16: Schema encoder assoluto

Perdite Meccaniche

Per entrambi i motori la simulazione benchmark prevede delle perdite meccaniche dovute alla presenza di attrito. La coppia di attrito è tipicamente caratterizzata da tre componenti: una coppia dovuta all’attrito statico, una dovuta a quello viscoso e proporzionale alla velocità ed una definita di ventilazione funzione della velocità al quadrato. Nel modello benchmark l’effetto dell’attrito viene considerato all’interno delle equazioni meccaniche del motore e non tiene conto della componente viscosa, la coppia d’attrito per questi modelli è quindi descrivibile con la seguente equazione:

Tloss = Tc+ Kv · ω2r [N m] (2.1) – Tc = coppia attrito statico [Nm]

– Kv = coefficiente perdite ventilazione [Nm/(rad/s2)]

I modelli di motore presentati nelle sottosezioni precedenti non prevedono invece questo tipo di perdita meccanica. Nei modelli qui presentati ho quindi introdotto il subsystem denominato "TmechLoss", sia in ambiente MATLAB che PLECS, che riceve in ingresso i valori di ω e della coppia di carico (Tload) e restituisce in uscita la coppia meccanica all’albero Tm secondo l’equazione 2.2.

Tm= Tload+ (Tc+ Kv· ωr2) · sign(ωr) [N m] (2.2)

(34)

Nel caso del motore SPM in ambiente MATLAB viene impostato a zero il valore di Tc all’interno del subsystem in quanto l’attrito statico è già presente nel modello di motore (vedi Figura 2.15a).

La Tm viene fornita come input meccanico per il motore e considerata come coppia resistente, in Simulink può essere inviata direttamente alla blocco motore mentre in PLECS è necessario introdurre la sorgente di coppia "Torque (controlled)"

della libreria meccanica rotazionale.

(35)

2.2.2 Modello fisico IM

(a) IM - Simulink

(b) IM - Plecs

Figura 2.17: Modello motore asincrono

(36)

In Figura 2.17 sono riportati i blocchi utilizzati nei due ambienti per l’IM; in Simulink è stato selezionato il motore Asynchronous Machine SI Unit mentre in PLECS il componente Induction Machine (Slip Ring, Saturable). In Figura 2.19 vengono riportate le configurazione dei blocchi motore nei due programmi; in entrambi i casi è prevista la saturazione del motore, il modo in cui questa viene modellata è però nettamente diverso e richiede quindi un approfondimento.

Nel modello Simulink la saturazione è modellata a partire dai valori di corrente e tensione ottenuti durante la prova a vuoto del motore, come già detto in sezione 2.1 sono stati forniti i valori delle prove a vuoto[14], i valori di corrente e tensione sono stati quindi inseriti nell’apposita casella come riportato in Figura 2.19b. Per quanto riguarda PLECS la pagina di impostazione del motore è riportata in Figura 2.19c. Rispetto alle impostazioni richieste da Simulink troviamo alcuni parametri aggiuntivi: Lm0, Lmsat, PsiT e fT. Questi ultimi sono necessari per introdurre l’effetto della saturazione che viene in questo caso modellata a partire dalla curva ψm - im riportata in Figura 2.18a.

I parametri corretti da inserire nel modello PLECS sono stati ottenuti confrontan- do tramite MATLAB la curva ψm - im ottenuta a partire dai dati raccolti durante le prove sul C.e.SET CIM 2/55 132/ZN con la curva ottenuta con le equazioni utilizzate da PLECS per modellare la saturazione e contenute nello script interno al modello di motore [4], stimando dei valori di partenza dai dati forniti dalle prove ho corretto iterativamente i valori delle quattro variabili citate fino a sovrapporre esattamente la curva del modello PLECS a quella reale come riportato in Figura 2.18b. I valori finali sono riassunti in tabella 2.1.

Tabella 2.1: Parametri modello IM Parametro Valore [Unità di misura]

Lm0 0.1483 [H]

Lmsat 0.026 [H]

PsiT 0.32 [Vs]

fT 5 -

(37)

(a) Curva ψm - im. Immagine tratta da [6]

(b) Confronto curve ψm- im

Figura 2.18: Curve ψm - im

(38)

(a) Impostazioni Motore - Simulink.

Configurazione (b) Impostazioni Motore - Simulink.

Parametri e saturazione

(c) Impostazioni Motore - Plecs

Figura 2.19: Impostazioni IM

(39)

2.2.3 Modello Average Inverter

(a) Connessioni inverter AVG

(b) Impostazioni Universal Bridge

Figura 2.20: Inverter Average Simulink

Questa sotto sezione presenta il modello di inverter Average (AVG), questo tipo di modello utilizza un valore mediato del segnale di switch calcolato o su un "ciclo di switch" dell’inverter o sovra-campionando il segnale a intervalli regolari. Citando un esempio degli autori di [1] se durante uno step di simulazione non avvengono eventi di switching il segnale inviato all’inverter rimane 1 o 0 mentre se per esempio avviene un evento a metà step il valore mediato sarà 0.5. Questo concetto viene ripreso più avanti e nello specifico per il modello utilizzato in PLECS.

Per quanto riguarda il modello Simulink è stato utilizzato il blocco Universal Bridge presente in libreria, le impostazioni possibili, riportate in Figura 2.20b sono limitate per il modello AVG (numero di gambe ed eventuali valori da riportare fuori maschera per la misura). Il modello utilizza il segnale di riferimento per generare un valore di tensione medio ai terminali ABC del convertitore.

(40)

La libreria PLECS non fornisce un blocco inverter direttamente utilizzabile in modalità average ma quest’ultimo può essere realizzato usando 3 blocchi IGBT Half Bridge. I quali presentano due modalità di utilizzo:

• Switched: I semiconduttori sono modellati con degli interruttori ideali. Il singolo IGBT è controllato con i segnali logici di gate.

• Sub-cycle average: In questa modalità il modulo è realizzato usando delle sorgenti di tensione e corrente funzione dei comandi di switch. Gli input di controllo devono essere forniti sotto forma di valori compresi tra 0 ed 1 e possono essere o i comandi logici istantanei oppure i duty cycles dei singolo IGBT [6].

Se un segnale di switch viene campionato ad intervalli regolari, corrispondenti al time step della simulazione, il duty del segnale campionato è tipicamente affetto da un errore quando la transizione del segnale avviene tra due time steps. La modalità Sub-cycle average" (SCA) consente di ridurre questo errore tramite un sovra-campionamento del segnale di switch, come evidente in Figura 2.21, con intervalli di tempo nettamente minori allo step size della simulazione. Inoltre, la SCA non necessita, contrariamente alla modalità Switched, di matrici di stato per le varie combinazioni di switch che devono essere calcolate a priori e la cui lettura tende a rallentare la simulazione [1].

h]

Figura 2.21: Confronto tra segnale originale e campionato. Figura tratta da [1]

(41)

(a) Average Inverter

(b) Average Inverter schema

(c) Impostazioni Half Bridge

Figura 2.22: Inverter Average PLECS

(42)

2.2.4 Modello Logico Inverter

(a) Inverter Simulink

(b) Inverter PLECS

Figura 2.23: Inverter ideale

I modelli di tipo logico utilizzano un inverter basato su interruttori ideali. Sia il blocco inverter di Simulink che quello di PLECS usati nei modelli average sono impostabili in modalità "ideale" anche se con alcune differenze. Come è evidente dalla Figura 2.24a l’inverter di Simulink presenta uno snubber resistivo e una resistenza di on il cui valore deve essere non nullo per il corretto funzionamento della blocco. I valori utilizzati (e riportati in Figura) sono quelli suggeriti nell’Help.

Il blocco inverter di PLECS invece, impostato in modalità "Switched", non ha valori impostabili ed utilizza degli interruttori ideali. Nel momento in cui si passa da un inverter average a quello ideale non è più possibile utilizzare direttamente i duty cycle come segnali di comando ma bisogna ricavare degli opportuni valori PWM.

(43)

Questo risulta molto semplice in PLECS in cui viene fornito il blocco "Symmetrical PWM" riportato in Figura 2.24b. Quest’ultimo si comporta come un modulatore PWM confrontando il segnale in ingresso (Duty trifase) con una portante triangolare simmetrica della quale possiamo selezionare tipo, frequenza ed eventuale offset, inoltre è possibile decidere il range dei valori di input e output (fig. 2.25). In Simulink è invece necessario modellare un subsystem appropriato il cui schema è riportato in Figura 2.26b.

(a) Impostazioni inverter Simulink (b) Impostazioni inverter PLECS

Figura 2.24: Impostazioni inverter ideale

(44)

Figura 2.25: Impostazioni symmetrical PWM

(a) Symmetrical PWM

(b) Comandi di gamba Simulink

Figura 2.26: Generazione comandi di gamba

(45)

2.2.5 Modello Fisico Inverter

(a) Inverter modello fisico Simulik

(b) Inverter modello fisico PLECS

Figura 2.27: Modelli inverter fisico

L’ultimo modello presentato viene chiamato "Fisico", a differenza dei modelli precedenti include anche il deadtime e utilizza un inverter con parametri "reali". Il modello di benchmark è sempre il modello didattico ma, contrariamente a quanto fatto nel caso dei modelli Average e Logico, sono stati attivati deadtime e cadute di tensione delle componenti elettroniche. Inoltre è stata riattivata la compensazione del deadtime nel codice di controllo. Il blocco inverter in Simulink è lo stesso

(46)

(a) Impostazioni inverter fisico Simulink (b) Impostazioni inverter fisico PLECS

Figura 2.28: Impostazioni inverter

utilizzato nei precedenti modelli; tra le varie impostazioni possibili per questo blocco è stata selezionata la modalità "IGBT/Diodes". I valori impostabili sono la resistenza di On (Ron) dei componenti elettronici e le tensioni di forward (Vf). I valori di Ron e Vf che compaiono in Figura 2.28a sono ricavati ancora una volta dal file di inizializzazione del modello benchmark [vedi sezione 2.1.1]. In PLECS ho invece utilizzato il blocco "IGBT Converter with Parasitics (3ph)" ossia un modello di inverter trifase a IGBT presente in libreria con valori di resistenza di on e forward voltage impostabili da maschera (fig. 2.28b).

Come già detto in questo modello è stato introdotto il deadtime. Per quanto riguarda Simulink, la libreria fornisce il componente "On/Off delay", quest’ultimo applica un ritardo al segnale di input quando l’input cambia da FALSE (0) a TRUE (1) o viceversa. In questo caso è stato impostato in modalità "On delay" in modo tale che quando l’input diventa TRUE l’output diventa a sua volta TRUE dopo un intervallo specifico di tempo (1 µs), viceversa se l’input passa al valore FALSE l’output diventa immediatamente FALSE. Il delay è stato aggiunto per ogni comando di gamba come riportato in Figura 2.29. In PLECS invece è stato introdotto il blocco "Blanking Time" a valle del modulatore (vedi Figura 2.27b); quest’ultimo provvede ad inserire opportunamente il ritardo di on su ogni comando di gamba ottenendo quindi lo stesso risultato ottenuto in Simulink.

(47)

Figura 2.29: On Delay Simulink

2.3 Confronto risultati simulazione

In questa sezione vengono presentati i risultati ottenuti dalle simulazioni dei modelli.

Per entrambi i motori troviamo a sinistra i valori ottenuti con Simulink mentre a destra quelli del modello analogo realizzato in PLECS. Tutti i modelli presentati sono stati simulati sia con un solver Fixed-Step che con uno di tipo Variable-Step. I modelli del motore SPM però risultano incompatibili con un solver a step variabile, in entrambi gli ambienti infatti la simulazione si blocca dopo pochi secondi senza però segnalare errori.

Simulink presenta in generale una maggiore varietà di solver mentre PLECS propone solamente il solver "Discrete" per il caso fixed e "RADAU (stiff)" o "DOPRI (Non stiff)" per il variable. Nel caso delle simulazioni fixed step è stato usato il solver denominato "Discrete", presente anche in Simulink, mentre per il caso variable ho utilizzato un solver di tipo "stiff"; in generale possiamo definire un modello "rigido"

(stiff in inglese) quando sono presenti componenti che variano con costanti di tempo estremamente diverse [15], nei modelli presi in considerazione, per esempio, viene simulato un inverter ideale con switching istantaneo ma anche delle componenti meccaniche molto più lente. É stato quindi selezionato il solver RADAU per PLECS e Ode23s per Simulink.

Nelle prossime pagine vengono presentarti i risultati ottenuti dalle simulazioni, il passo in fixed step è stato impostato a 5 µs per i modelli AVG e Logico mentre per il modello con inverter Fisico in cui viene modellato un dead time di 1µs è necessario ridurre il passo di simulazione. Usando un passo di simulazione maggiore del dead time quest’ultimo ovviamente non sarebbe simulato correttamente di conseguenza il passo è stato impostato esattamente a 1µ. Non è stato possibile ridurre il passo a valori inferiori al microsecondo, la RAM richiesta dai software infatti avrebbe superato quella disponibile sul computer utilizzato.

(48)

(a) Impostazioni solver Ode23s

(b) Impostazioni solver RADAU

Figura 2.30: Impostazioni solver variable step

(49)

(a) Modello Average Simulink (b) Modello Average PLECS

(c) Modello Logico Simulink (d) Modello Logico PLECS

(e) Modello Fisico Simulink (f) Modello Fisico PLECS

Figura 2.31: Velocità e coppia modelli SPM

(50)

(a) Modello Average Simulink (b) Modello Average PLECS

(c) Modello Logico Simulink (d) Modello Logico PLECS

(e) Modello Fisico Simulink (f) Modello Fisico PLECS

Figura 2.32: Duty Cylce modelli SPM

(51)

(a) Modello Average Simulink (b) Modello Average PLECS

(c) Modello Logico Simulink (d) Modello Logico PLECS

(e) Modello Fisico Simulink (f) Modello Fisico PLECS

Figura 2.33: Correnti assi dq modelli SPM

(52)

(a) Modello Average Simulink (b) Modello Average PLECS

(c) Modello Logico Simulink (d) Modello Logico PLECS

(e) Modello Fisico Simulink (f) Modello Fisico PLECS

Figura 2.34: Tensioni assi dq modelli SPM

(53)

(a) Modello Average Simulink (b) Modello Average PLECS

(c) Modello Logico Simulink (d) Modello Logico PLECS

(e) Modello Fisico Simulink (f) Modello Fisico PLECS

Figura 2.35: Flussi modelli SPM

(54)

(a) Modello Average Simulink (b) Modello Average PLECS

(c) Modello Logico Simulink (d) Modello Logico PLECS

(e) Modello Fisico Simulink (f) Modello Fisico PLECS

Figura 2.36: Velocità e coppia modelli IM

(55)

(a) Modello Average Simulink (b) Modello Average PLECS

(c) Modello Logico Simulink (d) Modello Logico PLECS

(e) Modello Fisico Simulink (f) Modello Fisico PLECS

Figura 2.37: Duty Cylce modelli IM

(56)

(a) Modello Average Simulink (b) Modello Average PLECS

(c) Modello Logico Simulink (d) Modello Logico PLECS

(e) Modello Fisico Simulink (f) Modello Fisico PLECS

Figura 2.38: Correnti modelli IM

(57)

(a) Modello Average Simulink (b) Modello Average PLECS

(c) Modello Logico Simulink (d) Modello Logico PLECS

(e) Modello Fisico Simulink (f) Modello Fisico PLECS

Figura 2.39: Tensioni trifase modulate modelli IM

(58)

(a) Modello Average Simulink (b) Modello Average PLECS

(c) Modello Logico Simulink (d) Modello Logico PLECS

(e) Modello Fisico Simulink (f) Modello Fisico PLECS

Figura 2.40: Flussi modelli IM

(59)

Osservando i risultati riportati nelle pagine precedenti risulta evidente, a parità di solver e di modello, una maggiore rumorosità nei modelli PLECS. La differenza è evidente per esempio per le correnti in assi dq del modello logico del motore SPM (vedi Figura 2.33d). Il passo di calcolo è ovviamente lo stesso e le impostazioni dei modelli nei due ambienti sono speculari, questa differenza sembra essere imputabile quindi al modello dell’inverter logico usato in PLECS che, per esempio, non presenta resistenza di On contrariamente a quello di Simulink, nel quale come già detto in sottosezione 2.2.4 è presente, seppur piccola, una Ron. Questa differenza rimane, seppur in maniera minore grazie anche ad un passo di simulazione più fitto nel modello Fisico. Per quanto riguarda il modello con inverter Average non si notano invece differenze evidenti tra i due programmi se non in termini di tempi di calcolo come illustrato nelle prossime pagine.

(60)

2.3.1 Tempi di calcolo

Viene infine presentato un confronto dei tempi di calcolo necessari ai due programmi per simulare i modelli precedentemente presentati. Vengono riportati sia i tempi in Fixed-Step che in Variable-Step. I valori riportati alle figure 2.41 e 2.42 sono ottenuti dalla media dei tempi di 5 simulazioni per ogni modello e per ogni solver.

L’asse dei tempi, data la notevole disparità tra le simulazioni è presentato in scala logaritmica. I tempi di calcolo di Simulink sono ottenuti usando le funzioni tic-toc richiamate automaticamente all’avvio/stop della simulazione. Lo stesso risultato si può ottenere con PLECS usando lo script riportato a fondo pagina (codice 2.6).

É evidente la disparità di prestazioni tra Simulink e PLECS, il secondo software risulta in generale più veloce, in particolare la differenza è netta nel caso fixed step;

per esempio, simulando il modello fisico a 1µs i tempi necessari a PLECS sono paragonabili a quelli che Simulink richiede per simulare il modello benchmark, in generale più rapido rispetto agli altri modelli in ambiente MATLAB, con un passo di simulazione 5 volte maggiore. L’andamento viene confermato anche nel caso del solver a passo variabile, anche se il confronto è possibile soltanto nel caso del motore asincrono dato che i modelli SPM non risultano compatibili come già detto, anche in questo caso infatti il software PLECS risulta nettamente più veloce.

Per quanto riguarda invece il confronto tra i due tipi di solver, fixed e variable step, se dal punto di vista dei risultati non si notano differenze tali da essere evidenziate, possiamo notare alcune differenze nei tempi di calcolo. Per quanto riguarda i modelli Average il solver a passo variabile richiede tempi di calcolo minori, con differenze evidenti per l’ambiente MATLAB; il passo di calcolo utilizzato dal solver variable risulta probabilmente maggiore rispetto ai 5 µs scelti per il caso fixed consentendo quindi di ottenere un risultato con un numero di passi minore e quindi un tempo di calcolo minore; un comportamento analogo viene evidenziato per il modello Fisico.

Al contrario nel caso Logico, il tempo di calcolo aumenta in entrambi gli ambienti ed in particolare in PLECS, questo è dovuto all’utilizzo di un passo di calcolo minore rispetto a quello impostato in modalità fixed per effetto probabilmente delle commutazioni degli interruttori ideali che costituiscono l’inverter logico.

plecs(tic ’simulate’) toc

Codice 2.6: Script PLECS tic-toc

(61)

(a) Fixed-Step

(b) Variable-Step

Figura 2.41: Tempi di calcolo SPM

(62)

(a) Fixed-Step

(b) Variable-Step

Figura 2.42: Tempi di calcolo IM

(63)

Avendo osservato i risultati e i tempi di calcolo si può affermare che, sicuramente, PLECS risulta essere una valida alternativa all’ambiente MATLAB, risultando in generale più rapido, leggero ed intuitivo rispetto all’alternativa di proprietà MathWorks. Per quanto riguarda i modelli presentatati però, pensando per esempio allo scopo didattico per cui sono nati, ritengo che l’unico modello che potrebbe sostituire i modelli Benchmark stessi sarebbe un modello Average in ambiente PLECS in cui possono essere implementati in aggiunta la modulazione PWM ed il deadtime. Il problema principale di introdurre il deadtime è dato dal fatto che, per essere competitivo in termini di tempi di calcolo, il modello dovrebbe essere simulato con un solver a passo variabile che, come sottolineato in precedenza, non risulta però compatibile con ogni modello; usando un solver fixed dovremmo utilizzare anche in questo caso un passo estremamente ridotto (almeno pari al deadtime) riconducendo la simulazione a tempi di calcolo prossimi a quelli del modello Fisico senza però avere le cadute di on e senza che vengano evidenziati nei risultati gli effetti della commutazione presenti invece nel caso con inverter fisico.

(64)
(65)

Hardware-in-the-loop

Figura 3.1: Sistema Hardware-in-the-loop di un azionamento elettrico Obiettivo di questa seconda parte dell’elaborato è quello di realizzare un modello del motore sincrono a magneti permanenti Microphase S140-2B353, utilizzato per introdurre gli studenti alla programmazione dei microcontrollori durante il corso

1 già citato. Il modello viene sviluppato in ambiente PLECS, sfruttando quindi i modelli e le abilità acquisite durante la realizzazione della prima parte dell’elaborato,

1"Controllo digitale di convertitori e azionamenti" tenuto dal Professor. Pellegrino per il corso di laurea magistrale in Ingegneria Elettrica del Politecnico di Torino

(66)

Figura 3.2: Hardware-in-the-loop. RT Box e scheda Nucleo

e è utilizzato in un sistema Hardware-in-the-loop (HiL) grazie al simulatore real time

"RT Box" prodotta da Plexim. Innanzitutto viene implementato un controllo su microcontrollore connesso al motore tramite un inverter, analizzato il comportamento del motore e a partire dal datasheet e da alcune misure viene quindi sviluppato il modello da simulare in real time. Prima di procedere con questo caso specifico viene presentata una breve introduzione sul concetto di HiL.

3.1 Cos’è l’Hardware-in-the-loop?

La simulazione con Hardware-in-the-loop è una tecnica che consente di sviluppare e testare sistemi di controllo usati per applicazioni real-time. In un sistema reale la macchina o le componenti fisiche sono connessi ad un controllore tramite l’uso di sensori. In un HiL le componenti fisiche vengono sostituite da una simulazione che, se progettata in modo corretto, replica esattamente il comportamento dell’impianto anche in termini di sensori ed attuatori ed è in grado di ricevere ed interpretare i segnali fisici provenienti dal sistema di controllo; il tutto con dei tempi di simulazione compatibili con i tempi del sistema simulato, in altre parole gli eventi simulati devono avvenire ed avere una durata pari a quella degli eventi "originali".

(67)

Molto spesso il sistema di controllo e l’impianto "fisico" vengono progettati contemporaneamente consentendo di testare il controllo solamente durante la fase di commissioning con il rischio di ritardare la consegna o danneggiare il prodotto in caso di errori. La soluzione HiL consente di anticipare il testing che può a questo punto essere fatto anche in assenza del sistema finito ed in completa sicurezza.

Inoltre, essendo la componente fisica simulata, diventa possibile testare condizioni nelle quali l’hardware verrebbe danneggiato irrimediabilmente in modo da verificare, per esempio, il corretto intervento di protezioni o algoritmi di sicurezza. Tutto ciò con un vantaggio anche dal punto di vista economico andando ad eliminare la necessità di utilizzare prototipi e precauzioni di sicurezza che possono rivelarsi costose o, più semplicemente, la necessità di recarsi nel luogo di installazione del sistema per il test.

La soluzione HiL più semplice consiste nell’utilizzare un computer sul quale viene installato un software di modellistica e simulazione per simulare il comportamento dell’impianto o dell’azionamento. Bisogna però tener conto del fatto che i sistemi operativi comunemente installati su un PC (Windows per esempio) non lavorano in real-time; per un’accurata simulazione diventa quindi necessario equipaggiarsi di un simulatore HiL basato su un’architettura real-time come la RT Box presentata più avanti [10, 9].

(68)

3.1.1 Simulatore Real-Time: RT Box

La RT Box (RTB) è un simulatore real-time che può essere utilizzato sia in funzione HiL sia come strumento per "rapid control prototyping". Come già spiegato in precedenza usando la RTB in termini di HiL andremo a simulare in real-time gli stadi di potenza (elettronica di potenza e motore) sfruttando gli input/output analogici e digitali della RTB per comunicare bidirezionalmente con un microcontrollore (MCU).

In termini di rapid prototyping invece la RTB può essere usata in sostituzione del MCU con il vantaggio di avere un maggior numero di canali ed una CPU più veloce della maggior parte dei microcontrollori [16].

A livello hardware la RTB è fornita di una CPU dual core da 1 Ghz, 32 canali analogici (16 input + 16 output) e 64 digitali (32 input + 32 output) [vedi 8, p. 21]. La connessione degli input/output della RTB con il MCU è possibile grazie all’utilizzo di due schede di interfaccia, una per i canali analogici e l’altra per quelli digitali. Entrambe le schede forniscono input ed output sotto forma di pin headers facilmente compatibili con qualunque microcontrollore. L’interfaccia analogica è inoltre dotata di connessioni BNC mentre quella digitale presenta anche una morsettiera. In Figura 3.3b sono visibili le due schede connesse alla RTB.

(a) RT Box

(b) Schede di interfaccia RT Box

Figura 3.3: RT Box Hardware. Immagini tratte da [16]

(69)

3.2 Configurazione Hardware

Figura 3.4: Schema configurazione hardware

In Figura 3.4 è riportato uno schema della configurazione hardware che è stata simulata. La scheda inverter X-NUCLEO-IHM08M1 viene montata su una scheda Nucleo STM32 e connessa al motore Microphase S140 ed all’encoder integrato. Nei prossimi paragrafi sono presentati singolarmente i componenti presenti nello schema appena illustrato.

Microcontrollore L’algoritmo di controllo è implementato su un microcontrollore (MCU) della famiglia STM a 32 bit. In particolare è stato utilizzato il STM32F303RE basato su processore ARM Cortex (72MHz clock, DMIPS2 90) e montato sulla scheda Nucleo STM32 (Figura 3.5) ossia un "Evaluation Kit" che consente di testare rapidamente il controllo ed il MCU integrando direttamente sulla scheda le connessioni necessarie per interfacciarsi alle componenti di potenza e per consentire la programmazione ed il debug tramite PC.

2Dhrystone MIPS, benchmark di misura del numero di istruzioni eseguite al ciclo. MIPS è acronimo di million instructions per second

(70)

Figura 3.5: Scheda Nucleo STM32. Immagine tratta da [18]

Per programmare la scheda e fare debug e build del codice sono stati utilizzati i seguenti software:

• STM32CubeMX3 prodotto dalla STM consente di attivare ed impostare tramite interfaccia grafica le periferiche presenti sulla scheda Nucleo

• KEIL µVision54 prodotto dalla KEIL è un ambiente di sviluppo che combina editing, compilazione e debug real-time del codice.

(a) CubeMX (b) µVision5

Figura 3.6: Software

3www.st.com/en/development-tools/stm32cubemx.html

4www.keil.com/download/product/

(71)

Inverter La scheda X-NUCLEO-IHM08M1 (Figura 3.7) è una expansion board prodotta dalla STM e pensata per essere compatibile con le schede Nucleo STM32.

La scheda contiene tutto il necessario per controllare un motore brushless trifase.

Sulla scheda troviamo un’inverter realizzato con Power MOSFET STripFET™ F7 STL220N6F7 (RDS=0.0014 Ω)[vedi 19] insieme ovviamente ai driver necessari per il loro controllo. Sono presenti inoltre 3 shunt di corrente e un sensore per la misura della tensione di DC-link.

Figura 3.7: Scheda X-NUCLEO-IHM08M1. Immagine tratta da [20]

(72)

Microphase S140-2B353 Il motore S140-2B353 , prodotto dalla Microphase, è un servomotore brushless sinusoidale a magneti permanenti (NdFeB) a 4 coppie polari dotato di encoder incrementale a 2048 divisioni. Il motore S140 non viene fatto girare a vuoto ma viene usato per trascinare un secondo motore, in particolare viene utilizzato il Microphase S160-1B303. I parametri principali indicati nel datasheet [11] sono i seguenti:

Tabella 3.1: Principali parametri Motore Microphase S140-2B353 Parametro Valore [Unità di misura]

VN 17 [VAC]

IN 6.6 [A]

PN 100 [W]

NN 3000 [rpm]

KE 3.15 [VRMS/krpm]

J 0.06 [kg cm2]

RU-V 0.5 [Ω]

LU-V 0.53 [mH]

Figura 3.8: Microphase S140 e S160

Riferimenti

Documenti correlati

I Per salvare tutte e solo alcune variabili x , y e z della sessione di lavoro in un file (con estensione.mat) di nome nomefile si utilizza il comando save..  save

• File (di comandi) per la graficazione risultati ( motoreDC0plot.m ) Permette di rappresentare e di elaborare i segnali rilevati durante la simulazione del modello Simulink. NOTA

Tutte le variabili usate all’interno di una function sono variabili locali, cio` e esistono solo durante l’esecuzione della funzione e non modificano il workspace. Ad esempio,

I primi due input del comando linspace corrispondono agli estremi del vettore desiderato, mentre il terzo input corrisponde al numero totale di elementi che si desiderano nel

Se si vuole cambiare direttorio dove salvare e far eseguire i file di Matlab™ è possibile utilizzare il comando chdir nomedir.. Esempio:

• Quando Matlab entra nella funzione MySum, le variabili note sono SOLO quelle presenti nella funzione o passate alla

I risultati sono raccolti in forma matriciale dove ogni matrice rappresenta le simulazioni implementate con determinate condizioni

insiemi di comandi ‘autonomi’ (function) che possono essere poi essere utilizzati in più programmi (script). − Le funzioni accettano variabili in input e restituiscono altre