Buongiorno, scusate se approfitto del forum, mi rivolgo qui sempre quando non riesco a trovare nulla che possa risolvere un mio problema.
Ho un guasto su una macchina che leggeva dei barcode in movimento, utilizzando un HOA6480-001 o similare.
Inutile tentare qualunque riparazione, se veniva presa ripetutamente a martellata sarebbe stata messa meglio, e come se non bastasse, chi ha prodotto quel abominio non esiste più da almeno una ventina d'anni.
Montava oltre al sensore, un operazionale quadruplo, una PIC e un'integrato che suppongo fosse stato un rs232, dato che comunica con il resto via seriale.
Avrei bisogno di riprodurre la cosa in qualche modo, ho provato a cercare ovunque ma ottengo sempre come risposta schedini che utilizzano cmos per la lettura, che potrei anche usare, se non fosse che quel sistema di lettura non è abbastanza veloce (ricordo che sono in movimento).
Qualcuno ha esperienza nell'uso di quei sensori a riflessione per la lettura di barcode ?
Parliamo di applicazione low-cost o hai a disposione un buon budget?
Gli scanner con sensore CMOS sono lenti come hai già avuto modo di vedere.
Per leggere codici in movimento in modo affidabile hai bisogno di un laser scanner e la maggior parte di questi dispositivi hanno già integrate una o due seriale RS232 per dialogare direttamente con un PC.
Sarebbe utile sapere anche di che tipo di codice a barre si tratta perché alcune tipologie non prevedono caratteri di start/stop (ad esempio il pharmacode) ed in quel caso gli scanner hanno un po' di problemi.
I codici sono tutti uguali e sono CODE 25, tutti alla stessa distanza uno dall'altro ed ho pure un punto di riferimento che mi permetterebbe di usare un sistema "strobo" con lettore Cmos/CCD, ma dovrei apportare significative modifiche che comunque sarei disposto a fare, ma non ho fatto test in tal senso, e quindi chiedevo qui proprio la condivisione di esperienze in tal senso.
I barcode viaggiano ad una velocità di circa 8 al secondo (magari fossero prodotti !!!!) e per assurdo NON c'è la necessità che tutti vengano letti, la lettura è solo una verifica di ulteriore conferma "saltuaria", anche uno su cinque sarebbe accettabile.
Budget dipende da cosa uno intende per LOW COST, quella soluzione sarebbe pure da replicare per altri che prima o poi si troveranno nella stessa situazione, trattandosi di un qualcosa prodotto nel 1993.
Io sto parlando di dispositivi industriali ed il costo naturalmente è proporzionato.
Ad esempio in questo momento in laboratorio ho un Datalogic DS2100N recuperato da una linea dismessa e l'ordine di grandezza per il nuovo è di 700/800€ (usato sulla baia si trova per 250/300€).
Il code 25 (anche detto code "interleaved 2 of 5") lo legge senza problemi.
Se vuoi posso provarlo in velocità e vedere come si comporta (potrei stampare 5/6 codici in colonna e fare una rapida scansione osservando quanti ne legge).
Da quel che ho visto supera notevolmente quel prezzo, e a quel punto siamo sicuro fuori buget, perchè una macchina simile nuova siamo sul tre mila euro, spendere più di mille oltre ai tempi di modifica per recuperare qualcosa del 1993, comincia non valerne più la pena.
Per quello pensavo di replicare il sistema attuale, economico ma che ha funzionato fino ad oggi.
Ho trovato pochissime informazioni, giusto un paio di schemi con proprio delle PIC come quello in uso, ma nessun codice da mettergli dentro.
Se ce la fa una PIC dell'antichità, non vedo perchè non sia possibile replicare tutto con un UNO, o meglio ancora un Mega o un ESP32 !
Più che altro il codice che non comprendo, perchè l'hardware è elementare.
Ce la fa di sicuro, io chiedevo del budget proprio per capire in che direzione andare perché se uno ha bisogno di affidabilità e non ha problemi nello spendere cifre simili, non ha senso star li sabattersi a fare qualcosa quando ci sono dispositivi industriali che lo fanno bene e sono già pronti all'uso.
Questo non è il tuo caso ovviamente e quindi l'idea di ricostruire il dispositivo che si è guastato ha più senso.
Il sensore HOA6480 è di fatto un sensore che è in grado di leggere il bianco ed il nero del tuo codice a barre.
Quindi in sostanza devi capire come prima cosa se si tratta di code 25 "normale" oppure "interleaved" (una fotografia potrebbe aiutare).
A quel punto si tratta di misurare la durata del segnale "nero" per il digit 0 e quella per il digit 1 e stessa cosa per il segnale "bianco".
Ad esempio queste sono le specifiche dell'algoritmo per la versione "interleaved" (che per quanto ne so è quello più diffuso).
Avevo trovato anch'io la pagina delle specifiche dell'algoritmo, ma l'implementazione software mi mette in agitazione, perchè sono un abituato alle cose che "non cambiano", inteso nel senso che in questo caso e giusto per fare qualche esempio, come avviene la lettura dello stato 1 o 0 su un pezzo di carta che non ha solo bianco e nero assoluti ?
E quello che c'è prima e dopo ?
E come calcolo la lunghezza delle barre, dato che ci sono codici stampati più piccoli e codici più grandi ?
Ho avuto parecchio a che fare con questi lettori a riflessione, mi sono sempre posto il quesito, ho sempre pensato tra me e me "ok, quando sarà il momento e se servirà, studierò la cosa".
Se prendi il datasheet del sensore puoi vedere che sul pin "output" avrai un valore in tensione che è proporzionale alla riflettività di quello che gli metti di fronte.
Una superficie che riflette il 50% della luce che lo colpisce genererà un valore in tensione di 1.1V
Una superficie nera (teoricamente 0%, nella realtà qualcosa di più) produrrà una valore di 4.5V
Una superficie bianca (teoricamente 100%) produrrà un valore di 1.0V
Nel circuito guasto dici che ci sono 4 operazionali, probabilmente usati per realizzare un circuito comparatore o un trigger di Schmitt cosi da "squadrare" il segnale ed evitare valori intermedi.
Per quanto riguarda il software, tutto quello che c'è prima e dopo è la cosiddetta "quiet zone".
Dovresti implementare un algoritmo che legge le transizioni del sensore e memorizza la durata di ciascun impulso ad esempio in un array.
A quel punto vai a fare la decodifica: come prima cosa cerchi il carattere di start, se manca scarti, il pacchetto. Se c'è prosegui con la decodifica fino al carattere di stop.
La fregatura con l'interleaved è che devi tenere conto sia della durata del nero che quella del bianco.
Cosi di primo acchito, la soluzione migliore mi sembra quella di usare l'interrupt esterno configurato sull'ONCHANGE e ogni volta che viene chiamata la ISR fai la differenza.
L'array a questo punto potrebbe essere di struct cosi da memorizzare sia la durata che il tipo (bianco/nero).
Sicuramente, ci sono anche dei residui di un trimmer per la regolazione del guadagno.
In teoria non dovrebbe nemmeno servire alcun trigger di Schmitt, con quel sensore, perchè già di suo in condizioni quantomeno dignitose, restituisce qualcosa di già utilizzabile.
Cerco meglio se trovo qualche bozza di codice di qualcuno che si è già sbattuto in modo da portarmi avanti.
Ho provato a cercare qualcosa anche io per curiosità, ma senza successo.
Io inizierei intanto a mettere in piedi un sistema per la misura della durata dei segnali magari aiutandoti con un signal tracer se ce l'hai disponibile (si trovano per pochi euri anche su Amazon).
Quando hai i tuoi tempi tutti belli messi in fila, inizi a ragionare sull'algoritmo per la decodifica tenendo conto delle caratteristiche della codicia 2/5 interleaved.
Così, solo come possibile alternativa, QUESTO fa fino a 300 letture/secondo e, un mio distributore, lo ha a catalogo per poco più di 50€ ... si interfaccia via USB quindi occorre una scheda Arduino che abbia la USB Host (sicuramente emulerà una seriale quindi non ci dovrebbero essere grossi problemi) ... vedi un po' tu ...
Guglielmo
P.S.: a catalogo hanno diversi modelli con diverse capacità e velocità di scansione.
P.P.S.: il manuale non riporta le specifiche di programmazione dettagliate ma solo indicative (bisogna vedere se sono disponibili a fornire il manuale di programmazione dettagliato), comunque conferma che va vista come una "Communication Device Class".
Si, infatti, eventualmente può essere un'alternativa ... il solo problema, come dicevo è che, come vedi a pag. 17 del manuale, le specifiche di protocollo sono del tutto insufficienti e bisogna contattarli per avere le specifiche complete per interfaccialo
Di solito il protocollo è liberamente configurabile via software utilizzando un qualche tool messo a disposizione dal produttore.
Questo almeno è sempre ciò che ho trovato con i lettori di codice a barre di tipo industriale che mi sono capitati per le mani (Sick, Datalogic, Cognex etc etc).
Interessante una cosa, il NLV-4001 viene dichiarato per "300 sps" ma Scan per Second potrebbe significare tutto e nulla, mentre esiste il modello superiore NLV-5201 che viene dichiarato "100 FPS", che lascia intendere che "fissa" fino a 100 immagini al secondo, quindi in teoria più indicato per barcode in veloce movimento.
E infatti dal manuale "The high-speed CMOS sensor (100fps) and high-speed CPU enables stress-free scanning and fast response from fast movement and poor/bright lighting conditions"
