Appunti da e per chi si vuole auto-costruire un posizionatore

[antgue]

P.S.: su datasheetarchivepuntocom, fai ricerca IRFZ44... ottimo MOSFET in TO220, canale N (equivalete all'NPN del transistor) e costa poco

 

[antgue]

Man mano che trovo qualche minuto aggiungo qualcosa:
pregi del MOSFET utilizzato come commutatore rispetto al transistor:
- Minore tensione di saturazione (transistor 0.2-1.5V, mosfet = Rds-on * Idrain = poche centinaia di millivolt alla max corrente)
- Minore potenza dissipata in conseguenza della minore tensione di saturazione
- Maggiore velocità di commutazione (opportunamente pilotato)
- Nessun assorbimento di corrente per il pilotaggio (escludendo i transienti)


se mi verrà in mente altro lo aggiungerò modificando il post

 

[pm.astra2dve]

IN questo periodo in cui non sto postando nulla è semplicemente perchè io e antgue abbiamo unito le forze, lui schema e io costruzione e sto provando la V2.0 dello stadio finale (dopo aver bruciato già 3 mosfet ), quando funzionerà posterlò le foto .

 

[pm.astra2dve]

Bene siete pronti per la prima foto dell'insieme in fase di prova?



In basso il motore H-H, in alto a destra il tavolino con il circuito di controllo e l'amperometro di rilevazione del consumo del motore , ovviamente i collegamenti sul circuito sono volanti perchè non ho ancora preparato i 2 radiatori laterali dei finali dove poi attaccherò anche gli stabilizzatori a 5 e 12V e i ponti raddrizzatori di potenza . Sulla basetta sperimentale troviamo un rudimentale circuito di accensione e controllo. Infatti ho progettato il tutto in modo che possa essere tenuto in standby senza consumare una follia: l'unico componente che rimane sempre acceso è il PIC (5VSB), che quando premo il tasto ON davanti o sul telecomando fa scattare 2 relè a 2 scambi: uno collega il secondario di potenza del trasformatore (quello per i 36V) al ponte raddrizzatore, l'altro collega i 5 e 12V alle morsettiere di uscita, delle quali 2 dedicate all'elettronica interna e 2 all'elettronica esterna (sensore ottico, reed eccetera), queste ultime dotate naturalmente di fusibili . Con questo accorgimento il consumo del posizionatore quando è spento dovrebbe assestarsi sui 10-15 mA al massimo tenendo conto di un paio di LED spia e il processore a 20 MHz che deve sempre rimanere in attesa di un comando, a 5V ciò significa 100 mW a farla grande, diciamo che è abbastanza "green"

Ma veniamo ai sensori: il motore H-H è reed, collegando una resistenza da 100K ai 5V e facendogli cortocircuitare a massa questa resistenza sull'uscita rilevo con l'oscilloscopio un'onda quadra molto pulita che sarebbe già idonea a pilotare il contatore o il micro, il problema sorge con il pistone EL che è ottico: il segnale in uscita è una sequenza di rampe di tensione (onda a dente di sega) la cui ampiezza non supera 50 mV (segnale a basso differenziale), per renderlo uP compatibile lo devo preamplificare e squadrare, inoltre un segnale così debole è più suscettibile ai disturbi esterni... Ma non potevano fare un circuito meno ostico?

 

[antgue]

Ma veniamo ai sensori: il motore H-H è reed, collegando una resistenza da 100K ai 5V e facendogli cortocircuitare a massa questa resistenza sull'uscita rilevo con l'oscilloscopio un'onda quadra molto pulita che sarebbe già idonea a pilotare il contatore o il micro, il problema sorge con il pistone EL che è ottico: il segnale in uscita è una sequenza di rampe di tensione (onda a dente di sega) la cui ampiezza non supera 50 mV (segnale a basso differenziale), per renderlo uP compatibile lo devo preamplificare e squadrare, inoltre un segnale così debole è più suscettibile ai disturbi esterni... Ma non potevano fare un circuito meno ostico?

Prova metti una 1K di pull-up a +5V e quel segnale a dente di sega dovrebbe diventare molto piu ampio, tipo quadra con fronti molto rallentati da un condensatore in uscita piuttosto pesante, che la 100K non riesie mai a caricare
Fanno così per essere sicuri di eliminare le commutazioni multiple al passaggio da uno stato all'altro

 

[pm.astra2dve]

Bene scusate l'ora ma domani è domenica

Lo stadio finale a mosfet progettato da Antgue e da me costruito è molto robusto, merito del sovradimensionamento dei finali (mosfet N da 14A, P da 12 contro 4 di picco del motore... ) e dei diodi soppressori altrettanto sovradimensionati: BYW80 da 10A e molto più veloci (40 ns) del minimo richiesto (120 ns) ...
Ora ho iniziato a sviluppare il programma di gestione del tutto che viene poi caricato nel PIC, per il momento uso i 16F876 recuperati da scuola ma non è escluso che passi al 16F877 pieno di I/O .
Ma veniamo a noi: per le prime prove ho collegato 2 bit della porta C (PC6 e PC7) a un 4011 configurato come doppio buffer (NOT-NOT), tanto perchè sono sempre guardingo e se mi capita qualcosa allo stadio pilota mi si brucia un 4011 che costa decisamente meno di un PIC . Alla PC3 ho attaccato un LED spia gestito via software, a PB0/INT l'ingresso dal sensore reed del motore H-H con un pull-up da 47K (quindi il reed cortocircuita a massa il pull-up), per finire a PB4 e PB7 ho collegato un deviatore con 0 centrale e autoritorno (in pratica funziona come un pulsante con 0 centrale in deviazione basculante), sempre con 47K di pull-up (quindi attivo basso).
P.U.T. e B.O.R. attivati, piccola rete RC sulla linea di Reset (47K e 1 µF) per ritardare l'avvio a tensione stabilizzata ; non ho subito messo il quarzo da 20 MHz, intanto ho provato con il clock più diffuso per i PIC (4 MHz).

Dopo varie prove e tentativi senza motore collegato (usando il LED e l'oscilloscopio), ho sviluppato già qualche blocco funzionale del software, in particolare ho implementato i controlli di movimento manuale con una protezione:
A comando ricevuto il PIC dà tensione al motore e utilizza il trigger su PB0/INT per rilevare gli impulsi dal sensore reed, al primo fronte di salita (o di discesa, è impostabile ), quindi quando il motore ha fatto un passo, lo arresta e controlla se sto ancora premendo il pulsante, dopo un tempo impostabile a piacere passa al movimento continuo facendo girare il motore finchè non rilascio il pulsante, a pulsante rilasciato naturalmente si ferma in fase all'arrivo del prossimo trigger ; la prima forma di protezione o allarme che ho implementato è quella se si scollega il cavo del sensore reed: dopo aver avviato il motore il micro resta in attesa di ricevere l'impulso dal reed, se entro un certo tempo (sempre prefissabile a piacere) non ha ricevuto nulla arresta il motore e avvisa dell'allarme . Quando avrò riportato anche il segnale di corrente al micro aggiungerò il controllo sulla corrente, accendi poi controlla se gira (consuma corrente), quindi attendi gli impulsi reed; se non gira allarme cavo potenza scollegato (o fusibile saltato), se gira ma non arriva reed allarme cavo segnale staccato (o reed bruciato) , naturalmente poi si aggiungeranno i limiti. Tanto ho visto che già a 4 MHz la velocità è ampiamente sufficiente .

Mi sa che verrà fuori un programma bello corposo ma anche molto raffinato .

P.S. con il movimento step ho fatto la prova dello stadio finale con corrente impulsiva, visto che uno step equivale a 1/4 di giro del dischetto magnetizzato e a pochissimo del perno, già così è DECISAMENTE più preciso di uno Stab , aggiungendo 2 monostabili posso anche raddoppiare la precisione a 1/8 di giro , si può raddoppiare anche via software ma mi complico la vita (dovendo lavorare a trigger alternato )

 

[pm.astra2dve]

v2.0

Bene ora diciamo che ho messo in piedi un circuito sperimentale un po' più presentabile (nel senso che non comunica solo con il lampeggio di un LED) e più raffinato .

Vista d'insieme


Il motore appoggiato per terra collegato con un cavo telefonico a 3 coppie


La scheda principale (manca il secondo stadio di potenza )


La scheda sperimentale di comando, il deviatore a sinistra accende o spegne lo stadio di potenza, il deviatore-pulsante al centro è il controllo E-W manuale


Il display a matrice di punti 16x2 recuperato da scuola che visualizza qualche info utile, "Ready" compare solo se il micro ha completato la sequenza di accensione, a destra c'è lo stato dello stadio di potenza (rileva il deviatore)


Quando fornisco i 36-40V allo stadio di potenza, oltre ad accendersi il voltmetro a sinistra del tavolino si accende anche la retroilluminazione del display, che non è a LED ma di tipo EL, per accenderla ho utilizzato un piccolo inverter prelevato da una striscia rossa decorativa per modding PC , bel colore...


Nella seconda riga compare una barra verticale ("|") quando il motore è fermo, "<" o ">" quando lo faccio ruotare a passi, "<<" o ">>" quando lo faccio girare continuo. Il comando è a doppia modalità: premendo fa un passo; continuando a tenere premuto per più di 2 secondi circa il motore inizia a girare e quando lascio il pulsante si ferma in fase, cioè al primo fronte di discesa del segnale reed; rilasciando prima dei 2 secondi non fa altro . C'è un LED spia verde che mi indica se il PIC ha ricevuto gli impulsi dal reed (ogni impulso si accende). Ho già implementato un controllo di sicurezza in tutte le fasi della gestione del movimento: quello se si scollega il sensore reed, attivo sia nel movimento a passi, sia nel movimento continuo, sia nell'arresto: se per un periodo di tempo (impostabile) il PIC non rileva il segnale dal sensore, arresta il motore, visualizza "ERR" sul display e fa lampeggiare il LED verde 8 volte (il LED è retaggio del vecchio circuito che non aveva il display ). Ho notato controllando i movimenti del dischetto magnetizzato, che anche senza giostrare il segnale di sincronismo (reed) invertendolo al cambio di direzione, la precisione è più che sufficiente, ±1/2 step elettronicamente, meccanicamente l'inerzia della trasmissione (anche autofrenata) ha un errore maggiore .
Il sistema prende forma... modificando i microswitch dei limiti e riportando la tensione sulla resistenza di caduta corazzata le protezioni sono complete: sequenza c'è limite?-accendi-c'è corrente?-c'è segnale reed?. Volendo il PIC ha un A/D interno a 10 bit, si può campionare il valore della corrente assorbita dal motore e visualizzarlo...

P.S. per il progetto definitivo ho in mente di rimediare un display con i caratteri meno microscopici, per essere leggibile anche da media distanza (divano ), e forse anche più grande: almeno 20x2, ma magari anche un bel 20x4. Mi era balenata l'idea di usare un display grafico da 160x160 punti, ma dovendolo gestire interamente dal PIC sarei impazzito .

 

[intruder800]

gran lavoro ma hai pensato anche al mobile che ospitera il tutto? tanto che ci sei...........come display potresti usare un tv o il tv tramite il decoder

 

[antgue]

Ciao Intruder... non è possibile utilizzare il TV in quanto il micro utilizzato non ha la possibilità di gestire l'OSD su un segnale video.
Gli LCD citati si comandano con 6 linee I/O del micro... 4 bit dati + i linea comando/dato (RS) e una linea di enable (EN)

 

[intruder800]

Ciao Intruder... non è possibile utilizzare il TV in quanto il micro utilizzato non ha la possibilità di gestire l'OSD su un segnale video.
Gli LCD citati si comandano con 6 linee I/O del micro... 4 bit dati + i linea comando/dato (RS) e una linea di enable (EN)

ciao antgue era una battuta(quasi)

 

[antgue]

Ops... scusami se non avevo colto il senso ironico

 

[Maxicono]

Ops... scusami se non avevo colto il senso ironico

a onor del vero con il PIC ci hanno fatto anche due videogames da TV, il tetris ed il ping pong. Unico componente attivo utilizzato, il PIC16C84!

 

[antgue]

Hai ragione ... non ricordo che pic però... gli facevano generare il segnale video, molto piu complesso che scrivere su un display
E poi noi facciamo un gioco... non un videogiogo

 

[pm.astra2dve]

Se vuoi farti del male puoi provare a generare un segnale videocomposito (in bianco e nero, sempre che non voglia ammazzarti a gestire anche la sottoportante colore in QAM ). Altrimenti generi solo i segnali di sincronismo e tramite 3 convertitori D/A a rete a scala R-2R a 8 bit (collegati alle porte I/O di un PIC con un po' di I/O o a 5 linee del PIC tramite 3 registri shift-and-store 4094 ) puoi generare un segnale RGBS a 16 milioni di colori che poi puoi buttare dentro a un modulatore videocomposito. Integrati un po' vecchiotti ma che per certe applicazioni sono ancora validi . Altrimenti ci dovrebbero essere i chip moderni che entrando con un segnale (anche digitale) di qualche tipo fanno l'OSD .
P.S. per gestire il segnale video con un PIC 4 MHz di clock non credo siano sufficienti, il segnale video ha una banda di 5.5 MHz e se non vuoi trovarti con i cicli macchina alla gola meglio 8-10 MHz (o 20 ) perchè devi gestire il sincronismo di riga (15625), quello di quadro (25), quello di interlacciamento (50)... Con una memoria VRAM esterna di adeguata capacità basta iterare 720 colonne per 576 righe per 50 volte alternate (prima pari poi dispari) al secondo la lettura di un byte (256 grigi o 256 colori tramite tavolozza), 2 byte (65536 colori, 5 bit per canale), o 3 byte (24 bit, 8 bit per canale). La visualizzazione a video in PAL avviene una riga alla volta, quindi per ogni riga 720 punti poi la prossima . Se ti ci metti con impegno raggiungi qualsiasi risultato (cit. ).

Tornando a noi, credo che per ora continuerò a sviluppare in PIC Assembler, dato che lo conosco come le mie tasche. La memoria programma dei PIC16F87x (ho giusto trovato un 16F877A a 40 pin con 33 I/O ) tiene 8K parole e la programmazione in alto livello non permette un controllo minuzioso sull'overhead di gestione del programma stesso. Ad esempio in PBP utilizzare l'interrupt via software (ON INTERRUPT) è comodo dal punto di vista della stesura del programma perchè non devi unire blocchi ad alto livello con pezzi Assembler, ma nelle parti dove è richiesto l'interrupt handling il 50% delle istruzioni servono solo per controllare se è arrivato un interrupt, praticamente ti si dimezza la velocità operativa... . Certo se devi stampare papiri sui display alfanumerici (o disegnare una foto sul display grafico ) è più "bello" e "carino" fare una sola PRINT con una stringa lunga un chilometro , ma visto che io userò sì e no il 10% della memoria RAM utente di un PIC16F876/877, ottengo lo stesso risultato con meno impegno di risorse (preziosissime) di sistema allocando tutto lo spazio utente disponibile in pagina 3 (100 e rotti caratteri eh...) come "memoria video", all'avviamento mi precarico iterativamente le stringhe predefinite che userò (la EEPROM mi serve per le memorie del motore ) e quando me ne serve una mi basta una sola chiamata alla subroutine relativa che autonomamente si occuperà di piazzare il cursore dove serve e iterare la stampa di tutti i caratteri . La funzione di lettura automatica di un pulsante (BUTTON) con eliminazione delle spurie e il typematic fa comodo se il programma non è troppo complicato, perchè per come è stata strutturata, a meno di impazzire con i salti condizionati e blocchi IF-THEN-ELSE (usando 3-4 registri come variabili d'ambiente), non posso far fare due lavori diversi a seconda che prema il pulsante e lo lasci o lo tenga premuto (typematic); in Assembler basta una subroutine di ritardo (che comunque avevo già per il display, 10 righe ) e con altre 12-15 istruzioni fai quel che vuoi . I controlli su tutte le condizioni possibili d'errore (motore non gira, limite raggiunto, microswitch guasto, reed non segnala eccetera) basta farli nell'ordine giusto, quando serve (di continuo se sto muovendo il motore) e con i giusti salti: il PIC è RISC, l'unico salto condizionato che può fare è saltare l'istruzione successiva a quella di controllo, si mettono tutte le condizioni d'errore alla fine, se nella subroutine devo gestire più movimenti metto per ogni movimento il blocco controllo errori e se in un punto qualsiasi della procedura si verifica un errore basta saltare sempre alla stessa posizione che si preuccuperà di gestire l'errore . Supporta fino a 6 livelli di nidificazione delle subroutine (lo stack sarebbe da 8 ma uno è riservato all'interrupt e uno lo si tiene sempre libero ) quindi si può fare un moderato riciclaggio del codice snellendo ancora di più il programma . Non so quanto riciclaggio fa il linguaggio ad alto livello, ho paura non troppo... Antgue tu continua pure a sviluppare in PBP, è ottimo per chi inizia da zero o per chi non è avvezzo a ragionare a bit, byte e indirizzi (io venendo anche da 2 anni di programmazione Assembler x86 ero facilitato ), se dovessi cominciare a programmare lo proverei anche io. Altrimenti c'è sempre la programmazione in C adattato, naturalmente il C non è facile come il Basic ma è sicuramente più raffinato e tosto; anche qui se volessi imparare sarei un pochino facilitato perchè conosco un po' di PHP (un C semplificato)... P.S. il PBP prende a prestito qualche sintassi non solo dal mitico Basic, ma anche da C, Java e Pascal, tipo quando devo specificare un bit di un registro e scrivo PORTB.5 come in Java per OGGETTO.VALORE, i "modificatori" delle istruzioni per riformattare il risultato tipici del C, o le DECLARE, che sono le #DEFINE del C , la REPEAT-UNTIL identica al Pascal...

Vabbè vi lascio per ora...

 

[pm.astra2dve]

telecomando più o meno pronto

Dunque visto che devo ancora montare lo stadio finale numero 2 e anche prelevare i limit switch per il PIC, stasera mi sono dedicato alla simulazione dell'altro programma che serve per questo posizionatore: il telecomando

La simulazione l'ho fatta con 8 pulsanti, il solito PIC16F876 a 4 MHz e 8 LED bianchi ad alta luminosità che mi capitavano a tiro...


Premendo un tasto emetto un certo codice esadecimale ogni 100 millisecondi (tempo impostabile a piacere)...


Ma al contempo utilizzando il ricetrasmettitore seriale asincrono (USART) integrato nel PIC trasmetto lo stesso codice sulla linea PC6/TX in modalità 8-N-1, la trasmissione è gestita autonomamente dal micro che dopo aver dato lo start transmission al modulo USART si libera subito


Ho scelto all'accensione di non attivare subito il trasmettitore e metterlo in attesa del byte da trasmettere, bensì accenderlo solo prima di trasmettere il byte e spegnerlo subito dopo, sia per ridurre i consumi, sia per mantenere sempre in fase la trasmissione (il trasmettitore ha un suo registro contatore interno per la generazione del tempo di simbolo, e a ogni accensione viene azzerato ripartendo sempre dallo stesso punto ). Questo richiede di collegare una resistenza di pull-up da 10K sul piedino PC6 perchè quando il trasmettitore è spento l'uscita è tenuta in alta impedenza, dato che quello è il piedino che tramite un transistor piloterà i diodi emittenti all'infrarosso (o volendo il modulo trasmittente a 433.92 MHz), non va molto bene che lo stato sia indefinito... .

Per la lettura dei tasti ho utilizzato il classico metodo a matrice, organizzandoli in 2 righe per 4 colonne; il micro attiva una riga e legge in sequenza le 4 colonne per controllare se un tasto è premuto, poi attiva la seconda linea e riprende dall'inizio e così via . Per quanto riguarda la leggerezza del programma e il riciclaggio del codice, non ho utilizzato 8 subroutine diverse per 8 tasti, la subroutine è sempre la stessa e io in base al tasto che ho premuto passo come parametro il codice che voglio trasmettere . A 4 MHz di clock, il controllo di un tasto richiede la bellezza lol di 2 microsecondi, se è premuto a questi si aggiungono altri 2 microsecondi per passare il parametro e poi il tempo della subroutine di trasmissione, che può durare a piacere in base alla velocità a cui voglio trasmettere il byte (9.6 o 19.2 kbps), se lo voglio trasmettere con parità o senza, ogni quanti millisecondi voglio che avvenga la ritrasmissione se tengo premuto il tasto eccetera .

Utilizzando un PIC16F876 che togliendo i 2 pin necessari all'USART offre 20 linee di I/O posso organizzare una matrice 10x10 e indirizzare un massimo di 100 pulsanti, aggiungendo 2 registri a scorrimento 4094 in cascata, collegati ad esempio a PA<0,1,2> e utilizzando PB<0:7>, PC<0:5> e PA<3,5> per le colonne posso raggiungere la massima capacità gestibile con un codice a 8 bit, cioè 256 pulsanti

Visto che immagino già un telecomando con 100 tasti sia di dubbia utilità posso usare PC<0:5> per le righe della matrice e PB<7:4> per le colonne in configurazione 6x4 e gestire max 24 pulsanti, al momento:
- Power On/Off
- Cifre da 0 a 9
- Store
- Recall
- Step/Move Est
- Step/Move Ovest
- Step/Move Up (EL)
- Step/Move Down (EL)
- Resync Positions
- Recalibrate H-H
- Recalibrate EL
Altri 4 tasti liberi...

Consumi: a 4 MHz in standby (nessun tasto premuto) il telecomando consuma 1.4 mA circa, che in trasmissione dipendono ovviamente da quanta potenza voglio dar dentro ai diodi trasmittenti. Giostrando con 12 diodi 1N4148 posso fare in modo che in standby il micro vada in Sleep consumando praticamente nulla (2 µA...), e venga risvegliato dall'interrupt su PB<7:4> (c'era un motivo se avevo scelto quei piedini no? ) premendo un tasto qualunque, poi torni in SLEEP.

 

[antgue]

In genere uso il compilatore Basic PBP per questione di tempo e visto che non faccio progetti complessi me la cavo con poche righe di programma basic (che comunque dovendole fare in ASM sarebbero parecchie pagine)... quando devo usare interrupt o ho a che fare con segnali brevi vado pure io con l'assembler anche se ormai sono giu di allenamento... tempo fa avevo utilizzato dei micro della SGS-Thomson tipo ST6, e di questi non avevo nessun compilatore, erano molto piu lenti e in piu non erano flash ma avevano la finestrina per la cancellazione della eprom interna... quindi bisognava averne 2 o 3, e intando che ne provi uno gli altri li si mettevano in cancellazione ad abbronzare... altri tempi ormai

Riguardo al progettino... perchè non usi qualche telecomando infrarossi di qualche appareccio (tv, vcr, dvd...) che non usi piu? Si potrebbe anche usarne uno universale di marca conosciuta e programmato con codice per qualche appareccho poco diffuso, in modo che chiunque poi se lo possa procurare

 

[pm.astra2dve]

Ah i mitici ST62Exx a 20 o 28 pin con la memoria EPROM adesso ci sono gli ST7 che se non sbaglio sono Flash come i PIC . Di solito li si fa girare a 8-10 MHz e sono lenti perchè sono CISC e non RISC, le istruzioni sono più complesse del PIC, i salti li possono fare quasi dove vogliono se non ricordo male... .

Io non pensavo di commercializzare il mio posizionatore piuttosto rendere disponibili (una volta funzionanti) i sorgenti dei programmi, tutti gli schemi e i layout delle basette. D'altra parte non penso sia troppo difficile costruirsi una basetta 6x16 con 20 tasti collegati tra loro in modo quasi elementare e soltanto un PIC con pochi componenti di contorno e 1 o 2 LED a infrarossi . Utilizzando i telecomandi commerciali che trasmettono in codifica RZ a lunghezza di parola variabile avrei dovuto implementare la routine di ricezione manualmente nel programma, usando l'USART integrato il micro si occupa del campionamento del segnale, ricezione eccetera, io devo solo leggere il risultato e non implementare come si legge e poi leggerlo . A me poi interessava avere un telecomando con i tasti giusti, non riciclare un telecomando che magari mi costringe a mappare il comando SYNC sul tasto REC, i due CAL su CONT+/- a scapito dell'intuitività ... Se poi funziona a dovere sarebbe il primo telecomando che riesco a far andare, dopo le esperienze poco entusiasmanti con i modulini a 433 MHz

 

[antgue]

Poteva essere comoda la tastiera numerica e le 4 frecce di un qualsiasi telecomando... inizialmente si potrebbe mettere un secondo pic come ricevitore-codificatore di telecomando

 

[pm.astra2dve]

Messo da parte il telecomando (devo trovare una scatolina che mi vada bene ), lo stadio finale inizia a prendere forma...


Disposizione componenti e progetto di montaggio...


Mi manca una metà del circuito perchè ho finito le miche isolanti...
Io non lesino su nulla radiatori massicci , ponti a diodi di potenza raffreddati (quello che si vede l'ho recuperato da un alimentatore da computer rotto, non so quanti Amper tiene, forse 3, ma quello dedicato ai motori sarà da 8-10A ), resistenza di caduta da 25W corazzata, morsetti a sgancio rapido, fusibili integrati, piste fatte con filo di rame nudo rigido da 2.5 mm² piegato e saldato con pazienza certosina (e consumando una tonnellata di stagno ), collegamenti volanti con filo da elettricista della stessa misura . Penso che questo stadio finale quasi industriale tiene tranquillamente 2-3 motori per canale

Se non mi incasino ho anche trovato un modo per riutilizzare gli L298 che avevo preso dopo aver arrostito quello delle prove a suo tempo un modo che forse sarebbe un'innovazione (se trovo il modo di renderla stagna)

 

[antgue]

Complimenti Pm.astra2dve per l'ottimo montaggio.
A mio parere i mosfet non avevano bisogno nemmeno di aletta, ma se si ha tempo e voglia di metterla, comunque non guasta... Vedo 8 componenti finali... i mosfet sono 4, gli altri 4 sono i diodi di ricircolo?
Penso che sarebbe buona cosa rendere pubblico anche lo schema... che ne dici?