Vai al contenuto
PLC Forum


Motore BLDC lavatrice LG


marcoc4d

Messaggi consigliati

Sandro Calligaro
2 ore fa, Sandro Calligaro ha scritto:

Hai capito bene il problema, vedo.

Era un modo per dire "bravo!": non è banale capire queste cose con poche righe di spiegazione.

Modificato: da Sandro Calligaro
Link al commento
Condividi su altri siti


  • Risposte 159
  • Created
  • Ultima risposta

Top Posters In This Topic

  • marcoc4d

    71

  • Sandro Calligaro

    62

  • Livio Orsini

    19

  • zhavinchi1

    4

Grazie Sandro non ti preoccupare avevo capito che era un complimento.

Continuando a guardare nelle librerie si st ho visto che hanno tre opzioni in caso di sovravoltaggio:

1 resistenza esterna

2 aprire tutti gli igbt, ma rimangono i diodi flyback che possono condurre se la sovratensione arriva dal motore

3 chiudere i 3 igbt bassi mettendo in corto le fasi del motore

Ora che ci penso il controller della lavatrice penso che chiuda proprio i tre switch bassi quando finisce una centrifuga e inoltre se si stacca la spina e si ruota velocemente il cestello la lavatrice si accende (con la spina staccata) e "frena", era una cosa strana che non capivo a cosa servisse ma forse é proprio per una questione di protezione dalla sovratensione che può essere generata dal motore.

Mettendo in corto le fasi del motore penso che comunque la corrente sia autolimitata dalle impedenze delle fasi cioé se la bemf e proporzionale alla velocità, l impedenza  pure é proporzionale alla velocità quindi la corrente dovrebbe rimanere costante.

Link al commento
Condividi su altri siti

Sandro Calligaro
17 ore fa, marcoc4d ha scritto:

Mettendo in corto le fasi del motore penso che comunque la corrente sia autolimitata dalle impedenze delle fasi cioé se la bemf e proporzionale alla velocità, l impedenza  pure é proporzionale alla velocità quindi la corrente dovrebbe rimanere costante.

Il valore di corrente di corto-circuito è molto importante, e viene anche chiamato "corrente caratteristica".

Trascurando le cadute resistive, si tratta del punto di lavoro con Id = -flusso_magnete/Ld ed Iq = 0, perché a quella corrente si ha tensione nulla.

A seconda che la corrente caratteristica sia dentro o fuori il limite di corrente, si ha o non si ha il funzionamento in Maximum Torque Per Voltage (che è in pratica una modalità di deflussaggio in cui devi limitare la corrente, altrimenti la Id negativa inizia a far aumentare la tensione, invece di diminuirla).

 

 

17 ore fa, marcoc4d ha scritto:

il controller della lavatrice penso che chiuda proprio i tre switch bassi quando finisce una centrifuga

Non credo che la lavatrice venga frenata in quel modo, anche se potrebbe essere che aumentino la Id volutamente (per aumentare le perdite) in frenata (in pratica faresti un "corto-circuito parzializzato"). Negli asincroni si fa e viene chiamato "flux-braking".

Non mi pare che i transitori della lavatrice siano particolarmente veloci, ma magari mi sbaglio.

Considera che c'è sempre una resistenza di scarica del bus (è obbligatoria nei drive, ed ha più che senso in tutte le applicazioni), poi ci sono tutti i carichi della lavatrice (oltre il motore) da alimentare. Inoltre, quello che si può fare è frenare con una coppia tale da non far salire troppo il bus. Questo si fa anche nei drive industriali, mettendo un regolatore che limita la Iq (in negativo, se la velocità è positiva, o viceversa), cioè limita la potenza in frenata andando a variare il limite in funzione della tensione di bus (se la tensione sale sopra il limite, abbassi il limite di Iq, se la tensione è sotto il limite, alzi il limite di Iq).

 

 

17 ore fa, marcoc4d ha scritto:

inoltre se si stacca la spina e si ruota velocemente il cestello la lavatrice si accende (con la spina staccata) e "frena"

Quando la lavatrice è spenta, è normale che sia "frenata" e si carichi il bus: come hai detto tu, i diodi ci sono sempre, quindi quando il bus è scarico in pratica è un corto-circuito. Girando a mano il cestello vai a caricare il bus e può essere che la tensione salga ad un livello sufficiente ad accendere il convertitore per il controllo.

Modificato: da Sandro Calligaro
Link al commento
Condividi su altri siti

Le cose si complicano.

quindi la corrente di corto circuito é effettivamente indipendente dalla velocità del motore? Se la corrente di corto circuito é inferiore al limite di corrente allora non c'é problema a mettere in corto le fasi?

Guardando i dati di quel motore della fisher paykell 

 

che - BEMF constant 3.41 Vrms/rad.s-1 Line to neutral, RMS Voltage

Kt – Torque constant 10.22 Nm/A

Km - Motor constant 2.07 Nm / Watt

Inductance 77.9 mH Line to neutral inductance (includes self and mutual inductance)

36 rotor poles

Torque at 140 rpm 31 Nm

 

la corrente di c.c. non é k e*(rotor poles/2)/Inductance? sarebbe 2.43A

facendo la coppia di 31Nm/Kt viene che il motore sopporta almeno una corrente di 3A

 

sono conti che hanno senso?


Ho bisogno di riflettere sul Maximum Torque Per Voltage.

Modificato: da marcoc4d
Link al commento
Condividi su altri siti

  • 2 weeks later...

Rieccomi,

é da circa una settimana che sto sperimentando il materiale della ST che in sé funziona benissimo.

Ci sono alcune cose che non capisco per mia ignoranza della materia.

Le librerie di controllo del motore se configurate per funzionare con i sensori Hall fanno fatica penso per un problema di disturbi (eccoli finalmente), nel senso che quando il motore é alimentato, sul segnale dei sensori si sovrappone una componente a circa 17 khz che guarda caso é la frequenza di pwm. Il risultato é che il motore va facendo un rumore come se il cestello grattasse contro qualcosa.

Cosa posso fare per eliminare questo disturbo? Al momento i sensori sono collegati direttamente agli input della scheda nucleo tramite un partitore per portare il segnale da 10V a 5.

 

Un altra cosa che non capisco é che provando a fare andare il motore senza sensori con BEMF observer + PLL (di cui ho capito solo le idee molto generali e che per il livello di comprensione che ho é come usare la sfera di cristallo per indovinare la posizione del rotore) il controllo rimane open loop fino a circa 150 rpm quando l'observer converge (penso si dica così) e il controllo passa a loop chiuso. Una volta che l'observer ha agganciato il rotore lo tiene agganciato anche se il rotore é quasi fermo. Aggiungo che con BEMF observer il motore é silenzioso.

Mi chiedo se non si possa fare in modo che l'observer converga a velocità basse o bassissime?

Link al commento
Condividi su altri siti

Sandro Calligaro

Ottimi risultati, bravo! 

 

14 ore fa, marcoc4d ha scritto:

Mi chiedo se non si possa fare in modo che l'observer converga a velocità basse o bassissime?

Il problema, in generale, è che a velocità bassa la back-EMF è piccola, perciò ad un certo punto diventa inaffidabile (rapporto segnale/rumore troppo basso) per usarla per la stima. C'è anche un problema di "confusione" tra offset edeffettiva back-EMF, quando la frequenza elettrica diventa bassa. 

 

Nel caso di un motore con costante di tensione alta e numero di coppie polari alto, come il tuo, la minima velocità di funzionamento sensorless dovrebbe essere molto bassa, molto meno di 150 rpm. Quanto più bassa dipende anche dall'eventuale compensazione dei dead-time. 

Link al commento
Condividi su altri siti

Vincenzo Durante 2001

Ma se utilizzi arduino affiancato al suo modulo inverter che utilizzano sulle schede? E fai ciò che vuoi?? Gli fai una schedina su millefori con arduino nano per la gestione della logica e sei apposto.

Link al commento
Condividi su altri siti

Sandro Calligaro
17 ore fa, marcoc4d ha scritto:

Mi chiedo se non si possa fare in modo che l'observer converga a velocità basse o bassissime?

Dimenticavo... Per migliorare il funzionamento a bassa velocità, puoi aggiungere una Id di riferimento non nulla, tipo il 10-20% della nominale.

Link al commento
Condividi su altri siti

 

8 ore fa, Sandro Calligaro ha scritto:

Nel caso di un motore con costante di tensione alta e numero di coppie polari alto, come il tuo, la minima velocità di funzionamento sensorless dovrebbe essere molto bassa, molto meno di 150 rpm

ho riprovato l'observer + pll e in effetti funziona benissimo anche a 30 rpm.

Insistevo sull utilizzo dei sensori hall perché capisco di più come funzionano, ma non sono necessari.

Adesso sto provando il pid per il controllo di velocità ma non riesco a stabilizzarlo, la velocità oscilla tantissimo e se aumento troppo la Ki dopo aver accelerato oltre la velocità di riferimento rallenta troppo velocemente creando un picco di tensione sul bus che manda in protezione il controllo.

6 ore fa, Sandro Calligaro ha scritto:

Per migliorare il funzionamento a bassa velocità, puoi aggiungere una Id di riferimento non nulla, tipo il 10-20% della nominale

ho provato a mettere un Id negativa, e sono arrivato fino a 1000 rpm contro i 740 rpm massimi che raggiunge il motore a 320V. Mi mette un pò di apprensione il deflussaggio, le librerie che sto usando non hanno nessuna protezione per evitare sovratensioni col deflussaggio, anzi penso che se per un motivo qualsiasi dovesse andare in protezione per sovratensione quando il motore é in deflussaggio il fatto di interrompere la pwm farebbe si di trovarsi con una sovratensione ancora peggiore.

Link al commento
Condividi su altri siti

Sandro Calligaro

Il mio suggerimento, in realtà, andava nella direzione opposta: mettere Id positiva a bassa velocità tende a migliorare il comportamento in controllo sensorless.

Potrebbe essere che il problema che hai nel tarare il controllo di velocità sia dovuto al fatto che magari la banda dell'osservatore è insufficiente. ST dà delle regole per la taratura dell'osservatore, ma quando le avevo guardate non mi avevano convinto. Siccome (se non ricordo male) il controllo è in grandezze "per unit", la taratura analitica è un po' più complicata, ma rimane sempre la possibilità di andare per tentativi "ragionati".

Potresti magari postare un link alla versione delle librerie che stai usando, possibilmente al manuale, così magari diamo un'occhiata e si può pensare a quale parametri provare a cambiare.

 

Riguardo al deflussaggio, invece, hai ragione a preoccuparti, se dovessi perdere il controllo quando la back-EMF effettiva è alta rischieresti una sovra-tensione sul bus.

Generalmente, per stare tranquilli si dovrebbe verificare che la back-EMF concatenata (valore di picco) sia comunque inferiore alla tensione massima che il bus DC può sopportare.

In alcuni casi, l'unica soluzione è un crowbar che, se occorre, mantiene la tensione limitata, dissipando. Purtroppo, di questa cosa si parla poco, anche in letteratura, ma è un problema concreto.

 

 

Link al commento
Condividi su altri siti

7 ore fa, Sandro Calligaro ha scritto:

Il mio suggerimento, in realtà, andava nella direzione opposta: mettere Id positiva a bassa velocità

Si si lo so, solo che il controllo della Id lo si può fare dal workbench della st mentre il motore é in funzione solo quando si controlla solo la coppia senza loop di controllo della velocità, allora visto che mettere la Id positiva senza controllo della velocità non mi sembrava utile ho provato a metterla negativa giusto per vedere se il motore accelerava, una prova che non c'entrava niente con quello che dicevi tu.

Per controllare la Id col controllo di velocità bisogna scrivere nel codice un valore nella Id_ref perché la libreria in modalità controllo di velocità la tiene sempre a zero. Forse di potrebbe fare qualcosa col feedforward che aggiusta le tensioni di comando della pwm ma non ho capito che calcoli faccia.

Proverò a forzare la Id nel codice

8 ore fa, Sandro Calligaro ha scritto:

Potrebbe essere che il problema che hai nel tarare il controllo di velocità sia dovuto al fatto che magari la banda dell'osservatore è insufficiente

Cioè intendi che l'osservatore calcola male la posizione del rotore, generando delle fluttuazioni che poi si ripercuotono sul pid di velocità? Però in questo caso ci sarebbero delle oscillazioni di velocità anche quando si controlla solo la coppia, ma non é così. 

 

8 ore fa, Sandro Calligaro ha scritto:

mettere Id positiva a bassa velocità tende a migliorare il comportamento in controllo sensorless

Anche impostando 600 giri la velocità fluttua tra 740 e 200. Sembra quasi che tutto l'insieme motore cestello abbia un'inerzia esagerata. In effetti il profiler della ST non riesce a calcolare i parametri meccanici del motore, rileva solo quelli elettrici.

 

8 ore fa, Sandro Calligaro ha scritto:

Riguardo al deflussaggio, invece, hai ragione a preoccuparti

Ritornerò sul deflussaggio quando avrò capito tutto il resto

 

8 ore fa, Sandro Calligaro ha scritto:

il controllo è in grandezze "per unit"

Si usa delle unità tutte sue per semplificare i calcoli al processore, soprattutto il tempo ha come unità di misura il clock della pwm e gli angoli sono espressi in 360/65536 

 

8 ore fa, Sandro Calligaro ha scritto:

Potresti magari postare un link alla versione delle librerie che stai usando, possibilmente al manuale

Questo é il manuale più dettagliato che si puo scaricare

https://www.st.com/content/ccc/resource/technical/document/user_manual/group1/48/e6/91/f4/66/ea/48/a1/DM00490980/files/DM00490980.pdf/jcr:content/translations/en.DM00490980.pdf.

Poi c'é quello che si installa con tutto l sdk che esiste in due versioni

senza sorgenti

https://www.st.com/en/embedded-software/x-cube-mcsdk.html#overview

e con sorgenti

https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-mcsdk-ful.html

Link al commento
Condividi su altri siti

Sandro Calligaro
4 ore fa, marcoc4d ha scritto:

Cioè intendi che l'osservatore calcola male la posizione del rotore, generando delle fluttuazioni che poi si ripercuotono sul pid di velocità? Però in questo caso ci sarebbero delle oscillazioni di velocità anche quando si controlla solo la coppia, ma non é così. 

No, non è così semplice... C'è la dinamica dell'anello chiuso, di mezzo.

Prima di tutto, la posizione è relativamente facile da stimare in modo accettabile, la velocità molto meno, perché è la derivata della posizione e quindi più soggetta a rumore.

 

Inoltre, a regime, quasi qualunque set di guadagni dell'osservatore e della PLL ti dà una stime di posizione e velocità che, al di là dell'eventuale rumore, sono corrette.

Dinamicamente, invece, se le variazioni (in particolare della velocità) vengono inseguite troppo lentamente, il controllo di velocità rischia facilmente di oscillare.

Non sto dicendo che sia certamente questo il motivo, potrebbe anche essere il motivo opposto: anche l'osservatore può essere instabile, anche se è relativamente più difficile che succeda.

La cosa è complicata dall'interazione tra i due anelli: se la velocità oscilla, è più difficile stimarne correttamente le variazioni. Se si inseguono male le variazioni, si tende ad oscillare, e via dicendo.

 

Se avrò tempo di guardare di nuovo i manuali della libreria, cercherò di dirti quali parametri modificare.

 

4 ore fa, marcoc4d ha scritto:

