GRBLHAL e Teensy 4.X

Sezione dedicata ai controlli seriali, usb e Ethernet
Per gli approfondimenti si rimanda ai subforum specifici.
Subforum:
CncDrive
PlanetCNC
RosettaCNC
Twintec
Rispondi
tecno67
Member
Member
Messaggi: 391
Iscritto il: lunedì 26 febbraio 2007, 14:25
Località: Prov. di Milano

Re: GRBLHAL e Teensy 4.X

Messaggio da tecno67 » martedì 1 dicembre 2020, 13:44

@Junior73
Se quello che ti interessa è un DRO per Arduino l'ho già scritto, come esercizio quando stavo scrivendo la mia lettura per encoder , solo il tempo di recuperarlo e te lo mando.

Ho anche scritto un doppio controllo closed-loop per motori DC minimale per Arduino UNO, funziona ovviamente con step rate relativamente bassi.
Qui ne trovi traccia, assieme alle discussioni che abbiamo avuto io ed Hell

viewtopic.php?f=8&t=81037&start=45

Se vai sul sito forum italiano di Arduino ci trovi anche altro. Se riesci a capirne la logica di quello che ho fatto, è abbastanza semplice creare una versione con 3 letture encoder in quadratura e 3 canali in step/dir da comparare tra loro per farne una sorveglianza su tre assi con un contatto di allarme da rimandare al controllo per metterlo in stop in caso di superamento errore oltre un certo valore e questo potrebbe anche essere un oggettino interessate per tutti quelli che hanno una modesta 3 assi che ogni tanto perde qualche passo per salvare un po di alluminio o MDF.

Il fatto è che con Arduino UNO, sono più che altro degli esercizi accademici. Già volendo fare un semplice sistema di sorveglianza per bloccare la lavorazione in caso di perdita passi, è già difficile arrivare attorno ai 25KHz (e sono ottimista!) Implementare DRO, controllo closed loop e pure il GRBL in Arduino è fantascienza. Col Teensy magari no, ma non ci ho ancora giocato! Sarebbe sicuramente una casa da lasciar fare a Tereio. Io devo studiare ancora parecchio prima di poter anche solo pensare di provarci! In ogni caso se non ho letto male la teensy4.1 dovrebbe averne 4 di QEI, quindi l'hw per 3 assi e volantino ci sarebbe.

https://forum.pjrc.com/threads/58478-Te ... er-Library

Volendo semplificare la gestione dell'anello di posizione sulle righe, penso venga più semplice impiegare motorizzazioni in controllo velocità sul comando degli assi, perché come dicevo nel post di ieri sera, il closed-loop su stepper, per funzionare necessita di un feedback direttamente sul motore che alla fine per il controllo posizione dell'asse non usi. Oltretutto questo magari ti permetterebbe di riutilizzare motori e driver esistenti sulla macchina per gli assi Passando attraverso un semplice riferimento analogico, anche se la dinamica non sarebbe un granché, ma come si dice la botte piena e la moglie brilla non si può.

tecno67
Member
Member
Messaggi: 391
Iscritto il: lunedì 26 febbraio 2007, 14:25
Località: Prov. di Milano

Re: GRBLHAL e Teensy 4.X

Messaggio da tecno67 » martedì 1 dicembre 2020, 14:00

Quanto alla nota di hellfire sui SIL ecc. ricordo che le realizzazioni hobbystiche sono ovviamente escluse dall'ambito applicativo della direttiva macchine, DL81 ecc. Questo significa che per hobby si può fare quello che si vuole, ma ovviamente lo si deve fare da soli nella propria cantina e/o garage avendo cura di evitare di dar fuoco alla casa e lasciando fuori pure il gatto ed il cane perché a norma di legge non è permesso fare secchi nemmeno loro. Soprattutto se si vive in un condominio!
Quindi Junior73, se recuperi la fresa del tuo amico per portartela a casa ed usarla tu, OK. Se stai pensando di retrofittarla per lui con GRBL... Nun se pò faa!

Avatar utente
hellfire39
God
God
Messaggi: 3413
Iscritto il: domenica 16 dicembre 2012, 9:04
Località: AN

Re: GRBLHAL e Teensy 4.X

Messaggio da hellfire39 » martedì 1 dicembre 2020, 14:30

