Archivi categoria: elettronica

5 minuti da Maker – supporto per saldatura elettrica

In laboratorio, quando bisogna stagnare cavi e cavetti, la difficoltà più comune è sempre la stessa: tenere fermo il filo nella posizione giusta mentre si lavora con saldatore e stagno. Per rendere questa operazione più semplice (e più “pulita” sul banco), ho realizzato un piccola basa costituita da due morsetti stampabile in 3D, pensato come supporto rapido per assistere la saldatura di cavi elettrici.

La struttura è volutamente essenziale ed è composta da tre elementi: una base e due mollette che si incastrano nella base. Ho realizzato anche una seconda versione della base che ermette due distanze diverse dai morsetti, così è possibile avvicinare o allontanare le mollette in base al tipo di filo o alla lavorazione da effettuare.

Come per il porta bobine di stagno che avevo condiviso nel post precedente, anche qui l’obiettivo è uno: mettere ordine e velocizzare le operazioni quando si salda, soprattutto in contesti didattici dove avere supporti semplici e robusti fa davvero la differenza.

Stampa rapida;
nessun supporto necessario;
assemblaggio a incastro, zero viti.

File per la stampa 3D

Seguendo il link è possibile scaricare i file e stampare le parti.

Buon Making a tutti 🙂

Arduino nello zaino, upgrade: un saldatore TS101 in un rugged case stampato in 3D

Lascia una risposta

Nel post “Arduino nello zaino” raccontavo l’idea di fondo: non portarsi dietro un mini-laboratorio completo, ma una dotazione minima, ordinata e pronta per qualsiasi micro-attività (in aula, in laboratorio, in giro).

Oggi aggiungo un tassello importante, l’uso di un saldatore elettrico portatile per la realizzazione di circuiti elettronici.

Ne ho provati tantissimi, a gas, a batteria, ma da qualche tempo uso il Miniware TS101, perché unisce portabilità, alimentazione flessibile e controllo della temperatura.

Con Arduino, ma in generale nella realizzazione di circuiti elettronici, prima o poi capita sempre almeno uno di questi scenari:

un cavetto Dupont che si sfila/si rompe e volete rifare un collegamento pulito;
un sensore o un connettore che volete rendere più robusto (saldatura + guaina termorestringente);
una piccola riparazione al volo (header, pin storti, fili su jack o morsetti);
saldare su circuiti PCB o millefori.

inoltre l’uso di un saldatore di queste dimensioni resta coerente con la logica che descrivevo nel post precedente: setup rapido, ordine, micro-attività replicabili.

Caratteristiche del TS101

Alimentazione: USB-C PD e DC “classico”

Il TS101 supporta due ingressi di alimentazione:

DC5525 (9–24 V) da alimentatore o batteria
USB-C Power Delivery (PD) da 9 V in su (caricatore PD / power bank PD, ecc.)

IMPORTANTE: non vanno usate contemporaneamente le due alimentazioni.

Nel manuale utente trovate anche una tabella che collega tensione/potenza e tempo minimo per passare da 30°C a 300°C (valori dichiarati):

9V (≈9W): ~95 s
12V (≈16W): ~43 s
16V (≈30W): ~22 s
19V (≈40W): ~15 s
24V (≈65W): ~9 s

Potenza e profili PD

In DC lavora tipicamente 9–24 V fino a 65 W max.
In USB-C PD può arrivare (a seconda di firmware e alimentatore) fino a 90 W max con PD 3.1.

Range temperatura e stabilità

50–400 °C con stabilità dichiarata ±2%.

Display

Display OLED più grande (128×32) rispetto a TS100, menu più ricco, preset e opzioni.

Comandi e uso base

Pulsante A: avvio riscaldamento / regolazione
Pulsante B: impostazioni / regolazione
OLED con icone di stato (boost, movimento, sleep, ecc.)
Presenza di vite di terra (ground screw)

Preset e regolazione temperatura

Potete lavorare con temperature preimpostate T1/T2/T3, oppure regolare “al volo”.

Boost mode

In riscaldamento, tenendo premuto A entri in boost mode: la punta sale alla temperatura “Boost” finché tenete premuto; rilasciando, torna alla temperatura di lavoro.

Sleep/Standby

se in working mode il TS101 resta fermo per 180 s (default), entra in sleep (compare “zZ”) e la punta scende alla “Sleep Temp”;
quando viene rilevato movimento, esce dallo sleep e torna in working mode;
se resta fermo in sleep per 240 s (default), passa in standby; dopo ulteriore tempo, lo schermo si spegne;
la lettera “M” sul display indica che il TS101 si sta muovendo;
parametro MsenUnit (sensibilità 1–5: più alto = più sensibile).

Configurazione rapida via file

Una funzione molto interessante è la gestione tramite file:

1. collegate il TS101 al PC con cavo dati USB-C
2. compare un disco virtuale
3. modificate CONFIG.TXT e i parametri vengono aggiornati

Questo è ottimo per preparare un “config” standard (temperature preset, tempi sleep, luminosità, sensibilità movimento) identica per più dispositivi.

Firmware update

tenete premuto A;
collegate via USB-C al PC (entra in DFU mode);
copiate il file firmware nel disco virtuale.

Sicurezza e limiti termici

range punta: 50°C–400°C;
dopo 5 minuti ad alta potenza sopra 350°C (o uso prolungato) il controller può arrivare a ~50°C;
quando non in uso, spegnere per evitare rischi;
se compare “No tip!”, la punta non è inserita correttamente e va reinstallata.

Compatibilità punte: un vantaggio pratico (e economico)

Il TS101 è compatibile con le punte TS100: se avete già punte, le riusate; se dovete comprarle, trovate molta scelta.

La custodia rugged stampata in 3D

Se il saldatore è portatile, il punto debole diventa il trasporto: punta, cavo, stagno, spugnetta/lanetta… tutto deve essere protetto e ordinato.

Un contenitore stampato 3D risulta molto utile, ciò evita di utilizzare la scatola di cartone con cui vi viene venduto il saldatore. Il contenitore che ho stampato è una custodia rugged multi-scomparto, pensata specificamente per TS100/TS101, e derivata (remix) da un progetto precedente che trovate seguendo il link allegato.

Su Makerworld trovate molti contenitori simili a quello che sto utilizzando io ma questa soluzione mi piace perché:

può ospitare TS100/TS101
cavo
rocchetto stagno
lana metallica per pulizia punta
stand/rest (con cuscinetto 608, usato come appoggio per il saldatore caldo)
vani extra per piccoli accessori/ricambi

riassumendo una configurazione minimalista come piace a me 🙂

Buon Making a tutti 🙂

Domande dagli utenti: perché micro:bit non pilota i motori direttamente?

2 Repliche

Nella giornata di ieri mi è arrivata una domanda molto sensata, una di quelle che prima o poi ci si pone tutti quando si prova a far muovere un robot con micro:bit o con Arduino.

“Se micro:bit riuscisse a passare da 3V a 5V si risparmierebbero i costi della scheda di espansione, nonché l’ottimizzazione degli spazi. Lei è d’accordo? Chissà perché non lo fanno: ormai tutti abbiamo bisogno di motorini.”

La risposta breve è questa:

Capisco il ragionamento, ma il vero ostacolo non è 3 V vs 5 V. Il punto è che un pin di micro:bit non è uno stadio di potenza.
Anche se la scheda fosse “a 5 V”, non potresti comunque collegare un motore direttamente ai pin in modo sicuro e affidabile.

Vediamo perché, con esempi concreti e riferimenti ai due kit che uso spesso nei corsi: Ring:bit V2 board e Kitronik :MOVE mini.

La spiegazione che segue è volutamente semplificata in quanto non necessariamente i colleghi che seguono i miei corsi sono docenti di materie di indirizzo tecnico.

Perché “alzare la tensione” non risolve il problema

Corrente: il motore chiede molta più energia di quella che un pin può dare

Un motore (anche piccolo) non “vuole solo tensione”: vuole soprattutto corrente, e ne vuole parecchia quando parte (corrente di spunto) e quando è sotto sforzo (ruote che spingono, attrito, urti).

Un pin GPIO di una scheda a microcontrollore è progettato per segnali e piccoli carichi, non per alimentare carichi elettromeccanici. Se provate a farlo, i sintomi tipici sono:

reset improvvisi della scheda,
comportamenti instabili,
surriscaldamento,
nel peggiore dei casi danni ai pin o al microcontrollore.

Disturbi e picchi: il motore “sporca” l’alimentazione e genera back-EMF

Il motore è un carico induttivo: quando viene acceso/spento o se ne cambia la velocità, può generare picchi di tensione (back-EMF) e disturbi elettrici che:

mandano in crisi la logica,
creano interferenze (anche sulla radio/BT),
degradano l’affidabilità nel tempo.

Serve un driver: lo “stadio di potenza” che separa logica e motore.

Per pilotare un motore DC, ad esempio quelli gialli che tipicamente vengono usati nei progetti didattici di robotica, serve uno stadio di potenza, cioè un driver motore, per esempio:

ponte H (per andare avanti/indietro e fare PWM in modo robusto),
oppure MOSFET + protezioni (se serve solo on/off o un verso).

Il driver fa tre cose fondamentali:

regge la corrente (anche i picchi),
gestisce la direzione e la velocità (PWM),
protegge micro:bit dai disturbi e dai picchi del motore.

Citando la richiesta dell’utente: “Ma allora perché micro:bit non è a 5V?”

In realtà molte schede “vivono” già in ambienti dove esistono 5 V (ad esempio USB), ma l’elettronica interna e i pin di I/O lavorano a bassa tensione (tipicamente 3,3 V) perché:

si riducono consumi e riscaldamento,
si protegge meglio la scheda,
si mantiene compatibilità con sensori moderni a bassa tensione,
e soprattutto (punto chiave): anche a 5 V i pin non diventerebbero “pilotamotori”.

Quindi: passare a 5 V non eliminerebbe la necessità di un driver. Cambierebbe solo alcuni dettagli di alimentazione/compatibilità, ma non la sostanza.

Il caso reale nei kit: Ring:bit V2 board e Kitronik :MOVE mini

Ring:bit V2 board: non è “la scheda che pilota motori”

La Ring:bit V2 board è principalmente una scheda di espansione/breakout:

rende più comodi alcuni collegamenti (ad esempio porte tipo GVS su P0/P1/P2),
integra un portabatterie (3×AAA) per alimentare il sistema/il robot,
fornisce un’interfaccia pratica per prototipare.

Va interpretata come interfaccia e distribuzione di alimentazione/connessioni, non come “micro:bit che pilota motori direttamente”.

Ring:bit V2

Kitronik :MOVE mini: usa servomotori, non motori DC senza elettronica di controllo integrata

La scheda Kitronik :MOVE mini può controllare due servomotori a rotazione continua. Questa scelta è utile per la didattica, perché un servo:

contiene già la propria elettronica di pilotaggio,
si controlla con un semplice segnale PWM (impulsi “stile servo”),
prende l’energia dal pacco batterie/board del kit, non dai pin di micro:bit.

In pratica:

micro:bit invia il comando (PWM),
il servo esegue, usando la sua alimentazione dedicata.

Questo è il motivo per cui, con :MOVE mini, si riesce ad avere un robot “semplice” e robusto senza introdurre subito il tema dei ponti H per motori DC.

:MOVE mini

Cosa vedremo nel corso: motori DC “veri” e driver dedicati

Durante il corso mostrerò anche l’altro scenario, quello tipico quando si usano i classici motori gialli da 6 V (motori DC con riduttore), dove il driver è obbligatorio.

motore TT

Lavoreremo in particolare con:

L298N (ottimo per capire il concetto di ponte H e cablaggi, anche se non è la soluzione più efficiente in assoluto),
Motor:bit di ELECFREAKS (più compatta e didattica, comoda per micro:bit).

Obiettivo: far capire chiaramente la differenza tra:

“motore DC” (serve driver + alimentazione adeguata),
“servo” (driver interno, controllo PWM più diretto).

Regola utile sempre: alimentazione separata e masse in comune

Quando si entra nel mondo motori/attuatori, una buona pratica è:

alimentare i motori/servi con una linea robusta (batterie/pack dedicato),
e mantenere massa (GND) in comune tra microcontrollore e driver/attuatori (quando richiesto), così i segnali di controllo hanno un riferimento corretto.

Questa singola regola elimina moltissimi “misteri” (reset, comportamenti casuali, servo che impazziscono).

Qualche precisazione in più sui motori DC o motori senza elettronica di controllo integrata

Troverete spesso la dicitura motori bare DC motor in pratica sono motori che hanno solo due terminali (o due fili):

fornite tensione > girano
togliete tensione > si fermano
invertite la polarità > invertono il verso di rotazione (se lo permettete elettricamente)

In ambito tecnico anglofono è abbastanza comune parlare di “bare DC motor” per indicare un motore senza elettronica di controllo integrata (cioè “il solo motore”, tipicamente a due fili) e spesso anche senza riduttore/struttura accessoria.

Esempi tipici:

i classici motori gialli TT 3–6 V usati nei robot economici
motorini DC “a spazzole” da modellismo o recuperati da giocattoli

I bare DC motor non hanno al loro interno:

driver di potenza
protezioni contro i picchi (back-EMF)
logica per interpretare un segnale di controllo

Quindi, per farli funzionare con micro:bit, serve aggiungere elettronica esterna:

un ponte H (es. L298N, TB6612, DRV8833) se vuoi avanti/indietro + PWM
oppure un MOSFET + diodo se ti basta on/off (e magari un solo verso)

L298N

TB6612

DRV8833

Differenza con un servo (o un motoriduttore “intelligente”)

Un servomotore (anche a rotazione continua) invece non è senza elettronica di controllo perché contiene già:

elettronica di pilotaggio
circuito di potenza
logica che interpreta il comando (impulsi PWM stile servo)

Per questo il micro:bit può “comandare” un servo con un semplice segnale, mentre con un motore DC senza elettronica di controllo deve essere gestito da un driver.

Buon Making a tutti 🙂

Arduino esercizi – Base marziana ELYSIUM

Lascia una risposta

Quest’anno sto supportando, con attività di sperimentazione pratica, anche classi non mie, proponendo laboratori motivanti per riaccendere curiosità e partecipazione. La prossima settimana lavorerò con una terza elettronica numerosa ed eterogenea, non semplice da gestire nei laboratori tradizionali. Per questo, insieme ai colleghi, abbiamo scelto di spostare la lezione nel Laboratorio Territoriale (LTO), uno spazio ricco di attrezzature “inusuali” per un normale laboratorio scolastico: il contesto giusto per stuzzicare l’attenzione e rendere concreti gli apprendimenti su Arduino.

Stato iniziale della classe:

hanno svolto le primissime prove con Arduino (blink e poco altro);
conoscono le variabili e hanno un’idea dei tipi di dato;
sanno riconoscere e usare pulsanti, interruttori, deviatori e LED.

L’obiettivo della lezione è mettere insieme questi elementi in un compito pratico, semplice ma significativo: progettare e realizzare un piccolo controller di luce che usa pulsante, interruttore/deviatore e LED, approfondendo al tempo stesso nozioni base di programmazione (lettura ingressi, gestione del tempo con millis() o delay(), piccola logica a stati AUTO/MANUALE).

Desidero che gli studenti vedano subito un risultato, si divertano a farlo funzionare e, passo dopo passo, consolidino lessico, metodo e fiducia.

Questa lezione sarà suddivisa in tre parti, due introduttive (ed ognuna con attività aggiuntive facoltative) che condurranno alla terza parte conclusiva in cui gli studenti dovranno realizzare il sistema completo.

In ogni fase viene mostrato:

diagramma di flusso;
pseudocodice;
schema di collegamento;

Lo studente deve realizzare lo sketch Arduino di ogni fase.

Come sempre amo introdurre il problema usando una narrazione coinvolgente e visto che mi piace la fantascienza andremo con i ragazzi su Marte. 🙂

