Mi Piace! Mi Piace!:  0
NON mi piace! NON mi piace!:  0
Grazie! Grazie!:  0
Pagina 1 di 2 12 ultimoultimo
Visualizzazione dei risultati da 1 a 20 su 37

Discussione: Flynn e Arduino

  1. #1
    Novizio/a

    User Info Menu

    Predefinito Flynn e Arduino



    Ciao

    Prima di tutto un saluto a tutti coloro che animano il forum, e un "DAJEEE" a kecco e mac (e collaboratori/amici/appassionati vari) per il loro fantastico lavoro, credo di non essere l'unico che aspetta giorno dopo giorno notizie e aggiornamenti...

    Ma vengo alla domanda

    C'è qualcuno che ha provato o pensa di provare il "Flynn" insieme alla scheda Arduino?

    Partendo da un post di btbbass (Parallel Path Gigante) ho cercato in rete e il "cosetto" è davvero intrigante (ed economico).

    Chiedo perchè non essendo del "mestiere" se decidessi di provare a fare qualcosina, al di la delle difficoltà tecniche (piu' o meno - forse - superabili) sicuramente mi inchioderei sulle modifiche del codice su Arduino.
    Non vorrei (ne sarei in grado) di fare i "mostri" di kecco e mac, ma solo veder girare qualcosa...

    Per finire, come già proposto, perchè non mettere in "evidenziata" un post che spieghi (per chi volesse fare dei piccoli test) cose come:

    1) scegliere la giusta dimensione dei magneti, bobina, fili ecc. Un po come già scritto su

    Parallel Path: esperimento definitivo sul suo funzionamento

    ma con più esempi...

    Per finire considerate che chi ha scritto fa l'impiegato.... non sparate sul pianista :-)

    Ciao e dajeeeeee

  2. #2
    Pietra Miliare

    User Info Menu

    Predefinito

    Il grosso problema che ha incontrato kekko nella sua super centralina è la velocità del processore (leggi i suoi ultimi post) e penso che dovrà delegare alcuni compiti del processore ad altri integrati analogici/digitali per allegerire la CPU dai calcoli sopratutto quando il motore va ad alto numero di giri.
    Credo che anche la scheda arduino usi dei processori relativamente lenti e il problema si ripresenterà come per la centralina di Kekko.

  3. #3
    Novizio/a

    User Info Menu

    Predefinito

    Quote Originariamente inviata da triac60 Visualizza il messaggio
    ...Il grosso problema che ha incontrato kekko nella sua super centralina è la velocità del processore (leggi i suoi ultimi post) ......
    Ciao Triac,
    Ho letto e riletto i post , ma come detto "non sono del mestiere"....
    Pensavo di "giocare" con un microFlynn (micro nel senso di piccolo)

    Le caratteristiche di Arduino sono (prese dal sito)
    MicrocontrollerATmega168 Operating Voltage5V Input Voltage (recommended)7-12V Input Voltage (limits)6-20V Digital I/O Pins14 (of which 6 provide PWM output) Analog Input Pins6 DC Current per I/O Pin40 mA DC Current for 3.3V Pin50 mA Flash Memory16 KB (of which 2 KB used by bootloader) SRAM1 KB EEPROM512 bytes Clock Speed16 MHz
    Poi esiste anche un clone "Sanguino" che monta un ATmega644P

    picoPower technology AVR Microcontroller.
    64-Kbyte self-programming Flash Program Memory, 4-Kbyte SRAM, 2-KByte EEPROM, 8 Channel 10-bit A/D-converter. JTAG interface for on-chip-debug. Up to 20 MIPS throughput at 20 MHz. 1.8 - 5.5 Volt Operation.

    Ma qui mi fermo visto che "non so di che parlo, ops scrivo"

    Come scritto, mi piacerebbe solo fare dei test/esperimenti

    Ciao

  4. #4
    Seguace

    User Info Menu

    Predefinito

    Salve a tutti! I problemi che ho riscontrato nell'uso di processori sono proprio quelli elencati da triac, e la soluzione sarà quella di fare qualcosa di analogico per alleggerire i calcoli che deve fare il processore.

    Io ho usato un ATmega32, che sarebbe il successore dell'ATmega168 (quello usato su arduino).

    Con un ATmega64 si potrebbe provare, ma credo cambi di poco, il vero problema non è la "capacità" del processore ma la sua velocità, e siccome questi processori lavorano in genere a 16 MHz, sarà difficile andare su con i giri...

    Ci vorrebbe qualcosa di gorsso tipo un 150 MHz, ma facendo così rischiamo di dover costruire una centralina shuttle intorno al motore, e la cosa non è molto pratica...

    Per questo sto cercando di risolvere il problema per via analogica, cercando di semplificare un po' il tutto... Alla fine le cose più semplici sono sempre quelle che hanno funzionato meglio!!

    Saluti kekko!
    La sapienza è figlia dell'esperienza... Leonardo da Vinci

  5. #5
    Seguace

    User Info Menu

    Predefinito

    mmmm 150mhz.....
    ma siete sicuri....questa cosa mi ha fatto sempre pensare.....20 mhz sono un botto!!!!!
    Come programmate in C o in assembler???

    Nel motore 8 poli romagna,ho pensato a una ruota fonica con 10 livelli di fori,in pratica con 10 coppie di foto-ricevitori,riesco a controllare l'anticipo......poi con un shift-register regolo i 10 led.....in pratica con 3 pin digitali(clock,dati e strobe)piloto 10 led.....Per regolare il dyuty ho pensato a un normale encoder....parte il segnale di Anticipo-ritardo(uno dei 10 led sulla ruota fonica) la bobina si attiva,dopo N-impulsi dell'encoder(livello di dyuty) la bobina si disattiva......la cosa ricomincia al seguente impulso(ruota fonica,anticipo)
    Quindi il uP deve solo:Accendere uno dei 10 led(per decidere il grado di anticipo) e contare gli impulsi dell'encoder.....Non ci sono calcoli complicati Bastano anche 8mhz.....
    Questa è una prima idea.....


    Dai mac e kekko....cosa state combinando?????Stete tramando qualche cosa!!!

    Ciao
    Framoro...

  6. #6
    Seguace

    User Info Menu

    Predefinito

    Ciao gianfranco! E' proprio così che stavo facendo! Ricordi l'encoder con quella miriade di foto a giro?? Servivano proprio a quello, variare la fase, l'avevamo fatto con un fotodiodo ogni grado, ma purtroppo un grado di escursione sul 12 poli è un botto ma proprio tanto, e quindi non avevamo margine di escursione, e appena si superavano X gradi, il motore si sfasava e sboooooom!

    Purtroppo per il duty ti confermo che con 8 MHz non ci fai nulla... Poi nn so se ci riesci magariiiiiiiiiiiiiiiiiiiiiiiii !!!!!!!! Anche a lavoro ho chiesto agli ingegneri e mi hanno detto, che gestendo solo ed esclusivamente il duty, con un 16 MHz, non puoi arrivare sopra i 2 KHz di gestione (parlo di acquisizione segnale, conteggio del tempo, calcolo in %, e uscita finale). Questo perchè il tempo di calcolo diventa più lungo degli impulsi che arrivano dall'encoder.

    Per fare quella cosa che dici di usare un encoder per gestire il duty, stiamo sempre lì, per avere una buona escursione dovresti fare un botto di tacchette, e stiamo da capo a 12

    Cmq continua per la tua strada, perchè magari io sbaglio su qualcosa, se invece tu ci riuscisti sarebbe proprio una svolta!!!!

    saluti kekko e sempre dajeeeeeeeeeeeeeeeeeeeeeeeeeeeee
    La sapienza è figlia dell'esperienza... Leonardo da Vinci

  7. #7
    Pietra Miliare

    User Info Menu

    Predefinito

    Ciao Gianfranco
    Se stai studiando un encoder con 10 led ti conviene farlo assoluto, in modo da leggere in ogni istante la posizione in gradi del rotore, a quel punto il processore deve solo comparare la cifra binaria (a 10 bit) con una tabella residente in memoria, e attivare le uscite che pilotano il ponte ad H.

  8. #8
    Seguace

    User Info Menu

    Predefinito

    Il motore ha bisogno del regolatore di fase e di duty....per quello di fase ho pensato a 10 o 12 o 16 led-ricevitori il primo in linea con il dentino il secondo sfasato di 1 o 2 gradi il terzo 4 o 8 gradi e così via .....a questo punto basta alimentare il gruppo "uno dei tanti" led-ricevitore per avere lo sfasamento desiderato.....poi per il duty ci vuole un encoder assoluto che dica dopo quanti impulsi(dopo il segnale di sfasamento) la bobina si deve spegnere.
    Quindi ....il led(uno dei 10 o 12 0 16 led-fasatura)riceve l'impulso per attivare la bobina,inizio a contare gli impulsi dell'encoder assoluto e dopo tot impulsi(duty)stacco la bobina....
    Sembra semplice e nn ci vogliono calcoli.....se usiamo solo un'encoder bisogna fare un sacco di calcoli,per non parlare del duty.....le operazioni specie le divisioni,fanno perdere un sacco di tempo......bisogna fare le cose semplici.....
    Framoro...

  9. #9
    Seguace

    User Info Menu

    Predefinito

    in pratica triac....dici di usare solo un'encoder........?????mi sfugge qualcosa........ma è possibile che questo motore, sia più difficoltoso di un brushless che ha tre fasi..uffaa
    Framoro...

  10. #10
    Novizio/a

    User Info Menu

    Predefinito

    Ciao,

    Visto che siamo (siete ) in tema, in allegato un piccolo prg per la stampa del disco encoder.

    Fonte:http://www.mindspring.com/~tom2000/Delphi/Codewheel.html

    File Allegati File Allegati

  11. #11
    Pietra Miliare

    User Info Menu

    Predefinito

    Quote Originariamente inviata da Gianfranco Visualizza il messaggio
    Il motore ha bisogno del regolatore di fase e di duty....per quello di fase ho pensato a 10 o 12 o 16 led-ricevitori il primo in linea con il dentino il secondo sfasato di 1 o 2 gradi il terzo 4 o 8 gradi e così via .....a questo punto basta alimentare il gruppo "uno dei tanti" led-ricevitore per avere lo sfasamento desiderato.....poi per il duty ci vuole un encoder assoluto che dica dopo quanti impulsi(dopo il segnale di sfasamento) la bobina si deve spegnere.
    Quindi ....il led(uno dei 10 o 12 0 16 led-fasatura)riceve l'impulso per attivare la bobina,inizio a contare gli impulsi dell'encoder assoluto e dopo tot impulsi(duty)stacco la bobina....
    Sembra semplice e nn ci vogliono calcoli.....se usiamo solo un'encoder bisogna fare un sacco di calcoli,per non parlare del duty.....le operazioni specie le divisioni,fanno perdere un sacco di tempo......bisogna fare le cose semplici.....
    Guarda qui
    encoder

    L'encoder assoluto non ti da una semplice sequenza di onde quadre, ma un codice binario che ti indica esattamente l'angolo.
    Con 8 fototransistor hai 8 bit e quindi puoi spacchettare un angolo giro in 256 parti, con 'soli' 9 fotodiodi in 512, e quindi hai una precisione maggiore del grado.
    L'unica cosa da fare è tarare il disco ottico con lo zero del rotore.
    Leggi i 9 bit da nove porte/pin del processore e metti il risultato in una variabile(con un processore RISC sono due cicli di clock), poi la confronti con variabili o costanti preimpostate:

    ES:

    ON_SX = 10 'Gradi
    OFF_SX = 20 'Gradi

    if angolo = < ON_SX then Attiva_parte_sinistra_ponte_H
    if angolo = > OFF_SX then disattiva_parte_sinistra_ponte_H
    ecc..
    E anche qui sono pochi cicli (specialmente se li scrivi in codice nativo)

    Spero di essere stato di aiuto

    PS: Sto facendo anche io una centralina, ma senza processore, e con IC che possono andare a qualche MHz.

  12. #12
    Seguace

    User Info Menu

    Predefinito

    Quote Originariamente inviata da Gianfranco Visualizza il messaggio
    Sembra semplice e nn ci vogliono calcoli.....
    In bocca al lupoooooooooooooooooooooooooo!

    ...Io ho fatto esattamente così, per questo ti dico che non è così semplice, nel senso che così come vuoi fare, fai un encoder incrementale e non assoluto, per farlo assoluto devi fare come dice triac!

    ...Ti accorgerai che avrai bisogno di maggiore risoluzione, e qui cominceranno i guai

    Ma lungi da me lo scoraggiarti, magari trovi una qualche soluzione a cui io non ho pensatoo!!

    Sempre dajeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
    La sapienza è figlia dell'esperienza... Leonardo da Vinci

  13. #13
    Seguace

    User Info Menu

    Predefinito

    Grazie triac e kekko....ora studio.

    Triac....quando ho finito il motore ti vengo a prendere.....tanto abitiamo vicini....
    ciao
    Framoro...

  14. #14
    Seguace

    User Info Menu

    Predefinito

    Nel tuo modo sembra ancora più semplice.........basta l'encoder

    Questa notte ho pensato a un sistema

    >un fotodiodo che rileva il dentino.....inizio e fine......."pieno"
    poi basta il solito encoder....A singolo bit....che ti dice quanto il rotore si sposta da inizio dentino e fine dentino......basta contare il numero di impulsi e regoli l'anticipo e duty.....In pratica bastano due segnali.....diodo-fotodiodo e encoder(a un bit)......
    Si potrebbe fare l'encoder con due bit....uno 1000 passi "poi si calcolano" e l'altro con il numero di dentini del rotore.....
    Framoro...

  15. #15
    Seguace

    User Info Menu

    Predefinito

    Domanda se noi programmiamo bene il pic......il sistema riesce a leggere il numero di impulsi dell'encoder......a 10000 giri?????Non è per caso che noi quando leggiamo il dato e facciamo la verifica del dato,nn riusciamo a modificare lo stato dell'uscita in tempo??
    Se facciamo operazioni complicate(moltiplicazioni o divisioni) sicuramente non riusciamo.....poi bisogna programmare in assembler ...e non affidarsi a programmatori ad alto livello ....tipo C o peggio besic...Nel tuo modo triak basta fare solo una comparazione.....beh anche nel mio modo
    Framoro...

  16. #16
    Novizio/a

    User Info Menu

    Predefinito

    Quote Originariamente inviata da Gianfranco Visualizza il messaggio
    ...Questa notte ho pensato a un sistema
    Allora non sono l'unico che a volte non ci dorme

    @Kecco (e tutti gli atri):
    1) secondo la tua esperienza, che risoluzione dovrebbe avere un encoder? (in gradi e/o passi) per avere un buon controllo del motore?
    Immagino che sia anche in funzione della geometria del motore, ma lo chiedo per avere un'idea di massima

    2) Ho visto sempre che si scrive di grandi velocita in giri al minuto, la domanda da (super)profano è.... Perchè??? A velocità piu' umane non si entra in coppia? Non rende? ecc ecc

    Grazie

  17. #17
    Pietra Miliare

    User Info Menu

    Predefinito

    Quote Originariamente inviata da Halfblack Visualizza il messaggio
    Allora non sono l'unico che a volte non ci dorme

    @Kecco (e tutti gli atri):
    1) secondo la tua esperienza, che risoluzione dovrebbe avere un encoder? (in gradi e/o passi) per avere un buon controllo del motore?
    Immagino che sia anche in funzione della geometria del motore, ma lo chiedo per avere un'idea di massima

    2) Ho visto sempre che si scrive di grandi velocita in giri al minuto, la domanda da (super)profano è.... Perchè??? A velocità piu' umane non si entra in coppia? Non rende? ecc ecc

    Grazie
    il discorso encoder con alta risoluzione, serve per capire esattamente sto motore a quanto e come deve girare , il problema è che noi non lo sappiamo, per quello ci serve una centralina regolabile in anticipo ritardo duty ecc

    se sapevamo, data la geometria del motore, a quanti giri coppia volt A doveva girare, la centralina si fa in 2 ore

    abbiamo visto che un decimo di grado con il 12 poli già è tanto..per fare delle regolazioni buone servirebbe la metà del decimo di grado..

    quando al motore dai una fase fissa(anticipo) un duty fisso(50%) hai delle prestazioni, ma poi vedi che spostando di pochissimo l'anticipo cambia tutto drasticamente, consumo, giri, rendimento...per non parlare se poi quel duty lo porti al 60%, di conseguenza deve ricambiare l'anticipo e i V e A che gli dai..

    ecco perchè ci serve una centralina che possa regolare in tempo reale tutti questi valori, solo così potremo capire i punti di lavoro ideali di queso motore e fare una curva di rendimento..

  18. #18
    Novizio/a

    User Info Menu

    Predefinito

    Potrebbero essere utili ?
    PC/104 & PC/104 Plus Single Board Computers | CoreModule | Ampro Computers, Inc.
    soprattutto il CoreModule 420 dovrebbe essere un modulo a basso costo.....


  19. #19
    Appassionato/a

    User Info Menu

    Predefinito

    Mi sembra che state descrivendo l'encoder della haidenem.. ( non so se si scrive cosi)
    encoder assoluti con risoluzione 18.000 e 24.000 tacche ma costano un occhio.. Vengono usati sulle macchine a controllo numerico sono molto precisi.. Mi riferisco sempre ad encoder radiali che gestiscono il motore n. dei giri e velocità.. simili alla tachimetrica

  20. #20
    Pietra Miliare

    User Info Menu

    Predefinito

    Quote Originariamente inviata da Meccatronico1 Visualizza il messaggio
    Mi sembra che state descrivendo l'encoder della haidenem.. ( non so se si scrive cosi)
    encoder assoluti con risoluzione 18.000 e 24.000 tacche ma costano un occhio.. Vengono usati sulle macchine a controllo numerico sono molto precisi.. Mi riferisco sempre ad encoder radiali che gestiscono il motore n. dei giri e velocità.. simili alla tachimetrica
    Te lo immagini un motore che costa 100€ con un encoder da 1000€ e una centralina da 500€.
    Se riesco più tardi invio uno schema di massima per allegerire la CPU.

  21. RAD
Pagina 1 di 2 12 ultimoultimo

Discussioni simili

  1. Discutiamo del motore di Flynn a 12 poli!
    Da kekko.alchemi nel forum Parallel Path
    Risposte: 712
    Ultimo messaggio: 04-10-2014, 21:13
  2. Centralina elettronica per il motore di flynn
    Da kekko.alchemi nel forum Parallel Path
    Risposte: 33
    Ultimo messaggio: 05-11-2009, 14:34
  3. ricostruito il due poli di flynn!
    Da mac-giver nel forum Parallel Path
    Risposte: 181
    Ultimo messaggio: 05-11-2009, 14:29
  4. Mac & Kekko presentano: Costruiamo il motore di flynn a 12 poli
    Da kekko.alchemi nel forum Parallel Path
    Risposte: 365
    Ultimo messaggio: 05-11-2009, 14:26

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •