MECCANICA e DINTORNI

la macchina per i fulmini mi pare che max gia' l'abbia fatta...

1.21 Gigawatt?!! Come posso essere stato così sventato? 1.21 Gigawatt! Non si può fare, vero Copernico?

Come non si può fare ??? Tutto si può fare bit !! Ci metti 1200 IRFP460 in parallelo e vai di fulmini... quelli seri però, mica i miei !!!!!

Grazie a tutti per le offerte di collaborazione... molto apprezzate in particolare le salsicce di Dasama !
Iniziamo con il primo passo, la scheda micro.
L'ho già realizzata:

... e accesa :


E già che ci sono vi pubblico anche il progettino così chi mi vuole aiutare se la può iniziare a fare... mi raccomando non intasate il server a furia di scaricarla....


La scheda somiglia molto alla Micro HMI della saldatirce con la differenza che qui utilizzo un display LCD 20x4 e gli I/O sono configurati un po diversamente. Per la programmazione del micro ho adottato l'interfaccia ICSP standard con connettore RJ... come al solito nel pacchetto trovare lo schema di montaggio con tutti i riferimenti.

Da qui vorrei partire per scrivere il codice sperando di riuscire a farcela con le risorse del micro. La gestione dello STEP/DIR sincronizzato con l'ingresso encoder del mandrino mentre il micro calcola il PWM per il motore non è semplicissima; non è escluso che ci si trovi costretti a cambiare il micro in corsa a favore di uno più potente.

Domani vediamo di iniziare ad intavolare il discorso su come funziona la modulazione del PWM in modalità "space vector".... soprattutto per te Bit, visto che la dovrai implementare in assembler !!!

gia mi sono perso....

siamo in due , per me lo fanno apposta , parlano in padano e ci escludono

Il micro è più che sufficiente per fare quello che vuoi fare, basta utilizzarlo correttamente. Te l'ho detto, la programmazione in C non è adatta ad una applicazione del genere.
Se a te fa piacere mi unisco al progetto e ti sviluppo il software in asm, vedrai che uscirà un software lineare e chiaro, e più semplice che in C.
Per esercitarti in C (lo sto facendo anche io) meglio sviluppare roba per PC.

Dimmi tu, non voglio fare l'invadente...

McMax,
ho trovato il problema! cosa? come sarebbe problemi non ci sono?
nella prima foto (0070).. le formiche blu a destra sono fuori allineamento
con quelli a sinistra. la destra e sempre problematico lo so.

poi, vicino a quel scarafaggio grande al centro, c'e un componente scomparso -
lasciando in dietro soltanto l'ombra. credo sia colpa delle altre formiche blu.

di non parlare del LED spento.. dai sappiamo tutto che i LED devono essere accessi.
.. altrimenti perche usarli???

spero solo che il mio aiuto sara apprezzato. solo questo.

in img_0069 bel lavoro!!
(che versione di photoshop usa?)

Tony

Eccome se accetto la tua offerta di collaborazione Bit !! Ben vengano offerta come la tua di SMAZZARSI tutto il firmware !!!
Tanto io prima devo sistemare la primary e far funzionare la Mc Raban poi posso dedicarmi a questo. Tu puoi iniziare col SW intanto

Pensavo di farlo con varie opzioni in modo da poterlo utilizzare sia come inverter standard che con la semplice funzione di lettura dell'encoder (motore o mandrino, magari selezionabile, con funzione closed loop) che con anche il driver per la ELS tramite STEP/DIR.
In pratica:

Inverter standard ==> open loop senza lettura encoder
L'ingresso QEA/QEB/INDEX non viene utilizzato ed il motore gira senza vincoli solo sulla base della frequenza che impostiamo. Utilizziamo l'ingresso corrente (analogico) ed eventualemnte quello tensione (sempre ananlogico) per determinare eventuali condizioni di allarme. C'è comunque un ingresso FAULT optoisolato direttamente sull'apposito pin di Fault A del PIC sul quale possiamo intervenire con un allarme istantaneo determinato da circuiteria esterna.

Inverter closed loop ==> encoder velocità sul motore(diretto) o sul mandrino(indiretto)
L'ingresso QEA/QEB/INDEX viene utilizzato per leggere la velocità di rotazione del motore e determinare la correzzione d'errore per eliminare lo scorrimento e mantenere il regime di rotazione impostato indipendentemente dal carico. Qui eventualmente possiamo perevedere una doppia opzione e montare l'encoder direttamente sul mandrino; nel caso andrà prevista via software l'impostazione del rapporto di trasmissione in modo che il sistema sia in grado di regolare la velocità direttamente sul mandrino indipentemente dal rapporto di riduzione che stiamo utilizzano.
Per il resto restano valide le funzioni ed i controlli della versione precedente

Inverter + ELS==> encoder velocità sul mandrino
con questa opzione l'encoder QEA/QEB/INDEX non viene più utilizzato per regolare la velocità ma solo per il riferimento angolare che genera il passo per la vite madre. L'ho pensata così in quanto vedo la regolazione delle due cose contemporaneamente abbastanza impegnativa.... se poi abbiamo risorse e riusciamo a fare tutto ben venga!
Qui l'encoder deve essere PER FORZA sul mandrino e tramite l'uscita STEP/DIR si dovrà emulare il vincolo meccanico tra mandrino e vite, ovviamente con il passo impostabile via software.
Questa dovrà essere disponibile indipendentemente dal fatto che l'inverter stia alimentando o meno il motore.... in pratica vorrei che, una volta attivata l'opzione, il mandrino fosse "fisicamente" vincolato alla vite e la muova anche se questo veine girato a mano. Nel software potremmo ad esempio prevedere una funzione vincola/svincola indipendente dalla funzione inverter.