Base marziana ELYSIUM

Siete il tecnico elettronico della base marziana. È stato inaugurato un nuovo modulo abitativo e, durante lo spostamento di carichi nel tunnel pressurizzato che collega la serra alla cupola, un carrello radiocomandato ha urtato la parete, provocando una micro-frattura con inizio di depressurizzazione. L’intervento rapido di un manutentore ha evitato il peggio. Dalle analisi emergono due cause principali: affaticamento del personale in turno e illuminazione insufficiente nel corridoio. Per prevenire incidenti e ridurre i consumi, il comando vi incarica di realizzare un controller luce “low-power”: in AUTO la luce si accende per pochi secondi quando viene rilevato il passaggio (lo simulerete con un pulsante); in MANUALE rimane attiva per la durata delle ispezioni EVA (Extra-Vehicular Activity). Il progetto deve essere affidabile, parsimonioso nei consumi e conforme agli standard di sicurezza della base, così da superare senza riserve la verifica dei consumi energetici imminente.

Per evitare che un bug in un solo componente comprometta l’intero sistema, decidete di scomporre il problema e validare separatamente i due comportamenti critici, prima di integrarli.

Prima prova – “Solo PULSANTE” (sensore di passaggio)
Nel banco di test allestito accanto al tunnel, il tecnico simula l’evento di passaggio con un pulsante. Alla pressione del pulsante la luce si accende un un determinato tempo e poi si spegne.
(Facoltativo) Sperimentate anche la variante in cui la luce reagisca con un ping di cortesia temporizzato e che non riparta finché il pulsante resta premuto (niente retrigger). Questo serve a scongiurare illuminazioni troppo lunghe dovute a rimbalzi o pressioni involontarie: energia salva, rischio ridotto.
Seconda prova – “Solo INTERRUTTORE” (modalità MANUALE)
Il tecnico realizza il comando manuale: ON = luce stabile, OFF = buio. Qui controlla la priorità operativa.
(Facoltativo) Sperimentate anche il feedback all’inserimento, due lampeggi rapidi. Quando si passa a ON: due lampeggi veloci e poi resta acceso.

Superate queste due verifiche, il tecnico procede alla versione finale: unendo AUTO (pulsante) e MANUALE (interruttore) nello stesso controller, con la regola d’oro: MANUALE ha sempre priorità. È così che il progetto rispetta il protocollo Zero-Disturb e arriva pronto alla verifica dei consumi energetici.

Prima prova – “Solo PULSANTE” (sensore di passaggio)

Esercizio: realizzare lo sketch Arduino che permette di realizzare questa prima prova.

Diagramma di flusso

Pseudocodice

INIZIO
  imposta PIN_LED come USCITA
  imposta PIN_PULSANTE come INGRESSO
  scrivi PIN_LED = LOW

  RIPETI PER SEMPRE
    statoPulsante ← leggi(PIN_PULSANTE)   // HIGH = premuto (pull-down esterno)

    SE statoPulsante è HIGH ALLORA
      scrivi PIN_LED = HIGH
      attesa 1500 ms
      scrivi PIN_LED = LOW
      attesa 50 ms
    FINE SE
  FINE RIPETI
FINE

Schema di collegamento

Prima prova – “Solo PULSANTE” (sensore di passaggio) – variante che evita il retrigger

Esercizio: realizzare lo sketch Arduino che permette di realizzare la variante della prima prova.

- Premo > LED acceso ~1,5 s > poi spento.
- Tenendo premuto non riparte; riparte solo dopo il rilascio.

Diagramma di flusso – versione che evita il retrigger

Pseudocodice – versione che evita il retrigger

INIZIO
  // Setup
  imposta PIN_LED come USCITA
  imposta PIN_PULSANTE come INGRESSO
  scrivi PIN_LED = LOW

  RIPETI PER SEMPRE   // loop
    statoPulsante ← leggi(PIN_PULSANTE)

    SE statoPulsante è HIGH ALLORA           // pulsante premuto
      scrivi PIN_LED = HIGH                  // accendi luce di cortesia
      attesa 1500 ms                         // delay 1,5 s
      scrivi PIN_LED = LOW                   // spegni

      // attesa rilascio per evitare retrigger continui
      MENTRE leggi(PIN_PULSANTE) è HIGH FAI
        attesa 10 ms
      FINE MENTRE

      attesa 50 ms                           // piccolo anti-rimbalzo
    FINE SE
  FINE RIPETI