Quoto in pieno l'ultimo post.
Anche se è più corretto dire non si potrebbe fare. Temo che in Italia facciano un po' tutti come gli pare (almeno finché non ci scappa l'incidente, poi sono dolori!).

Aggiungo: per i controlli separati velocità-coppia e posizione, con gli stepper la vedo dura, perché i driver che utilizziamo noi sono giàcontrolli di posizione.
La parte di controllo dell'encoder/riga ottica esterna dovrebbe fare capo al driver, così come, nel settore industriale, fanno capo all'azionamento che pilota i brushless.
E' poi l'azionamento stesso che può utilizzare il doppio encoder, quello sul cu.. (opps volevo dire direttamente calettato sul motore) per il controllo delle correnti delle fasi del motore e quello esterno per il controllo di posizione.

tecno67
Member
Member
Messaggi: 391
Iscritto il: lunedì 26 febbraio 2007, 14:25
Località: Prov. di Milano

Re: GRBLHAL e Teensy 4.X

Messaggio da tecno67 » martedì 1 dicembre 2020, 17:23

Aggiungo: per i controlli separati velocità-coppia e posizione, con gli stepper la vedo dura, perché i driver che utilizziamo noi sono già controlli di posizione.
La parte di controllo dell'encoder/riga ottica esterna dovrebbe fare capo al driver, così come, nel settore industriale, fanno capo all'azionamento che pilota i brushless.
E' poi l'azionamento stesso che può utilizzare il doppio encoder, quello sul cu.. (opps volevo dire direttamente calettato sul motore) per il controllo delle correnti delle fasi del motore e quello esterno per il controllo di posizione.


Appunto quello che dicevo. Se si resta su un motore DC oppure su un BLDC con sensori Hall, il sistema si riduce a tre controllori PID di posizione che ricevono in ingresso gli impulsi step/dir e la riga ottica di retroazione, generando in uscita i tre segnali di pilotaggio in velocità.
Integrare il tutto in un Arduino UNO è proibitivo volendo una certa velocità. Farlo in un Teensy, ma anche in un Arduino a 32bit è sicuramente fattibile a questo punto si implementano anche le tre comparazioni dell'errore e si genera una uscita di allarme per mandare in stop il controllo. Magari a questo punto dato che un micro del genere costa relativamente poco, vale la pena di implementarlo come apparecchiatura a se e lasciare il controllo standard sia esso GRBL, GRBLHAL o anche uno qualsiasi dei controlli che si sta già utilizzando ora. I motori invece devono avere un ingresso analogico di riferimento in velocità (quindi niente step/dir).

Avatar utente
hellfire39
God
God
Messaggi: 3413
Iscritto il: domenica 16 dicembre 2012, 9:04
Località: AN

Re: GRBLHAL e Teensy 4.X

Messaggio da hellfire39 » martedì 1 dicembre 2020, 17:34

Sinceramente non mi piace mischiare le funzioni.
Preferisco un controller del motore che faccia SOLO il controller del motore ed un grbl che faccia solo grbl (ovvero si preoccupi di generare i profili di posizione interpolati ed inviarli ai controller dei motori in tempo reale).

Si tratta di due funzioni real-time, ognuna delle quali ha le proprie esigenze. Ho la forte impressione che convivano male.


Tra l'altro, oggi come oggi, il controllo delle correnti dei motori (parliamo prevalentemente di motori brushless) avviene in gran parte con l'ausilio delle periferiche hardware specializzate all'interno dei micro:
- blocchi QEI;
- blocchi Enhanced-PWM ad alta frequenza con gestione integrata del blanking per evitare di mettere in corto il ponte H;
- comparatori per il controllo della corrente, direttamente collegati in hardware al PWM;
- DSP integrato per velocizzare le operazioni matematiche;

Gestire efficacemente queste periferiche richiede un approccio molto verticalizzato che mal si accompagna alla filosofia HAL di grblHAL.
Inoltre, di solito ogni motore ha il suo micro dedicato, difficilmente si gestiscono più motori con un solo micro).

tecno67
Member
Member
Messaggi: 391
Iscritto il: lunedì 26 febbraio 2007, 14:25
Località: Prov. di Milano

Re: GRBLHAL e Teensy 4.X

Messaggio da tecno67 » martedì 1 dicembre 2020, 21:28

Magari a questo punto dato che un micro del genere costa relativamente poco, vale la pena di implementarlo come apparecchiatura a se e lasciare il controllo standard sia esso GRBL, GRBLHAL o anche uno qualsiasi dei controlli che si sta già utilizzando ora. I motori invece devono avere un ingresso analogico di riferimento in velocità (quindi niente step/dir).
Non voglio mescolare proprio niente come vedi:

-GRBL o un altro controllo genera i profili sotto forma di impusi step/dir.
-Il micro che fa i controlli closed-loop, gestisce i PID di posizione generando in uscita una richiesta di velocità per ogni asse su di una uscita analogica.
-L'azionamento di ogni singolo asse gestisce il loop di velocità con la tecnologia più congeniale in base al tipo di motore scelto.

La funzione di sorveglianza gestita dal micro che gestisce le posizioni infine invia una richiesta di arresto al generatore di profili se per qualsiasi ragione non riesce a mantenere l'errore di posizione entro un limite che non danneggi la lavorazione e questa è la funzione di sicurezza.

In definitiva è come se ci fosse un azionamento closed-loop per ogni asse, ma con la differenza che viene letta la posizione tavola e non la vite o il motore, che è poi l'organo che ci interessa controllare in posizione. Ovviamente si cerca di fare tutto in un micro solo per due motivi:

-L'economia di usare un solo micro ancorché prestante dato che anche alte capacità di calcolo costano poco e magari questo dispone pure dell'HW di lettura delle righe.

-Il fatto che per le ragioni spiegate nei post precedenti i closed loop stepper di comune uso non prevedono la possibilità di chiudere i loop di velocità e posizione su due differenti feedback. Ciò non toglie che il motore possa benissimo essere un closed-loop (quindi ci sarebbe sia l'encoder sul motore che la riga ottica) impiegato però in controllo velocità oppure in controllo coppia e non in controllo posizione (ovvero è un controllo posizione, ma noi lo usiamo solo per controllare la velocità o la coppia). E qui potremmo sostanzialmente avere sugli assi:

-Un motore DC con o senza tachimetrica (meglio con, anche se teoricamente con dinamica non esasperata se ne potrebbe fare a meno)
oppure
-Un brush-less con encoder (o resolver)
oppure
-Uno stepper closed loop in controllo velocità (che alla fine si comporta come un brush-less)
oppure
-Un inverter su motore asincrono, in controllo vettoriale sensor oppure sensor-less (non certo in V/F ed anche questo assomiglia ad un brush-less)

E' chiaro che la dinamica del tutto va calcolata, verificata ed ottimizzata (dove possibile!), ma in fondo è come si faceva il CNC nel passato , quando gli azionamenti intelligenti non esistevano.

E' ovvio che se i soldi non mancano, si può rifare tutto... mettere le viti a ricircolo... i brushless ecc. ed è decisamente più comodo avere un generatore di profili che li passa agli azionamenti intelligenti tramite rete dati real-time ad alta velocità (vedi Ethercat, Mecatrolink, CAN over IP ecc. ecc. altro che step/dir).
Ma è chiaro che allora non si usa certo GRBL.

Il vincolo da cui è partito Junior73 è 'Mantenere quanto più HW possibile dell'esistente anche a discapito delle performances'. E le viti con gioco sono purtroppo una di queste esigenze (oltre che un limite!.... Una revisione/registrazione delle chiocciole non la possiamo proprio fare eh! Junior)

safe60
Senior
Senior
Messaggi: 730
Iscritto il: venerdì 29 maggio 2009, 8:43
Località: Ferrara
Contatta:

Re: GRBLHAL e Teensy 4.X

Messaggio da safe60 » martedì 1 dicembre 2020, 21:46

Non c'entra molto con GrblHal ma forse puo' interessare qualcuno :

https://www.cnx-software.com/2020/10/13 ... out-board/
More Maiorum

Junior73
God
God
Messaggi: 3614
Iscritto il: lunedì 14 aprile 2014, 10:36
Località: Perugia

Re: GRBLHAL e Teensy 4.X

Messaggio da Junior73 » mercoledì 2 dicembre 2020, 0:04

Ehm mi sono perso !!! :? Provo a fare qualche considerazione a caso....poi vado a nanna :D

-Prendere una vecchia fresa manuale è per così dire in sintonia con il mio modo di ragionare
ma il retrofitting a cnc fatto di sostituzione di viti e guide e relativa elettronica non mi ispira molto .
Preferirei aspettare qualche tempo e trovare una macchina vecchia ma con guide e viti in uno stato decente
e magari con elettronica rotta. Non è detto che la "forte svalutazione" arrivi anche per modelli più recenti
(le prime convertite a cnc di circa 30 anni fa). Intanto continuo a divertirmi con il cemento .

-Vorrei formulare ragazzi un suggerimento per Tereio per questo Grblhal che sia "realizzabile" a costi accettabili
per un hobbista. Sentire la sua opinione ed intenzioni. Tenete sempre presente la "propensione" a spendere e le esigenze
di chi si rivolge al mondo opensource . Probabilmente Phil Barrett sta leggendo tentando di capire
le nostre "divagazioni " e spero che sia sia fatto un' idea conoscendo magari le capacità hardware del Teensy4.1.
Non ho le basi per capire , intuisco solo strade per lo più fatte di compromessi (e navigar ....) . In ogni caso rimane il fatto che avere un feedback della posizione, fosse anche solo un dro integrato nel programma IOsender o separato può risultare utile in certe lavorazioni dove la maggiore precisione è importante. Chiaramente è auspicabile , se si è in fase di progetto andare verso soluzioni meccaniche ed elettroniche idonee per i risultati che si vogliono ottenere ma questo costa molto . Nell'hobbismo non abbiamo il "vincolo " di certe "prestazioni" ma ci appassiona il tentativo di arrivarci .

@Safe60

Quanto del gcode tipico delle nostre frese riesce ad interpretare il Marlin? Sembra che questo Teensy 4.1 riscuota molto interesse.

Saluti

Avatar utente
hellfire39
God
God
Messaggi: 3413
Iscritto il: domenica 16 dicembre 2012, 9:04
Località: AN

Re: GRBLHAL e Teensy 4.X

Messaggio da hellfire39 » mercoledì 2 dicembre 2020, 8:44

@Tecno67
mi sa che viaggiamo su due mondi paralleli. Vivendo nel mondo dell'automazione industriale sono portato a ragionare con quello che utilizzo al lavoro, quindi, per quanto riguarda i posizionatori:
-driver + motore brushless con encoder (o resolver, ma di solito il resolver solo quando si vuole fare controlli di velocità).

Per questo motivo non riesco a ragionare in termini di soluzioni esoteriche in cui più controllori separati agiscono su differenti loop di controllo.
Le trovo soluzioni molto amatoriale e decisamente complicate da mettere a punto, soprattuto in questo mondo amatoriale dove l'utente medio è "plug and play" (o più che altro plug and pray!), ovvero voglio solo attaccare due fili, accendere e deve funzionare tutto.


In un solo micro la tua soluzione la puoi anche fare, ma, come ho già detto, la vedo difficile nell'ottica HAL del progetto grblHAL. Un progetto che vuole separare l'hardware dal sw. Ma qui vorresti delle funzioni calate direttamente sull'hardware, quindi specifiche di un solo micro.
Rimane sempre il problema delle prestazioni perché gestire i loop di 3 (o 4) assi e l'interpolatore al tempo stesso incomincia ad essere davvero oneroso.

Oggi stiamo andando verso un mondo di intelligenza distribuita: pensa ad un automobile: avrà all'interno un centinaio di ECU!. Oggi un micro, visto il suo costo irrisorio, non si nega a nessuno. Pure il singolo fanale anteriore ha il suo micro (o più di uno)

safe60
Senior
Senior
Messaggi: 730
Iscritto il: venerdì 29 maggio 2009, 8:43
Località: Ferrara
Contatta:

Re: GRBLHAL e Teensy 4.X

Messaggio da safe60 » mercoledì 2 dicembre 2020, 9:58

Junior73 ha scritto:
mercoledì 2 dicembre 2020, 0:04
...
@Safe60

Quanto del gcode tipico delle nostre frese riesce ad interpretare il Marlin? Sembra che questo Teensy 4.1 riscuota molto interesse.

Saluti
Il firmware Marlin ha decine (se non centinaia) di comandi ma essendo pensato piu' che altro per le stampanti 3D non credo vada bene per fresatura. E' vero che i principali comandi ci sono tutti ma, tanto per dirne una, mancano i cicli di foratura.

Il senso del link era quello di mostrare un'altra breakout board specifica per il teensy che, come dici, pare stia riscuotendo molto successo.
More Maiorum

Junior73
God
God
Messaggi: 3614
Iscritto il: lunedì 14 aprile 2014, 10:36
Località: Perugia

Re: GRBLHAL e Teensy 4.X

Messaggio da Junior73 » mercoledì 2 dicembre 2020, 10:02

sono portato a ragionare con quello che utilizzo al lavoro......
Esci dalla logica lavorativa e soprattutto "industriale" Hell .....vesti i panni dell'hobbista che cerca compromessi.

Quando mio cugino che vende prodotti agricoli tra cui lo zafferano mi è venuto a chiedere consiglio per una bilancia al milligrammo per piccole confezioni non gli ho suggerito quella certificata da 1000 euro e più pseudoitaliana ma la cinese da 20 euro con la pesata massima di 10g (che uso tutti i giorni)

https://www.banggood.com/Wholesale-0_00 ... rehouse=CN

perchè deve fare piccole confezioni da un grammo . L'errore confrontato con la mia al laboratorio al decimo di milligrammo è di 1-2-3 milligrammi ogni grammo. Era il migliore acquisto che poteva fare in base alle sue esigenze

Tornando a noi è possibile stabilire la velocità massima per singolo asse di Arduino Uno o altri micro di maggiore potenza a priori nella sola visualizzazione di una riga ottica in base alla risoluzione della stessa?

Con la logica delle bilance prendere una risoluzione di 0,005mm delle righe impegna troppo il micro?
L'errore delle righe ottiche cresce con la distanza o si mantiene abbastanza costante?
Altri metodi di misura rilevabili ? Stampanti a getto etc?


https://it.aliexpress.com/item/10050013 ... hweb201603_


@tecno67

Il discorso di Hell sull'utilizzo di più di un micro a costi accessibili se c'è necessità è giusto quanto maggiore è l'interazione con la lavorazione a patto che sia una cosa realizzabile a livello elettronico.
Quello che cambia è il grado di interazione delle rilevazioni sulla lavorazione:si può andare dalla semplice segnalazione al mettere in pausa la macchina se l'errore supera 1 decimo, 5 centesimi , fino a far intervenire l'operatore muovendo fisicamente gli assi e ricalcolando il tutto per io movimenti successivi , o addirittura correzioni automatiche per X assi.

@Safe60

Non ho seguito il mondo delle stampanti 3d ma spero che ci saranno schede che potranno essere caricate con firmware differenti a seconda dell'utilizzo in futuro.

Saluti



Saluti
Non hai i permessi necessari per visualizzare i file e le foto allegati in questo messaggio. Per visualizzare tali file devi registrarti ed effettuare il Login

Avatar utente
hellfire39
God
God
Messaggi: 3413
Iscritto il: domenica 16 dicembre 2012, 9:04
Località: AN

Re: GRBLHAL e Teensy 4.X

Messaggio da hellfire39 » mercoledì 2 dicembre 2020, 10:20

@Junior73

Il concetto che volevo esprimere è:
sono convinto che non valga la pena dedicare del tempo a soluzioni strane, con più oggetti in cascata che vanno programmati, debuggati, configurati, tarati, ecc.

Al alvoro io ho un asse elettrico. Collego tutto, lo configuro, fatto!
Da hobbista ho i miei driver, li collego, cambio due dip switch, fatto!
Al massimo prendo i closed loop e, se strettamente necessario, provo a ritoccare i PID.

Soluzioni più complicate possono servire a passare il tempo, come sfida personale, ma non sono pratiche, nè semplici da attuare. Richiedono tempo, competenza e strumenti. E qui usciamo proprio dal punto di vista hobbistico per il 99% degli utenti.
Ne vale la pena?

------------------------

P.S. se tuo cugino utilizza la bilancia per il commercio, non sono proprio sicuro che lo possa fare. La bilancia non dovrebbe avere un certificato di taratura? La bilancia cinese ha il certificato di calibrazione o qualche ente italiano l'ha certificata?


-----------------------

Per la velocità degli assi non posso risponderti perché è una funzione NON implementata. Puoi sapere che con il teensy (vedi uno dei link precedenti) si raggiungono frequenze superiori a quelle gestibili dai driver in commercio, ma non c'è nulla sulla retroazione di tre assi.

Junior73
God
God
Messaggi: 3614
Iscritto il: lunedì 14 aprile 2014, 10:36
Località: Perugia

Re: GRBLHAL e Teensy 4.X

Messaggio da Junior73 » mercoledì 2 dicembre 2020, 11:04

Non dobbiamo essere noi a fare il lavoro di integrazione del visualizzatore di quote all'interno di GrblHal ma solo proporre l'idea. Nel mio caso probabilmente non riesco nemmeno a collegare un Arduino Uno ad una riga ottica senza il programma già scritto e lo schema dei collegamenti (ben dettagliato!).
La richiesta di precisione a me è arrivata più volte sia da parte dei laseristi sia parte di piccole officine meccaniche senza cnc con cui sono in contatto ,ma ho dovuto dire di no in quanto nemmeno riesco a misurare l'errore oltre certe misure. In altri casi ho fatto un campione al meglio che potevo ed è andata bene (pura fortuna).

Le esigenze degli hobbisti possono essere anche elevate e GrblHal è rivolto a tutti. Se guardi Linuxcnc ha soluzioni come il Tcp, un numero di assi "esagerato ", il thcad per il plasma etc tutte soluzioni che i più non utilizzano ma gli sviluppatori hanno comunque deciso di integrarli nel tempo.


OT

la contestazione del prodotto avviene in genere per aver superato le soglie stabilite per tipologia di prodotti che sono piuttosto larghe nel settore alimentare a differenza di quello nostro cosmetico/farmaceutico , chimico . La bilancia certificata nel suo laboratorio alimentare la usa per olio , tartufi etc ma con scale di pesatura diverse e relativi costi diversi.
E' molto difficile che nasca una contestazione da parte dell'acquirente o dello "stato" sul peso dei prodotti nel settore alimentare. Di solito ci sono altri aspetti ben più gravi nel confezionamento che vanno a guardare nelle ispezioni.

Fine OT

Saluti

Avatar utente
hellfire39
God
God
Messaggi: 3413
Iscritto il: domenica 16 dicembre 2012, 9:04
Località: AN

Re: GRBLHAL e Teensy 4.X

Messaggio da hellfire39 » mercoledì 2 dicembre 2020, 11:45

Beh, qui il discorso si allarga. Nulla costa andare sui forum di grblHAL e proporre idee. Saranno poi gli sviluppatori a vagliarle e decidere se svilupparle.

Sul discorso "hobbista" ed "esigenze elevate" ho sempre molti dubbi.A meno che non si parli di professionisti "mascherati" da hobbisti. Ovvero pesone che producono e vendono prodotti in nero.

Anche perché hobbista, di solito, significa pochi soldi ed esigenze elevate, di solito, significa TANTI soldi :mrgreen:


---------------
OT
non discutevo del fatto che qualcuno possa contestare il peso, ma che sia una pratica legale.

rosettacnc
Member
Member
Messaggi: 209
Iscritto il: venerdì 6 settembre 2019, 8:18
Località: Vicenza

Re: GRBLHAL e Teensy 4.X

Messaggio da rosettacnc » mercoledì 2 dicembre 2020, 12:28

Parlo da hobbista in altri settori: fotografia e musica, pianoforte.

Un hobbie è qualcosa che ti prende molte energie ma che deve essere fonte di soddisfazioni o non si sostenta.
L'hobbie lo scegli, è una cosa che ami e da cui vuoi poi ottenere soddisfazione altrimenti è farsi male :)

Il succo del discorso è sempre uno:

Meno spendi più spendi, in quanto ri-spendi.

Compri una macchina fotografica perchè sta nelle tue "corde" ma come appassionato ed hobbista ti accorgi che i limiti imposti dal mezzo non ti permettono di raggiungere quel grado di soddisfazione che tiene vivo l'hobbie e capisci che spendendo quel poco di più, anche facendo sacrifici, dal tuo hobbie potrai ottenere quelle gratificazioni e soddisfazioni altrimenti limitate dal mezzo. Speso uno, ri-speso due, etc.

Stesso con la musica.
Beh sono alle prime armi quindi spendo poco.
Ma ad imparare e non essere più tu il limite nel sistema ci passa poco e si deve rispendere per avere qualcosa che stia al passo.

In tutti settori l'hobbie è quel pozzo nero in cui finiscono cifre innimaginabili per chi non condivide lo stesso interesse...

Rispondi

Torna a “Controlli Seriali, Usb e Ethernet”