Questo a grandi linee. Poi iniziamo a parlare più specificatamente di SVM.

Che ne pensate ?

Ok max... intanto preparo un software di diagnostica per testare tutte le periferiche.

Per le funzioni le deciciamo via via... sarebbe buono arrivare a fare un controllo vettoriale (ma mi devi trovare gli algoritmi...), nel caso dell'anello chiuso ha prestazioni migliori.

PS: un cicchetto te lo devo fare anche io... coma cavolo hai collegato i pin del bus dati del display? Maledetto te... li hai collegati invertiti!!!

Li hai messi:
DB7 - RC0
DB6 - RC1
DB5 - RC2
DB4 - RC3

Perchè vuoi fare giri di dati a questa maniera??
Andavano messi:
DB7 - RC3
DB6 - RC2
DB5 - RC1
DB4 - RC0

Vabbè... questo comporterà un degrado dello 0.00001% delle prestazioni dell'inverter... cominciamo bene...

Bit , secondo me non ha senso smazzarsi a scrivere codice in ASM per cose che richiedono prestazioni elevate, meglio usare il C.
Per le routine di retroazione , calcolo , ecc invece li meglio usare ASM.
Che tra l'altro era una cosa che volevamo fare anche per la MCRABAN (LA REGINA DELLE TENEBRE) , pero' non abbiamo capito come
inserire routins in ASM dentro a un programma scritto in C , in particolare non abbiamo capito come avviene la gestione della memoria riservata alle variabili , siano esse globali o locali , se tu ne sai qualcosa ....

lascia stare va. La pinout l'ho fatta così perchè ho sempre il vizio di voler attaccare il display al connettore direttamente, senza cablare. Solo che quando ho fatto lo schema si vede che era tardi e non so che pinout ho visto.... ero convinto che fose speculare a quella del display salvo accorgermi che non lo era solo dopo aver attaccato il display e tirato svariati porconi perchè non andava !!!
Ho fatto quindi il cavo e collegato il display correttamente solo che ormai il PCB è fatto... ad averlo saputo prima, cablaggio per cablaggio, li avrei messi meglio e soprattutto senza fare i salti mortali li sotto con le alimentazioni e il backlight.

L'algoritmo SVM ce l'ho.. o comunque l'ho capito....
Intanto puoi guardare questa AN di microchip dove tra l'altro il fw è già scritto in assembler: http://www.microchip.com/stellent/idcpl ... e=en022555

Negativo raban... tutto in asm. Quando vuoi provare a vedere come si fa prima sono qua.
Inoltre è proprio per le prestazioni elevate che devi usare l'assembler, più veloce e ottimizzato.

Variabili globali? Variabili locali? Formato variabili? Il pic mica supporta queste cose, sono solo seghe del compilatore C. Il pic ha una ram, tutte le locazioni sono da 8 bit... basta. Solo un tipo di valore: intero da 0 a 255. Sei tu nel programma che gli dai un significato. Lunguaggio di programmazione essenziale, poche istruzioni e sempre quelle, minima probabilità di errore di sintassi. Se vuoi usare una cosa devi sapere come funziona... completamente, altrimenti non la usi.

Bit c'era un errore nel mio messaggio :

Usare il C per codice lento , usare ASM per le routine veloci .

Già meglio raban.

Ma ti dico, io ho una preparazione elettronica, quindi arrivo dal basso e so come funziona un micro (non un pic, un microp in generale, sono tutti simili). Io trovo estremamente più semplice scrivere in asm. Anche se servono routine complesse, queste saranno di esecuzione chiarissima, e una volta fatte sono pronte per altri utilizzi certo che sarà sempre in grado di modificarle e debuggarle.
Con linguaggi elevati mi devo sempre stare a cercare cosa fanno i vari comandi, capirli... capire quando non vanno cosa c'è... una rottura immesa.

Se vuoi arrabattare qualcosa puoi anche scrivere in C, e saprai che il tuo codice nn sarà mai perfetto. Se vuoi utilizzare a pieno un processore, con un programma veloce, lineare, snello, armonioso (anche per l'esecuzione da parte del processore, non solo per come appare una volta scritto), devi scrivere nel linguaggio che parla lui. In un PIC16 sono 35 istruzioni (in un PIC18 sono di più ma si tratta per lo più di varianti della stessa istruzione). Cosa c'è di difficile da usare?
Vuoi il C perchè qualcuno ha già scritto la routine per gestire un display LCD? Quindi non te ne frega una mazza di come il pic dialoga col display? Guarda che è una cagata, l'avevamo pure studiato a scuola. Le routine sono due blocchi da una ventina di istruzioni, e vedi bene quello che fanno.

Ovvio che i linguaggi elevati li devo usare quando sviluppo roba per PC... e ogni tanto c'è da smoccolare (spesso).

Un progetto perche' sia valido deve avere 3 caratteristiche :

deve essere buono
deve essere veloce da realizzare
deve costare poco

Nel caso di parti di codice che non hanno particolari esigenze prestazionali e' ovvio che scrivere 2 righe in C comporta meno tempo che scrivere centinaia di righe in asm ed e' quindi piu' economico.

Questo da un punto di vista prettamente economico/manageriale .

E chiaro che se a livello hobbistico uno dice " no scrivo tutto in asm perche' voglio che la routine usi un nanosecondo invece che 2 nanonosecondi " bhe' e' libero di farlo, senza critiche e senza polemiche , ma
il mio punto di vista e' diverso .