FINE

Seconda prova – “Solo INTERRUTTORE” (modalità MANUALE)

Esercizio: realizzare lo sketch Arduino che permette di realizzare questa seconda prova.

Interruttore ON > LED acceso fisso. (1500 ms)
Interruttore OFF > LED spento.

Prevedere un anti-rimbalzo realizzato con un delay di 50 ms.

Diagramma di flusso

Pseudocodice

INIZIO
  imposta PIN_LED come USCITA
  imposta PIN_PULSANTE come INGRESSO
  scrivi PIN_LED = LOW

  RIPETI PER SEMPRE
    statoPulsante ← leggi(PIN_PULSANTE)   // HIGH = premuto (pull-down esterno)

    SE statoPulsante è HIGH ALLORA
      scrivi PIN_LED = HIGH
      attesa 1500 ms
      scrivi PIN_LED = LOW
      attesa 50 ms
    FINE SE
  FINE RIPETI
FINE

Diagramma di flusso

Pseudocodice

INIZIO
  // Setup
  imposta PIN_LED come USCITA
  imposta PIN_INTER come INGRESSO
  scrivi PIN_LED = LOW

  RIPETI PER SEMPRE    // loop
    statoInterruttore ← leggi(PIN_INTER)   // HIGH = MANUALE ON (con pull-down esterno)

    SE statoInterruttore è HIGH ALLORA
      scrivi PIN_LED = HIGH               // LED acceso
    ALTRIMENTI
      scrivi PIN_LED = LOW                // LED spento
    FINE SE
  FINE RIPETI
FINE

Schema di collegamento

Seconda prova (facoltativo) – “Solo INTERRUTTORE” (modalità MANUALE) – variante con feedback all’inserimento

Per il feedback prevedere un accensione e spegnimento del LED per 3 cicli da 80 ms

Diagramma di flusso

Pseudocodice – variante con feedback all’inserimento

INIZIO
  // Setup
  imposta PIN_LED come USCITA
  imposta PIN_INTER come INGRESSO    // pull-down esterno
  scrivi PIN_LED = LOW
  statoPrec ← LOW

  RIPETI PER SEMPRE
    stato ← leggi(PIN_INTER)          // HIGH = MANUALE ON

    // Rilevazione fronte di salita (OFF -> ON)
    SE (stato = HIGH) AND (statoPrec = LOW) ALLORA
      PER i da 0 a 1 FAI               // due lampeggi rapidi
        scrivi PIN_LED = HIGH
        attesa 80 ms
        scrivi PIN_LED = LOW
        attesa 80 ms
      FINE PER
    FINE SE

    // Stato stabile della modalita MANUALE
    SE (stato = HIGH) ALLORA
      scrivi PIN_LED = HIGH
    ALTRIMENTI
      scrivi PIN_LED = LOW
    FINE SE

    statoPrec ← stato
  FINE RIPETI
FINE

Realizzazione del sistema completa

Esercizio 03: realizzare lo sketch Arduino che permette di realizzare l’intero sistema.

manuale ON? = interruttore HIGH
pulsante premuto? = pulsante HIGH
timer attivo? = millis() prima di tScadenza (luce ancora entro i 5 s)

Diagramma di flusso

Pseudocodice