Si usa delle unità tutte sue per semplificare i calcoli al processore, soprattutto il tempo ha come unità di misura il clock della pwm e gli angoli sono espressi in 360/65536 

Ma il processore non ha l'unità floating-point?

Link al commento
Condividi su altri siti

Il 6/11/2019 alle 22:39 , Sandro Calligaro ha scritto:

Ma il processore non ha l'unità floating-point?

si! ho fatto la stessa riflessione pure io

Ho provato alzando ki e kp del loop di corrente e le cose sono migliorate molto ma la velocità fluttua ancora a giri bassi, mentre a giri piu alti é quasi perfetto.

Ho provato anche a usare "observer + cordic" al posto di "observer + pll" ma per il momento non funziona per niente, nel senso che dopo l'accelerazione iniziale ad anello aperto quando passa alla FOC si ferma.

Il 6/11/2019 alle 22:39 , Sandro Calligaro ha scritto:

Se avrò tempo di guardare di nuovo i manuali della libreria

Grazie mille

Link al commento
Condividi su altri siti

Sandro Calligaro
10 ore fa, marcoc4d ha scritto:

Ho provato anche a usare "observer + cordic" al posto di "observer + pll" ma per il momento non funziona per niente, nel senso che dopo l'accelerazione iniziale ad anello aperto quando passa alla FOC si ferma.

La PLL è decisamente il modo più classico di ricavare la posizione e la velocità dalle stime di back-EMF (cioè da un seno-coseno dell'angolo).

In pratica, la PLL estrae una versione filtrata della posizione e della velocità, senza però introdurre ritardo a regime sulla posizione, come invece succederebbe con un filtro passa-basso.

 

Il CORDIC è un algoritmo per la rotazione di vettori, usato in questo caso per calcolare l'arcotangente (atan2) a partire da seno e coseno. Di solito, in quel caso il problema è l'estrazione della velocità, che é critica, come dicevo prima.

 

10 ore fa, marcoc4d ha scritto:

Ho provato alzando ki e kp del loop di corrente e le cose sono migliorate molto ma la velocità fluttua ancora a giri bassi, mentre a giri piu alti é quasi perfetto.

Se hai un valore di induttanza e resistenza, si possono calcolare i valori di Kp e Ki per il controllo di corrente, che danno una certa banda.
L'unico problema è sapere esattamente come è implementato il controllore, cioè il vero significato di Kp e Ki (non so perché, ma a volte c'è confusione, qualcuno mischia le carte...) e la scalatura, ma questo dovrebbe essere specificato nel manuale e comunque chiaro leggendo il codice.

 

Io, però, punterei l'attenzione sui guadagni dell'osservatore e della PLL. Se non ricordo male, loro usano l'osservatore di back-EMF classico, che anche io reputo la soluzione migliore (2 guadagni) e la PLL (altri due guadagni, Kp e Ki).

 

PS: ma il codice sorgente è tutto disponibile, o ci sono delle parti già compilate?

 

PPS: avevo guardato (anche per capire cosa avessero sviluppato realmente) questo user manual:
https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-for-motor-control-/pmsm-motor---foc-control.html
Forse non è esattamente la stessa cosa, ma immagino che le soluzioni di controllo siano le stesse.
A suo tempo, quando l'ho letto, avendo lavorato a qualcosa di molto simile, sono rimasto impressionato dal grande lavoro che dovevano aver fatto e reso disponibile a tutti. Tanto per fare un esempio, Texas Instruments ha sviluppato qualcosa di simile, ma lo offre solo come soluzione proprietaria (in una ROM sul microcontrollore, che si paga), senza far conoscere i dettagli degli algoritmi.
Ho anche pensato che avrebbero dovuto valorizzarlo con delle pubblicazioni scientifiche, visto che quello che avevano sviluppato (e sicuramente avevano anche testato) sembrava molto più serio di quello che a volte leggo su riviste considerate prestigiose. Questo l'ho detto recentemente anche a qualcuno di ST Catania (per quanto ne so, sono loro che ci hanno lavorato), speriamo che si decidano, meglio tardi che mai.

