Streckkod (och läsare)
Re: Streckkod (och läsare)
Samma skrivare, som jag skrev ut paneldekalen på.
Ser inget behov av QR, även om den förmodligen klarar det (det handlar ju bara om 64 bitar data)
Dvs http://elektronikforumet.com/forum/view ... =2&t=66027
och
http://elektronikforumet.com/forum/view ... 65#p944317
Ser inget behov av QR, även om den förmodligen klarar det (det handlar ju bara om 64 bitar data)
Dvs http://elektronikforumet.com/forum/view ... =2&t=66027
och
http://elektronikforumet.com/forum/view ... 65#p944317
Re: Streckkod (och läsare)
Det finns ju ett par olika parametrar här att tänka på här... 
Först, är behovet enbart för att skapa produktstrukter inom
monteringen av prylarna? Eller behöver märkningen överleva
produktens hela beräknade livslängd? Det påverkar val av
etikettmaterial och skrivarteknik.
Om etiketten behöver överleva över en lite längre tid så behöver
ni fundera på vilka miljökrav det finns. D.v.s vilka ämnen och
t.ex lösningsmedel som den kan komma att utsättas för.
Om ni redan har valt skrivare så har ni ju en begränsning av tillgängliga
streckkodstyper redan där och kanske även etikettmaterial.
När det gäller avläsning så är det i princip inget problem med alla
moderna scanners oavsett om det är traditionella handscanners
eller 2D scanners, om ni inte väljer någon väldigt exotisk streckkod.
När det gäller strukturinläsningen så får man antingen (om etiketten inte
innehåller någon identifikation) se till att det görs i en viss ordning eller
att man har en direkt uppslagning av varje pryl i samband med avläsningen
så att det går att verifiera vad det är och markera den som avläst.
En annan sak är om alla inkluderade delar kommer att vara av intern
tillverkning eller om ni vill även vill läsa av serienummer på inköpta delar
(vanligt för t.ex LiPo batterier och liknande som har säkerhetskrav, men
det kan finnas andra orsaker till att ha spårbarhet även på inköpta detaljer).
Då har ni ju inte prylen i erat interna system (om man inte får datafiler
från tillverkaren eller läsar av detaljerna vid godsmottagningen) och får
kanske ha speciell hanteringen kring dom.
Vill ni ha något slags "processäkring" i monteringen? D.v.s verifiera att
rätt delar monteras tillsammans (och att alla delar som ska monteras
faktiskt också monteras)? Det kan i så fall byggas in i rutinerna för
scanningen vid inläsningen av strukturerna ("kopplingen").
Jag antar att ni även vill ha ett larm vid denna avläsning så att det inte
av misstag monteras två underdelar med samma serienummer på olika
produkter, det sabbar ju spårbarheten. Ni vill sannolikt även logga t.ex
olika tidpunkter och liknande i individ/serienummer databasen.
När det gäller val av streckkod så är Code39 robust men dock lite mer
"skrymmande" än de lite mer moderna koderna. Code128 (gärna Code128C för
att även få komprimeringen) är ett vanligt val. Ett problem kan vara att Code128C
ger en variablel längd på streckkoden, den beror på den aktuella mixen av tecken,
det är enbart två numeriska tecken i följd som "komprimeras" (om jag inte
minns helt fel, det är lätt att kolla upp). När det gäller "interleave 2-5" så har
jag för mig att den är kompakt men lite känslig, jag minns inte exakt men
det är något med att det är flera tjocklekar på strecken t.ex. Jag kan missat
något i detaljerna kring olika koder, jag jobbar mer med systemen runtikring.
När det gäller design av själva streckkoden så behöver ni även ta ställning
till sådant som t.ex om koden ska stå i klartext under streckkoden.
Sedan tillkommer efterbehandlingen av serienummer och strukturdata. Ni kanske
vill skicka med serienummeruppgifter som den del av leveransdokumentationen.
Det lär även behövas rutiner för att plocka fram information om en viss
produkt (individ) i efterhand för reparations- och garantibehov.
Sen, när ni i alla fall har individuella serienummer på prylarna så kanske man
vill koppla på sådant som versioner på laddad firmware och liknande.
Jag har försörjt mig bl.a på system för dessa behov senaste 30 åren.
Först, är behovet enbart för att skapa produktstrukter inom
monteringen av prylarna? Eller behöver märkningen överleva
produktens hela beräknade livslängd? Det påverkar val av
etikettmaterial och skrivarteknik.
Om etiketten behöver överleva över en lite längre tid så behöver
ni fundera på vilka miljökrav det finns. D.v.s vilka ämnen och
t.ex lösningsmedel som den kan komma att utsättas för.
Om ni redan har valt skrivare så har ni ju en begränsning av tillgängliga
streckkodstyper redan där och kanske även etikettmaterial.
När det gäller avläsning så är det i princip inget problem med alla
moderna scanners oavsett om det är traditionella handscanners
eller 2D scanners, om ni inte väljer någon väldigt exotisk streckkod.
När det gäller strukturinläsningen så får man antingen (om etiketten inte
innehåller någon identifikation) se till att det görs i en viss ordning eller
att man har en direkt uppslagning av varje pryl i samband med avläsningen
så att det går att verifiera vad det är och markera den som avläst.
En annan sak är om alla inkluderade delar kommer att vara av intern
tillverkning eller om ni vill även vill läsa av serienummer på inköpta delar
(vanligt för t.ex LiPo batterier och liknande som har säkerhetskrav, men
det kan finnas andra orsaker till att ha spårbarhet även på inköpta detaljer).
Då har ni ju inte prylen i erat interna system (om man inte får datafiler
från tillverkaren eller läsar av detaljerna vid godsmottagningen) och får
kanske ha speciell hanteringen kring dom.
Vill ni ha något slags "processäkring" i monteringen? D.v.s verifiera att
rätt delar monteras tillsammans (och att alla delar som ska monteras
faktiskt också monteras)? Det kan i så fall byggas in i rutinerna för
scanningen vid inläsningen av strukturerna ("kopplingen").
Jag antar att ni även vill ha ett larm vid denna avläsning så att det inte
av misstag monteras två underdelar med samma serienummer på olika
produkter, det sabbar ju spårbarheten. Ni vill sannolikt även logga t.ex
olika tidpunkter och liknande i individ/serienummer databasen.
När det gäller val av streckkod så är Code39 robust men dock lite mer
"skrymmande" än de lite mer moderna koderna. Code128 (gärna Code128C för
att även få komprimeringen) är ett vanligt val. Ett problem kan vara att Code128C
ger en variablel längd på streckkoden, den beror på den aktuella mixen av tecken,
det är enbart två numeriska tecken i följd som "komprimeras" (om jag inte
minns helt fel, det är lätt att kolla upp). När det gäller "interleave 2-5" så har
jag för mig att den är kompakt men lite känslig, jag minns inte exakt men
det är något med att det är flera tjocklekar på strecken t.ex. Jag kan missat
något i detaljerna kring olika koder, jag jobbar mer med systemen runtikring.
När det gäller design av själva streckkoden så behöver ni även ta ställning
till sådant som t.ex om koden ska stå i klartext under streckkoden.
Sedan tillkommer efterbehandlingen av serienummer och strukturdata. Ni kanske
vill skicka med serienummeruppgifter som den del av leveransdokumentationen.
Det lär även behövas rutiner för att plocka fram information om en viss
produkt (individ) i efterhand för reparations- och garantibehov.
Sen, när ni i alla fall har individuella serienummer på prylarna så kanske man
vill koppla på sådant som versioner på laddad firmware och liknande.
Jag har försörjt mig bl.a på system för dessa behov senaste 30 åren.
Re: Streckkod (och läsare)
Sodjan, gissar att jag behöver diskutera saker med dig.
Det handlar om dels egenproducerad utrustning, till exempel vår reglerutrustning, som normalt består av två delar, dvs två nummer, i vilket det ena är kopplat till kalibreringsdata.
Utrustningen består då av två eller tre kort, 1 AD-kort med eget serienummer och kalibreringsdata, ett cpu-kort och i vissa lägen ett webserverkort, alla med egna nummer, vilket kopplas till ingående komponenter, kort och programrevisioner etc.
Dels inköpt utrustning, till exempel kompressorer, frekvensomformare mm.
Tanken är att vid eventuella reklamationer och/eller support, kunna få fram en total bild av maskinen i fråga, samt även kunna följa upp kvaliteten.
(vissa av våra leverantörer "kräver" dessutom serienummret vid ev reklamation och/eller support)
Etiketterna som sådana överlever med största sannolikhet maskinerna, så där ser jag inga problem, de klarar dessutom rätt svåra miljöer, typ lösningsmedel, nötning osv.
Eftersom de inte sitter utomhus, så är UV ingaproblem, (de klarar 2 år i direkt solljus utan att mattas).
Det handlar om dels egenproducerad utrustning, till exempel vår reglerutrustning, som normalt består av två delar, dvs två nummer, i vilket det ena är kopplat till kalibreringsdata.
Utrustningen består då av två eller tre kort, 1 AD-kort med eget serienummer och kalibreringsdata, ett cpu-kort och i vissa lägen ett webserverkort, alla med egna nummer, vilket kopplas till ingående komponenter, kort och programrevisioner etc.
Dels inköpt utrustning, till exempel kompressorer, frekvensomformare mm.
Tanken är att vid eventuella reklamationer och/eller support, kunna få fram en total bild av maskinen i fråga, samt även kunna följa upp kvaliteten.
(vissa av våra leverantörer "kräver" dessutom serienummret vid ev reklamation och/eller support)
Etiketterna som sådana överlever med största sannolikhet maskinerna, så där ser jag inga problem, de klarar dessutom rätt svåra miljöer, typ lösningsmedel, nötning osv.
Eftersom de inte sitter utomhus, så är UV ingaproblem, (de klarar 2 år i direkt solljus utan att mattas).
Re: Streckkod (och läsare)
Jo, själva tekniken kring streckkoderna som sådana (utskrift och
avläsning) går ju alltid att lösa om man vet kraven.
Det pyssliga är ofta att bygga informationshanteringen runt det hela.
> ...gissar att jag behöver diskutera saker med dig.
Visst! Det kan dock i så fall inte bli on-line eftersom det kan
innehålla exempel på hantering hos tidigare eller befintliga kunder.
Jag har under flera år försökt hitta en möjlighet att delta på en
"Borås-träff" och här kanske det finns en anledning till...
avläsning) går ju alltid att lösa om man vet kraven.
Det pyssliga är ofta att bygga informationshanteringen runt det hela.
> ...gissar att jag behöver diskutera saker med dig.
Visst! Det kan dock i så fall inte bli on-line eftersom det kan
innehålla exempel på hantering hos tidigare eller befintliga kunder.
Jag har under flera år försökt hitta en möjlighet att delta på en
"Borås-träff" och här kanske det finns en anledning till...
Re: Streckkod (och läsare)
Ja, varför inte, Du är välkommen till Borås.
Eftersom det handlar om affärer, så tar vi det naturligtvis offline .
Slår dig en signal nästa vecka tror jag.
Eftersom det handlar om affärer, så tar vi det naturligtvis offline .
Slår dig en signal nästa vecka tror jag.
- Lennart Aspenryd
- Tidigare Lasp
- Inlägg: 12607
- Blev medlem: 1 juli 2011, 19:09:09
- Ort: Helsingborg
Re: Streckkod (och läsare)
Ser man på, sodjans eminenta inlägg leder till en träff IRL!
Det är så det skall vara Lycka till.
Det är så det skall vara Lycka till.
Re: Streckkod (och läsare)
Nu har ju ifs Sodjan pratat länge om att hälsa på oss, vi får väl göra ett specialmöte.
Sodjan säg till när du kan, så försöker vi fixa ihop det.
Sodjan säg till när du kan, så försöker vi fixa ihop det.
Re: Streckkod (och läsare)
OK, vi kan höras av nästa vecka.
Hm, Borås, det finns väl ett stort område där den kvinnliga
delen brukar roa sig. Kanske att vi kan kombinera nytta
med nöje...
Hm, Borås, det finns väl ett stort område där den kvinnliga
delen brukar roa sig. Kanske att vi kan kombinera nytta
med nöje...
-
sebastiannielsen
- Inlägg: 3663
- Blev medlem: 11 september 2004, 09:30:42
- Ort: gbg
- Kontakt:
Re: Streckkod (och läsare)
En sak som inte framgår är hur små detaljerna är. Handlar det om små kvadratiska (ytmonterade) pyttechip så kan det bli tvunget att ha QR eller datamatrix för att det ska bli någotsådär avläsbart.
DIL14, 16 , 18, 20, 22, 24 etc bör gå att köra 1D på.
DIL8 får man använda QR eller datamatrix på.
Sedan skrev du något om någon manuell hantering för att indikera vad för komponent det är. Det behövs ju inte heller, detta kan ju indikeras när streckkoden skrivs ut, så att streckkoden innehåller information om vad för komponent det är. På så sätt behöver inte operatören indikera vad för komponent det är när denne avläser streckkoden.
Ett annat tips är att man istället märker upp dem färdiga kretskorten med en streckkod med ett numeriskt serienummer, som sedan i eran databas sedan länkar mot komponenterna.
Ex att om ni scannar av streckkod nr "93875038530593" så kommer det upp en bild på kretskortet (antar att alla era kretskort ser ungefär likadana ut, då räcker det med att ta några enstaka bilder) där komponenterna är märkta, typ A, B, C, D och sedan i en tabell står det A: NE555, tillverkare Texas instruments, serienr: AAX53345VCD3245
B: FPGA, Tillverkare: SpartanTech, serienr: 982048CC8
DIL14, 16 , 18, 20, 22, 24 etc bör gå att köra 1D på.
DIL8 får man använda QR eller datamatrix på.
Sedan skrev du något om någon manuell hantering för att indikera vad för komponent det är. Det behövs ju inte heller, detta kan ju indikeras när streckkoden skrivs ut, så att streckkoden innehåller information om vad för komponent det är. På så sätt behöver inte operatören indikera vad för komponent det är när denne avläser streckkoden.
Ett annat tips är att man istället märker upp dem färdiga kretskorten med en streckkod med ett numeriskt serienummer, som sedan i eran databas sedan länkar mot komponenterna.
Ex att om ni scannar av streckkod nr "93875038530593" så kommer det upp en bild på kretskortet (antar att alla era kretskort ser ungefär likadana ut, då räcker det med att ta några enstaka bilder) där komponenterna är märkta, typ A, B, C, D och sedan i en tabell står det A: NE555, tillverkare Texas instruments, serienr: AAX53345VCD3245
B: FPGA, Tillverkare: SpartanTech, serienr: 982048CC8
Re: Streckkod (och läsare)
Nja, eftersom kompressorerna till exempel väger uppemot en 500kg, så är det inga småpryttlar direkt.
Re: Streckkod (och läsare)
> En sak som inte framgår är hur små detaljerna är. Handlar det om små kvadratiska
> (ytmonterade) pyttechip så kan det bli tvunget att ha QR eller datamatrix
> för att det ska bli någotsådär avläsbart.
Det är väldigt ovanligt att man behöver märka enskilda komponenter, om det
inte handlar om olika programmerbara kretsar eler liknande.
> A: NE555, tillverkare Texas instruments, serienr: AAX53345VCD3245
Sannolikt bara ett väldigt dåligt exempel. En 555'a har självklart inget serienummer.
Däremot kan det *ibland* finnas anledning att lagra (leverans-) batch på komponenter
i samband med montering. Men enbart om det finns anledning av spårbarhetsskäl. Och
inget sådant har nämnts i tråden.
I det aktuella fallet i tråden verkar det dock handla om märkning och spårbarhet
på modul/kretskortsnivå.
> Sedan skrev du något om någon manuell hantering för att indikera vad för komponent det är.
Jag antar att du syftar på denna mening:
> Alltså, vid tillverkning skall man skanna in serienumren och typbeteckningar på de ingående detaljerna...
Men grejen är ju att man redan vid *märkningen* vet vad det är man märker, det
behöver man aldrig tala om för systemet igen, det är ju det man har systemet till.
D.v.s att när serienumren skapas (individerna "döps" eller "föds") i systemet och
skrivs ut, så gör man det mot en specific serie med produkter. Man har aldrig
några serienummer som inte är kopplade till en fysisk pryl.
> Det behövs ju inte heller, detta kan ju indikeras när streckkoden skrivs ut, så att streckkoden
> innehåller information om vad för komponent det är.
Jag är personligen inte förtjust i sådana lösningar, lika lite som att det
står "Volvo" på nummerskylten på bilen.
> Ett annat tips är att man istället märker upp dem färdiga kretskorten med en streckkod med
> ett numeriskt serienummer, som sedan i eran databas sedan länkar mot komponenterna.
Ja, det är ju tanken enligt Tomas. Eller jag tolkade det i alla fall så. "Produkten" har
ett serienummer som sedan är kopplad (via en "struktur") till serienumren på de
ingående detaljerna.
>...så kommer det upp en bild på kretskortet...
Du är nog lite fel ut här. Det handlar om spårbarhet primärt.
För det du beskriver är det mycket enklare med vanliga ritningar,
utskriva eller som PDF'er, och BOM-listor.
En sak från ett tidigare inlägg från Tomas:
> Det hela skall ske utan att man är kabelansluten, antingen lagras uppgifterna i
> läsaren och tankas in i databasen när den sätts i "vaggan", som alternativ kan man
> tänka sig någon form av trådlös länk, dock inte BT, då räckvidden blir för kort
Vi kör en hel del med http://www.barcodesinc.com/datalogic/skorpio.htm.
(Verkar ha ersatts av http://www.barcodesinc.com/datalogic/skorpio-x3.htm.)
Vi får dom komplett med en telnet terminal-emulator och kör via vanligt W-LAN mot
servern där applikationerna ligger. Vi har applikationer som har 10x16 skärmbilder
för att passa handterminalerna istället för det vanliga standard 24x80 formatet.
Men man kan även skriva enkla program direkt för handterminalen, det är
någon slags Win-CE eller liknande.
> Nja, eftersom kompressorerna till exempel väger uppemot en 500kg,
I de fall jag jobbar med är det t.ex växellådor, motorer och batterier
till åkgräsklippare eller röjsågar. Det finns även problemet att det är
inköpta delar så vi har inte kontroll över format på streckkoderna.
> (ytmonterade) pyttechip så kan det bli tvunget att ha QR eller datamatrix
> för att det ska bli någotsådär avläsbart.
Det är väldigt ovanligt att man behöver märka enskilda komponenter, om det
inte handlar om olika programmerbara kretsar eler liknande.
> A: NE555, tillverkare Texas instruments, serienr: AAX53345VCD3245
Sannolikt bara ett väldigt dåligt exempel. En 555'a har självklart inget serienummer.
Däremot kan det *ibland* finnas anledning att lagra (leverans-) batch på komponenter
i samband med montering. Men enbart om det finns anledning av spårbarhetsskäl. Och
inget sådant har nämnts i tråden.
I det aktuella fallet i tråden verkar det dock handla om märkning och spårbarhet
på modul/kretskortsnivå.
> Sedan skrev du något om någon manuell hantering för att indikera vad för komponent det är.
Jag antar att du syftar på denna mening:
> Alltså, vid tillverkning skall man skanna in serienumren och typbeteckningar på de ingående detaljerna...
Men grejen är ju att man redan vid *märkningen* vet vad det är man märker, det
behöver man aldrig tala om för systemet igen, det är ju det man har systemet till.
D.v.s att när serienumren skapas (individerna "döps" eller "föds") i systemet och
skrivs ut, så gör man det mot en specific serie med produkter. Man har aldrig
några serienummer som inte är kopplade till en fysisk pryl.
> Det behövs ju inte heller, detta kan ju indikeras när streckkoden skrivs ut, så att streckkoden
> innehåller information om vad för komponent det är.
Jag är personligen inte förtjust i sådana lösningar, lika lite som att det
står "Volvo" på nummerskylten på bilen.
> Ett annat tips är att man istället märker upp dem färdiga kretskorten med en streckkod med
> ett numeriskt serienummer, som sedan i eran databas sedan länkar mot komponenterna.
Ja, det är ju tanken enligt Tomas. Eller jag tolkade det i alla fall så. "Produkten" har
ett serienummer som sedan är kopplad (via en "struktur") till serienumren på de
ingående detaljerna.
>...så kommer det upp en bild på kretskortet...
Du är nog lite fel ut här. Det handlar om spårbarhet primärt.
För det du beskriver är det mycket enklare med vanliga ritningar,
utskriva eller som PDF'er, och BOM-listor.
En sak från ett tidigare inlägg från Tomas:
> Det hela skall ske utan att man är kabelansluten, antingen lagras uppgifterna i
> läsaren och tankas in i databasen när den sätts i "vaggan", som alternativ kan man
> tänka sig någon form av trådlös länk, dock inte BT, då räckvidden blir för kort
Vi kör en hel del med http://www.barcodesinc.com/datalogic/skorpio.htm.
(Verkar ha ersatts av http://www.barcodesinc.com/datalogic/skorpio-x3.htm.)
Vi får dom komplett med en telnet terminal-emulator och kör via vanligt W-LAN mot
servern där applikationerna ligger. Vi har applikationer som har 10x16 skärmbilder
för att passa handterminalerna istället för det vanliga standard 24x80 formatet.
Men man kan även skriva enkla program direkt för handterminalen, det är
någon slags Win-CE eller liknande.
> Nja, eftersom kompressorerna till exempel väger uppemot en 500kg,
I de fall jag jobbar med är det t.ex växellådor, motorer och batterier
till åkgräsklippare eller röjsågar. Det finns även problemet att det är
inköpta delar så vi har inte kontroll över format på streckkoderna.
Re: Streckkod (och läsare)
Exakt så är det.Det finns även problemet att det är
inköpta delar så vi har inte kontroll över format på streckkoderna.
- Lennart Aspenryd
- Tidigare Lasp
- Inlägg: 12607
- Blev medlem: 1 juli 2011, 19:09:09
- Ort: Helsingborg
Re: Streckkod (och läsare)
När det gäller lite större delar så kanske det finns en tanke bakom QR som kommer via Toyota om jag inte har fel!
Re: Streckkod (och läsare)
ja, QR-koder är framtagna av Denso, som är ett företag i toyotafamiljen.