INIZIO
  // Setup
  imposta PIN_LED come USCITA
  imposta PIN_PULSANTE come INGRESSO
  imposta PIN_INTER come INGRESSO
  scrivi PIN_LED = LOW
  tScadenza ← 0
  DURATA_MS ← 5000

  RIPETI PER SEMPRE   // loop
    // Lettura ingressi
    statoInterruttore ← leggi(PIN_INTER)      // HIGH = MANUALE ON (pull-down esterno)
    statoPulsante     ← leggi(PIN_PULSANTE)   // HIGH = pulsante premuto

    // Significato applicativo
    manuale ← (statoInterruttore è HIGH)
    premuto ← (statoPulsante è HIGH)

    SE manuale ALLORA
      scrivi PIN_LED = HIGH                   // LED acceso fisso in MANUALE
    ALTRIMENTI
      SE premuto ALLORA
        tScadenza ← tempoCorrenteMs() + DURATA_MS
      FINE SE

      SE tempoCorrenteMs() < tScadenza ALLORA // timer attivo?
        scrivi PIN_LED = HIGH                 // LED acceso (luce di cortesia)
      ALTRIMENTI
        scrivi PIN_LED = LOW                  // LED spento
      FINE SE
    FINE SE
  FINE RIPETI
FINE

Schema di collegamento

Buon Coding a tutti 🙂

Meditazione da Maker: un supporto DIN per prototipare in fretta (e con ordine)

Lascia una risposta

5 minuti da Maker del fine settimana.

In queste settimane devo prototipare velocemente e rispondere ai dubbi di studenti di classi diverse: c’è chi inizia a “giocare” con l’elettronica e chi, più grande, pensa già ai progetti per la maturità. Risultato? Un continuo montare e smontare circuiti… e l’ordine che vacilla.

Per la mia attività di making del weekend ho deciso di dare forma a un supporto di prototipazione basato su guide DIN (guide omega), utilissime in elettronica e automazione. Chi mi segue sa che in passato ho realizzato vari supporti, trovate esempi sul mio sito e su Thingiverse, soprattutto per esercitazioni con PLC e microcontrollori.

Oggi pomeriggio, stanco dei moduli sparsi sul banco, ho sfruttato solo materiale di recupero per costruire una base pratica che mi permetta di passare da un’esercitazione all’altra in pochi minuti. Ho trattato l’attività come una piccola “Meditazione da Maker”: due ore di musica in sottofondo, progettazione e realizzazione. Missione compiuta nei tempi.

Il progetto è ancora migliorabile, quindi per ora non condivido i sorgenti: li pubblicherò a breve. Dalle immagini si capisce comunque quanto sia semplice replicarlo. La base misura 22×22 cm, una scelta dettata dal pannello già a disposizione e la struttura che ospita le barre DIN riprende i miei progetti precedenti, con qualche variazione mirata.

Nei prossimi giorni arriveranno sorgenti e dettagli, tornate a trovarmi. 🙂

Related posts:

Caratteristiche del TS101

Alimentazione: USB-C PD e DC “classico”

Potenza e profili PD

Range temperatura e stabilità

Display

Comandi e uso base

Preset e regolazione temperatura

Boost mode

Sleep/Standby

Configurazione rapida via file

Firmware update

Sicurezza e limiti termici

Compatibilità punte: un vantaggio pratico (e economico)

La custodia rugged stampata in 3D

Related posts:

Perché “alzare la tensione” non risolve il problema

Disturbi e picchi: il motore “sporca” l’alimentazione e genera back-EMF

Il caso reale nei kit: Ring:bit V2 board e Kitronik :MOVE mini

Cosa vedremo nel corso: motori DC “veri” e driver dedicati

Regola utile sempre: alimentazione separata e masse in comune

Differenza con un servo (o un motoriduttore “intelligente”)

Related posts:

Base marziana ELYSIUM

Prima prova – “Solo PULSANTE” (sensore di passaggio)

Diagramma di flusso

Pseudocodice

Schema di collegamento

Prima prova – “Solo PULSANTE” (sensore di passaggio) – variante che evita il retrigger

Diagramma di flusso – versione che evita il retrigger

Pseudocodice – versione che evita il retrigger

Seconda prova – “Solo INTERRUTTORE” (modalità MANUALE)

Seconda prova (facoltativo) – “Solo INTERRUTTORE” (modalità MANUALE) – variante con feedback all’inserimento

Diagramma di flusso

Pseudocodice – variante con feedback all’inserimento

Realizzazione del sistema completa

Diagramma di flusso

Pseudocodice

Schema di collegamento

Related posts:

Related posts: