MECCANICA e DINTORNI

Sto scrivendo del codice che riconosce i protocolli dei calibri: il 24*2(quello normale) il 7*BCD(piuttosto raro) e il bin6(quello che vi interessa). Come ho fatto? Faccio contare al pic i fronti di discesa del clock finché il segnale non cambia per troppo tempo, così ho 49 fronti per il primo protocollo, 28 per il secondo e 24 per il terzo. Ho avuto quest'intuizione geniale proprio oggi pomeriggio e sembra che funzioni.
Mi rimane da fare le routine di lettura e le varie conversioni, tuttavia si tratta solo di simulazioni al pc, per essere sicuro che funziona dovrete provare i vari HEX che vi manderò.
Con calma, pazienza e precisione risolvo pure questa...

Per chi fosse interessato, sul gruppo yahoo di shumatech se ne è parlato tempo fa, pare che lui abbia risolto.
In allegato c'è un'immagine che mostra i tre protocolli e le loro differenti strutture.
Quello grosso e brutto in mezzo è il vostro.
E' un brutto protocollo perché il rate con cui manda il dato è fisso, circa 7 Hz, quindi il fast reading mode non può essere impostato. E' più lento del protocollo 24*2 col fast reading mode, che va a 50Hz, ma molto meglio del rate nativo a 3Hz.
Oltretutto, pare che questi calibri dopo circa 4 minuti e 40 secondi si spengono e non mandano più dati, finché qualcuno non li muove: dovrò ricordarmi di dire al DRO di non aspettare i dati in eterno.

GRANDE Jarni!!

Il fatto che si spengano e' vero!! aspetto l'HEX per il test

Allora, provate questo HEX e segnatevi i numeri che vi dice(sperando che funzioni).
A seconda dei numeri riesco a capire che protocollo hanno i calibri.

Versione preliminare.
Si dovrebbero leggere i calibri col nuovo protocollo.
Non è definitivo, lo devo perfezionare.

Ciao Jarni,
PREMETTO: lo dico solo "pour parler",
visto che ci sono divesi tipi di calibri, sarebbe un casino fare piu' versioni di software,
anche perche' l'utente potrebbe impiccarsi nello scegliere e programmare la pic.
Potresti realizzare sempre nello stesso soft, piu' blocchi di routines che si possono scegliere nel menu iniziale, A, B, C, etc.
Mi spiego.
Senza aggiungere o modificare l'hardware, includi una routine di "set" tenendo premuto per 10 secondi un tasto (premendo quel tasto, lo mandi un una sub con un ciclo for nextcon dentro una pausa, se si tiene premuto per 10"" allora finisce il ciclo e va nei settaggi altrimenti esce dalla sub ed esegue la sua funzione originaria)
in questo sottomenu' di settaggio si possono scegliere e provare i vari tipi di calibri.
una volta trovato quello giusto si stocca in una locazione di memoria che si andra' a leggere quando la pic esegue il ciclo di inizializzazione.
spero di aver reso quello che stavo pensando.

E' chiaro che se il programma gia' fa' quello che ho descritto allora scusa.....
Io per ora il DRO NON L'ho ancora costruito.....

Per ora il programma funziona più o meno così: riconosce automaticamente il protocollo usato dal calibro e lo imposta per i vari assi, almeno da quello che risulta dal software di simulazione.
Attualmente è in grado di gestire sia i calibri "normali" con protocollo 24x2 sia quelli "nuovi" col protocollo a 24bit, quindi non è una versione specifica, è una versione migliorata che può essere installata da chiunque.
Effettivamente ci sono proprio due routines A e B che leggono ognuna il suo protocollo...
Mi manca la gestione del protocollo BCD, usato da certi calibri che mi pare nessuno abbia mai incontrato qui.
Il protocollo Digimatic dei calibri Mitutoyo non è previsto, così come il protocollo in quadratura degli encoder e di certe righe digitali professionali(ma questo perché è un protocollo "difficile" che necessiterebbe di riprogettare tutto il DRO, software e circuito, quindi è meglio usare una schedina di interfaccia).

La funzione di selezione manuale non l'ho messa ma si può sempre implementare.
Se avessi un tasto in più sarebbe facile, basta seguire lo stesso meccanismo che c'è sul sesto tasto, che permette di impostare e memorizzare nella eeprom le direzioni dei tre assi.

Ciò che mi preoccupa è che il rate di trasmissione dei nuovi calibri è fisso a 7.5Hz, non hanno il fast reading mode, quindi c'è il rischio che su tre assi che usano quel protocollo si potrebbe avere un aggiornamento complessivo delle misure di 2.5Hz e anche meno.
Dovrei fare alcuni test per verificare una mia idea, forse valida per tutti i calibri: invece di aspettare che il calibro invii i dati FORSE se gli mando il segnale di azzeramento lui mi manda il dato subito dopo, quindi potrei "prendere" i dati tutte le volte che mi servono, senza stare ad aspettare... è una possibilità che andrebbe verificata.

FUNZIONA!!!

La lettura del calibro "strano" ora e' corretta o quasi c'e' un centesimo in meno rispetto al calibro sempre tranne che a 0 (errore di arrotondamento?!).
Inoltre ho notato una certa lentezza nell'aggiornamento dei dati anche nel calibro che prima andava in FAST.
A questo proposito forse e' colpa del calibro che se ricordi ci metteva un po ad andare in fast e mi avevi fatto una versione del FW con delay di 5 secondi.

Dimenticavo,
ho visto che hai eliminato la scritta in alto ....pensavo ci potresti mettere l'informazione degli RPM sempre presente?! così avanza anche un bottone per altri funzioni.

L'errore di qualche centesimo è strano, dalle simulazioni non l'ho notato, vedrò di indagare.
La lettura va lenta perché il fast reading non è attivo, è ancora una versione preliminare.
Stasera vado da nuvolini a perfezionare il programma, se funziona domani posto il programma definitivo.
La riga in alto non c'è perché... mi sono scordato di metterla.
Non la posso sostituire col tachimetro perché a causa dell'interrupt interferirebbe con la lettura dei calibri.
Comunque sono felice che funzioni.

Grazie Jarni per il tuo interessamento ai nostri problemi!!

Ok, femminucce , questa versione ha il fast reading mode che si attiva dopo 10 secondi, tempo d'attesa necessario con alcuni calibri.
L'ho testato sul dro di nuvolini e funziona. Purtroppo i calibri "anomali" rallentano la velocità di aggiornamento dei dati degli assi.
Stamattina ho quindi aggiunto una modifica nelle routine di lettura, che teoricamente dovrebbe raddoppiare il refresh.
Provatelo e se non va fatemelo sapere.
Sto pensando di metterci una cosa nuova: se all'accensione si tiene premuto un certo tasto si può passare dalla modalità fresatrice alla modalità tornio, e la scelta viene memorizzata in eeprom.
La differenza è che gli assi nella modalità tornio si chiamano X, Y1 e Y2, e l'asse X(slitta trasversale) da' una misura raddoppiata, in modo che la misura che leggiamo si riferisce al diametro del pezzo, non al raggio.
Oggi o stasera ci lavoro...

A nome mio e di quanti hanno fatto il tuo DRO grazie.
Funziona alla perfezione, certo più cose si aggiungono e meglio è.
Comunque la mia filosofia rimane la stessa" a caval donato non si guarda in bocca" quindi bravo Jarni.

Bye bye.
Nuvolini.

Hai provato l'ultimo file? Dovrebbe migliorare quella cosa della velocità di aggiornamento.

Comunque basta coi ringraziamenti, in fondo tutto questo lavoro l'avrei dovuto fare comunque per la versione IV.
Piuttosto grazie a nuvolini che mi ha dato modo di osservare direttamente il comportamento di questi particolari calibri... nonché di vedere la sua BF20, il suo tornio e la CNC in "cartone pressato".

...se ti rubano tutte le macchine utensili tranne la scheda di sviluppo per i PIC sai chi devi sospettare...

Allora alcuni test veloci che ho fatto risultato ...

Tutto PERFETTO!!.

Unici 2 appunti:
1)Rimane quel centesimo in meno sul DRO, a questo proposito ho notato che la lettura in pollici e' identica quindi immagino che in mm sul DRO venga arrotondato per difetto mentre sul calibro per eccesso.
2) Il calibro lento se montato sull'asse X non viene rilevato (NODATA)

1) Il centesimo in meno riguarda il calibro normale o quello col protocollo nuovo?
Nel primo caso è spiegabile, poiché il protocollo 24x2 manda il dato in unità proporzionali al pollice, quindi la conversione fa casino con l'ultima cifra.
Ad esempio, 1.001 pollici sarebbero 25.4254, che arrotondati sono 25.43 sul calibro, ma il dro fa dei calcoli che gli portano 25.42.
In ogni caso verifica che, impostando la stessa unità di misura sul dro e sul calibro, i dati visualizzati siano gli stessi.
Sappi che comunque sto lavorando pure a quello, basta moltiplicare per 10 all'inizio, controllare l'ultima cifra e poi dividere per 10 aggiungendo 1 se necessario... ma questi sono fatti miei.

2) Il calibro lento è effettivamente mooooolto lento. L'asse X è il primo che viene esaminato per stabilire il protocollo di comunicazione, significa che anche 10 secondi di attesa sono pochi, il calibro inizia a trasmettere i dati ancora più tardi. Li porto a 12? 15? 30?

P.S.
Fra l'altro, stamattina ho trovato un piccolissimissimissimo nonché stupido errore nelle routine di lettura che potrebbe causare ogni tanto uno strano "ballamento" della misura di un asse. Ovviamente l'ho corretto.
Mi rimane da fare quella cosetta per il tornio, poi posterò la versione spero definitiva.
E' chiaro che se altre persone in un altro forum(ehmm... ) hanno di questi problemi siete liberissimi di passar loro gli HEX che posto qui.