Scorrendo di nuovo quel manuale, devo dire che sembra quasi un libro di testo sul controllo motore, spiega anche cose tipo la cancellazione zero-polo nel caso del controllo di corrente. Complimenti a quelli di ST!

 

PPPS: sembra che la libreria sia stata sviluppata sia per fixed- che per floating-point, questo spiegherebbe il motivo della scalatura in per unit (che è la soluzione tipica per il controllo in fixed-point, con varie implementazioni possibili).

 

Modificato: da Sandro Calligaro
Link al commento
Condividi su altri siti

3 ore fa, Sandro Calligaro ha scritto:

Se hai un valore di induttanza e resistenza, si possono calcolare i valori di Kp e Ki per il controllo di corrente, che danno una certa banda

Ora ho capito perché nel workbench c'é la cutoff frequency, io andavo a cercare nel sorgente delle librerie per capire cosa fosse, invece é utilizzato dal workbench stesso per calcolare Ki e Kp del current loop partendo da induttanza e resistenza (calcolati dal profiler).

 

3 ore fa, Sandro Calligaro ha scritto:

Io, però, punterei l'attenzione sui guadagni dell'osservatore e della PLL. Se non ricordo male, loro usano l'osservatore di back-EMF classico, che anche io reputo la soluzione migliore (2 guadagni) e la PLL (altri due guadagni, Kp e Ki).

la loro implementazione ha due guadagni G1, G2 e Pll Ki, Pll Kp. Penso che anche questi parametri siano calcolati dal workbench partendo dal valore di induttanza e resistenza. Si possono comunque modificare manualmente.

3 ore fa, Sandro Calligaro ha scritto:

PS: ma il codice sorgente è tutto disponibile, o ci sono delle parti già compilate?

 Il codice sorgente della libreria é tutto disponibile, l'unica cosa bisogna registrarsi e fare domanda per poterla scaricare nella versione con sorgenti. A me hanno risposto in meno di un'ora per autorizzare a scaricare la versione con sorgenti.

3 ore fa, Sandro Calligaro ha scritto:

PPPS: sembra che la libreria sia stata sviluppata sia per fixed- che per floating-point

I sorgenti che si scaricano mi sembra che siano solo fixed.

Link al commento
Condividi su altri siti

Sandro Calligaro
1 ora fa, marcoc4d ha scritto:

la loro implementazione ha due guadagni G1, G2 e Pll Ki, Pll Kp. Penso che anche questi parametri siano calcolati dal workbench partendo dal valore di induttanza e resistenza. Si possono comunque modificare manualmente.

Sì, è esattamente l'osservatore che uso di solito, e sul quale ho fatto un po' di lavoro a proposito della dinamica. 

Ricordo che a suo tempo la loro formula per la taratura dei guadagni non mi aveva convinto, ma c'era il dubbio sulle scale, che sono particolarmente rognose da trattare nell'osservatore. 

La PLL invece dovrebbe essere un po' più semplice da gestire. 

 

1 ora fa, marcoc4d ha scritto:

sorgenti che si scaricano mi sembra che siano solo fixed.

Sì, intendevo per micro con e senza floating-point unit. 

Qualcuno, per uniformità, se c'è la FPU cambia solo il tipo delle variabili, mantenendo la compatibilità col fixed. 

Link al commento
Condividi su altri siti

Oggi ho provato a riprofilare il motore mettendo una corrente max piu alta di 3.5 A ed il profiler é riuscito a calcolare parametri elettrici e meccanici.

In questo modo il workbench configura automaticamente i vari pid di corrente e velocità, anziché essere configurati a tentativi come facevo prima, però il controllo di velocità é sempre oscillante e il controllo di corrente fa rumore nel motore come se ci fosse della sabbia.

Fino ad ora l'unica soluzione che ho trovato per avere un controllo di velocità rapido e con poche oscillazioni é scrivendo del codice nell'observer per mettere un limite superiore alla velocità rilevata. Penso però che non sia una soluzione "elegante" e non ho idea se ha qualche effetto collaterale che non so.

Link al commento
Condividi su altri siti

Sandro Calligaro
Il 13/11/2019 alle 16:48 , marcoc4d ha scritto:

Oggi ho provato a riprofilare il motore mettendo una corrente max piu alta di 3.5 A ed il profiler é riuscito a calcolare parametri elettrici e meccanici.

Bene!

 

Riguardo al resto dei problemi, è difficile dire dove stia la causa. Io sospetto qualche problema con l'osservatore di posizione e velocità, ma è molto difficile tirare ad indovinare.

 

Ti faccio qualche domanda...

C'è la possibilità di vedere le variabili di controllo (salvando un certo numero di campioni e poi scaricandoli, oppure tramite DAC)?

Quante coppie polari ha il motore (lo avrai già detto, forse)...

 

Il 13/11/2019 alle 16:48 , marcoc4d ha scritto:

il controllo di corrente fa rumore nel motore come se ci fosse della sabbia

Come lo hai testato?

Comunque, la cosa più probabile, se fa un rumore come di "frittura", è che il controllo di corrente sia quasi instabile. Se fosse così, bisognerebbe abbassare i guadagni del controllo di corrente (prevalentemente il proporzionale).

E' facile, se la macchina è molto "tirata" magneticamente (come succede spesso in macchine ad avvolgimento sul dente, specie a rotore esterno), che la saturazione sia secca, cioè l'induttanza vari rapidamente oltrepassando un certo livello di corrente. Si potrebbe fare qualche prova per vedere se è così, ma non è semplicissimo.

Se non si vuole implementare un adattamento dei guadagni (cosa che ti sconsiglio, almeno per ora), meglio abbassarli.

Modificato: da Sandro Calligaro
Link al commento
Condividi su altri siti

18 ore fa, Sandro Calligaro ha scritto:

C'è la possibilità di vedere le variabili di controllo (salvando un certo numero di campioni e poi scaricandoli, oppure tramite DAC)?

Si ci sono due uscite DAC per il debugging, ma non ho capito come funzionano, o meglio penso che sia una tecnica di debugging che non ho mai usato.

Consiste nell'avere un segnale analogico di una variabile numerica? devo fare un tracciato con l'oscilloscopio?

Oppure potrei fare un log delle variabili di controllo, dovrei scrivere un pò di codice ma penso si possa fare.

18 ore fa, Sandro Calligaro ha scritto:

Quante coppie polari ha il motore (lo avrai già detto, forse)...

Sono 24 coppie polari

 

18 ore fa, Sandro Calligaro ha scritto:

Comunque, la cosa più probabile, se fa un rumore come di "frittura", è che il controllo di corrente sia quasi instabile. Se fosse così, bisognerebbe abbassare i guadagni del controllo di corrente (prevalentemente il proporzionale).

avevo notato infatti che abbassando le due Kpd e Kpq il rumore di frittura sparisce.

Tra l'altro mi ero dimenticato di dirlo ho provato ad abilitare il feedforward che mi sembra di aver letto nella documentazione di ST che dovrebbe aumentare la stabilità del controllo di velocità, ma non cambia niente. Anche il feedforward non ho capito cosa faccia, il codice modifica i riferimenti della tensione di pwm calcolati dai pid di corrente basandosi sulla tensione media del bus e sulla velocità del rotore e la corrente di riferimento. In piu utilizza i valori in quadratura per modificare la tensione pwm diretta e viceversa. Mi sfugge proprio il principio.

 

Link al commento
Condividi su altri siti

Sandro Calligaro
20 ore fa, marcoc4d ha scritto:

In piu utilizza i valori in quadratura per modificare la tensione pwm diretta e viceversa. Mi sfugge proprio il principio

Qui ti toccherebbe studiare! 😉

Link al commento
Condividi su altri siti

5 ore fa, Sandro Calligaro ha scritto:

Qui ti toccherebbe studiare! 😉

Ti dico, ho iniziato a studiare, l'argomento mi prende, faccio fatica però, cercando su internet trovo solo articoli accademici, come se fosse un argomento su cui si fa solo della ricerca.

Pensavo di trovare qualcosa di più strutturato forse sbaglio approccio.

Tieni conto che ho fatto elettronica industriale alle superiori e informatica all università quindi ho delle competenze un pò laterali rispetto all'argomento. Magari se mi potessi dare una dritta per indirizzare lo studio 😊...

Link al commento
Condividi su altri siti

Sandro Calligaro
Il 15/11/2019 alle 17:16 , marcoc4d ha scritto:

Si ci sono due uscite DAC per il debugging, ma non ho capito come funzionano, o meglio penso che sia una tecnica di debugging che non ho mai usato.

Consiste nell'avere un segnale analogico di una variabile numerica? devo fare un tracciato con l'oscilloscopio?

Oppure potrei fare un log delle variabili di controllo, dovrei scrivere un pò di codice ma penso si possa fare.

Tutte e due le opzioni sono utili, sia quella di usare il DAC per "far uscire" l'andamento di due variabili, sia quella di salvare i campioni in un vettore, per poi scaricarli e visualizzarli sul PC.

E' molto importante, direi essenziale avere questa possibilità, perché altrimenti è quasi impossibile fare debugging del controllo.

Non si tratta di correggere bug del software (potrebbe essere perfetto), ma di aggiustare i valori di parametri e/o capire se qualcosa nel sistema fisico non funziona correttamente.

 

Il 16/11/2019 alle 19:08 , marcoc4d ha scritto:

Pensavo di trovare qualcosa di più strutturato forse sbaglio approccio.

Purtroppo è vero, si trovano cose poco precise oppure cose troppo specifiche.

Le dispense di corsi universitari sono buona una possibilità, alcune tesi sono anche una buona alternativa (trovi facilmente anche la mia di dottorato, ma non so se faccia al caso tuo), perché di solito introducono le basi del modello del motore e lo schema di controllo.

Altrimenti, ci sono le application note dei produttori di microcontrollori, come Texas, ST, Renesas e Freescale.

https://www.renesas.com/cn/zh/doc/products/mpumcu/apn/rx/002/r01an3786ej0102-motor.pdf

http://www.ti.com/lit/an/spracf3/spracf3.pdf

http://www.ti.com/lit/an/sprabq2/sprabq2.pdf

http://www.ti.com/lit/an/sprabz0/sprabz0.pdf

http://read.pudn.com/downloads401/sourcecode/embedded/1713870/HVPM_Sensorless/~Docs/Sensorless FOC of PMSM.pdf

 

http://www.ti.com/lit/an/spra494/spra494.pdf

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=2ahUKEwibgbHZwvPlAhUpMewKHSelAisQFjABegQIBBAC&url=https%3A%2F%2Fwww.eeweb.com%2Fapp-notes%2Fdownload%2F2066&usg=AOvVaw3KN9SZeotQ9h5QOAl20eUd

 

https://training.ti.com/field-oriented-control-permanent-magnet-motors

 

Il primo link spiega la questione dei disaccoppiamenti degli assi (l'incrocio dei due percorsi d e q), quella di cui ti chiedevi il senso... Gli altri mi pare che lo trascurino, ma non ho guardato così bene.

Uno dei problemi che si incontrano maggiormente è la notazione. Ad esempio, sempre nel primo link, non fanno vedere la trasformazione di Clarke (abc->alpha,beta) e usano "p" per l'operatore di derivata...

Modificato: da Sandro Calligaro
Link al commento
Condividi su altri siti

Crea un account o accedi per commentare

Devi essere un utente per poter lasciare un commento

Crea un account

Registrati per un nuovo account nella nostra comunità. è facile!

Registra un nuovo account

Accedi

Hai già un account? Accedi qui.

Accedi ora

×
×
  • Crea nuovo/a...