Hallo, wie könnte man LEDs durch Barcode einzeln steuern. Barcode (1) einscannen , LED (1) geht an und bleibt so lange leuchten bis man den nächsten Scan startet. Es wären insgesamt 1000 LEDs. Ungefähr so http://program-plc.blogspot.de/2015/03/barcode-reader-scanner-usb-on-plc-using.html Gerne würde ich das mit LED streifen umsetzen lassen, PC oder Raspberry oder oder. Welcher PLC könnte so viele LEDs steuern. Ich würde mich über eure Antworten sehr freuen
Als Rechner würde sich ein RasPi oder ähnliches anbieten, an den der Barcode-Scanner angeschlossen wird. Nur damit allein kannst du keine 1000 Leds ansteuern. Dafür würde sich ein uC empfehlen, der per UART, I2C oder SPI mit dem RasPi kommuniziert. Mit einer 32x32 Matrix könntest du 1024 Leds mit 64 Pins steuern. Also Brauchst du einen uC mit >=64 IOs (plus die IOs, die für UART/I2C/SPI drauf gehen). Darf man fragen, was du damit vor hast? Mir erschließt sich der Sinn noch nicht ganz.
1000 LED - das sind also 1000 Bit. Die meisten Barcodes lassen nicht jede binäre Codierung als "Nutzlast" zu, nehmen wir also mal an, pro Zeichen 7 Bit ... das wären dann mind. 143 Zeichen. Das ist mit gewöhnlichen 1-dimensionalen Barcodes nicht oder nur sehr schwierig zu machen. Möglicherweise werden die zu lang für des Sichtbereich des Barcodereaders. EIne Alternative wäer evtl. ein 2-dimensionaler COde, z.B. QR-Code. Allen Lösungen ist gemeinsam, dass die Decodierung im Barcodereader erfolgt und dessen Output dann dem MC "sagt" welche LEDs er einschalten soll ... Der Teil ist rel. einfach, z.B. wenn du z.B. gleich einen LED-Strip mit WS2812-CHips nimmst, sparst du dir das mühselige Kontaktieren jeder einzelnen LED und evtl. Myriaden von Schieberegistern.
Frank E. schrieb: > 1000 LED - das sind also 1000 Bit. Sehr wahrscheinlich wird jedem Barcode-Wert eine LED zugeordnet. Z.B. einen eingegangenen Artikel scannen, Regalfach leuchtet, Artikel in leuchtendes Fach legen.
Bastello schrieb: > Darf man fragen, was du damit vor hast? Mir erschließt sich der Sinn > noch nicht ganz. Bin Ersatzteilhändler und habe ca. 2000 unterschiedliche klein Produkte die sehr gut sortiert sind, dennoch dauert das picken lange. Mit diesen System möchte ich einfach den Ean Barcode von der Pickliste einscannen und sehen wo der Artikel sich befindet. http://www.cap-ai.jp/english/img/about/img04.gif
Kristina D. schrieb: > möchte ich einfach den Ean Barcode von der Pickliste einscannen > und sehen wo der Artikel sich befindet Also muss immer nur eine LED gelcihzeitig leuchten, das reduziert massiv die Datenmenge. Folgende Elemente bräuchtest du: - Barcodescanner (gibts billig) - Raspi oder ähnliches - Datenbank auf dem Pi in der zu jedem Code eine LED abgelegt ist (und evtl. auch eine Meldung für "ungültig") - 8 8-Bit Schieberegister Vorgehen: - In der DB stehen zu dem Code x und y Koordinaten - Via SPI schiebst du den seriellen Datenstrom raus - Die Schiebregister versogrn die passende LED
:
Bearbeitet durch User
Frank E. schrieb: > 1000 LED - das sind also 1000 Bit. Die meisten Barcodes lassen nicht > jede binäre Codierung als "Nutzlast" zu, nehmen wir also mal an, pro > Zeichen 7 Bit ... das wären dann mind. 143 Zeichen. > > Das ist mit gewöhnlichen 1-dimensionalen Barcodes nicht oder nur sehr > schwierig zu machen. Möglicherweise werden die zu lang für des > Sichtbereich des Barcodereaders. EIne Alternative wäer evtl. ein > 2-dimensionaler COde, z.B. QR-Code. Verstehe ich die Frage nicht? Ein USB-Scanner sendet doch einfach den eingescannten Barcode als "Tastatur" an das angeschlossene Gerät. Dieses muss nur diese Eingabe verarbeiten und dann den entsprechenden Befehl an die Ansteuerung der LEDs geben. Für 1000 LEDs genügen also z.B. 2000 Zahlen (0000...1999) 0000 = LED 0 an 0001 = LED 0 aus 0002 = LED 1 an 0003 = LED 1 aus ... Und eine 4-Stellige Zahl ist nun wirklich kein so großer Barcode. Oder ich verstehe das Problem/die Frage wirklich nicht. TD
Kristina D. schrieb: > Bin Ersatzteilhändler und habe ca. 2000 unterschiedliche klein Produkte > die sehr gut sortiert sind, dennoch dauert das picken lange. Mit diesen > System möchte ich einfach den Ean Barcode von der Pickliste einscannen > und sehen wo der Artikel sich befindet. Aha, jetzt verstehe ich. Warum das eigentliche Problem nicht gleich beschrieben wird. Du willst also "pick-by-light".
könnte Max D. schrieb: > Also muss immer nur eine LED gelcihzeitig leuchten, das reduziert massiv > die Datenmenge. > > Folgende Elemente bräuchtest du: > - Barcodescanner (gibts billig) > - Raspi oder ähnliches > - Datenbank auf dem Pi in der zu jedem Code eine LED abgelegt ist (und > evtl. auch eine Meldung für "ungültig") > - 8 8-Bit Schieberegister > > Vorgehen: > - In der DB stehen zu dem Code x und y Koordinaten > - Via SPI schiebst du den seriellen Datenstrom raus > - Die Schiebregister versogrn die passende LED mit Led Streifen ? An wem könnte ich mich wenden der mir das Umsätzen könnte ? Danke Max für deine Mühe, Danke auch an andere Mitglieder.
tastendrücker schrieb: > Aha, jetzt verstehe ich. Warum das eigentliche Problem nicht gleich > beschrieben wird. Du willst also "pick-by-light". JA GENAU :-)
Kristina D. schrieb: > mit Led Streifen ? > > An wem könnte ich mich wenden der mir das Umsätzen könnte ? LED-Streifen leuchten entweder immer als ganzes (normale) oder sind mit rgb etwas overkill (ws2812). Mach für gute Ideen vlt. mal ein foto deines Arbeitsplatzes :)
Werde ich machen. Jetzt bin ich zuhause. DANKE ihr seit einfach die beste Community. Einfach Top Leute hier
Barcode-Reader funktionieren wie normale Tastaturen, die gibt es auch mit PS/2-Anschluss. Wenn du da einen Barcode mit einliest, dann werden einfach Tastendruecke gemeldet. Zur Auswertung reicht ein kleiner Controller (z.B. AVR) mit gewöhnlichem Tastaturtreiber, und eine Kette aus Schieberegistern. Da immer nur eine LED an ist, brauchst du auch nicht besonders auf den Stromverbrauch achten. Nachtrag: Die Datenbank kannst du auch weglassen, wenn du einfach als Barcode die "Fachnummer" benutzt. Mit Schieberegistern zu je 8 Bit brauchst du 125 Schieberegister in einer Kette fuer 1000 LEDs.
:
Bearbeitet durch User
Wenn er die EAN benutzen will braucht er schon ne datenbank. Ean-》Led. Man könnte einen Led stripe mit integriertem buskram nehmen und lichtwellenleiter zu den fächern legen...
Das will ich sehen wie du mit dem Servo reproduzierbar auf 1000 verschieden Fächer zeigst. Mit viel Geduld und Ausrichtung evtl. via untersetztem Stepper, aber Servo wird nix.... Das Flotteste dürfte aller Wahrscheinlichkeit nach Pi+Schiebereg sein. Wobei theoretisch auch WS2812er gehen sollten, aber die mit ihrem RGB eigtl. schon Overkill sind.
Ich würde mir das auch mit einem Raspi, ner DB und einem WS2801 Strip machen. Da sparst du dir wahrscheinlich das schreiben der Treiber für den Scanner bzw die Strips. Hätte zusätzlich den Vorteil das man in der DB gleich auch noch die vorhandene Menge, Bestellnummern, Preise usw halten kann. RGB LED ist zwar total oversized, aber du kannst mit der Farbe ja die Füllmenge zusätzlich anzeigen :-)
Hotschty schrieb: > Wenn er die EAN benutzen will braucht er schon ne datenbank. Oh stimmt, das mit der EAN hatte ich ueberlesen. Dann braucht's doch etwas dickeres mit Netzwerkanbindung, um die (vermutlich schon vorhandene) Datenbank auszulesen.
Ich würde es evtl. um einen Taster je Fach erweitern. Dann geht das austauschen des Inhalts via: - Knopf drücken - Code scannen - Neuen Kram reinschütten
Die Technik nennt sich "pick by light" und ist im Versandhandel bereits etabliert. Bei richtig großen Lagerwirtschaften befinden sich an jedem Fach farblich steuerbare Ziffernanzeigen und ein Taster: - Die Farbe bestimmt, für welchen "Picker" die Anzeige gilt (es können mehrere Leute gleichzeitig arbeiten) - die gezeigte Zahl steht für die zu entnehmende Menge ... - mit einem Druck auf den Taster bestätigt der Picker, dass er die Ware entnommen hat - danach hält der Picker Ausschau, wo die nächste Zahl in "seiner" Farbe aufleuchtet - meist wegeoptimiert in unmittelbarer Nähe
Die modernere Option ist hier das Bestaetigen ueber ein Smartphone, da diese billiger sind als die requisite Anzahl Taster - Mechanik ist teuer!
Es wäre wirklich erst mal interessant das Lager zu sehen. Wenn es ein regelmässiger Aufbau ist reicht vielleicht eine Spalten/Zeilen Einteilung und eine einzige Anzeige. Die zeigt dann z.B.: D 13 Dann greift man nach kurzer Einarbeitung ganz automatisch in das richtige Fach. Und das kostet auch nicht mehr als das ganze Geschäft einbringt ;-)
Angehängte Dateien:
-
DSCF1137_RLP_Teile.jpg
38 KB -
IMG_8509_Pos_Test.jpg
32 KB
Wenn es das Lager hergibt, dann ist Pick-By-Light eine sehr günstige Lösung. Ich habe sowas schonmal gebaut. Im Anhang zwei Bilder - einmal die Mechanikteile von einem Labormuster und dann eine Langzeitaufnahme von Testläufen. Es werden 6 Sollwerte pro Sekunde angefahren, man sieht schön wie die Servos auf dem Weg eiern, aber dann sauber im Ziel stehen. Hier liegt für kurze Zeit ein Video im flv-Format für z.B. VLC: http://www.harerod.de/rlp/RLP_166ms.flv Ansteuerung war in diesem Fall vom Lagerverwaltungssystem über Netzwerk. Teach-In über Joystick oder Webinterface.
S. R. schrieb: > Barcode-Reader funktionieren wie normale Tastaturen, die gibt es auch > mit PS/2-Anschluss. Wenn du da einen Barcode mit einliest, dann werden > einfach Tastendruecke gemeldet. Auf USB würde ich auch verzichten. Das ist sowieso nur eine Tastatus oder RS232. Besser als PS/2 ist die RS232. Auch da reicht ein 8-Bit Controller. Das kann (fast) jeder Barcode-Scanner.
Uwe K. schrieb: > Besser als PS/2 ist die RS232. Sehe ich auch so. RS232-Barcode-Scanner gibt es wie Sand am Meer. > Auch da reicht ein 8-Bit Controller. Das sehe ich allerdings nicht so. Du brauchst die Zuordnung Barcode -> LED. Bei ca. 1000 Artikeln reicht da ein µC nicht aus. Ein kleiner Linux-Rechner (meinetwegen auch ein RasPI) kann das locker. Noch eine Weboberfläche zum Einpflegen der Codes -> fertig.
Wen 1000 Tasten zu teuer sind, dann kann man auch an jede Box noch einen Ident-Code kleben (der halt nicht in den EANs vorkommt) und kann die dann so neu-zuweisen.
Melanie T. schrieb: > Die modernere Option ist hier das Bestaetigen ueber ein > Smartphone, da > diese billiger sind als die requisite Anzahl Taster - Mechanik ist > teuer! Kindchen - das ist Bullshit. Hast du schonmal eine gazen Arbeits-Tag lang mit 'nem Smartphone in der Hand herumgefuchtelt? So ein Stück Unterhaltungselektronik ist keine Arbeitsmaschine, auch wenn es im ersten Moment funktioniert, oder was glaubst du, warum z.B. die Hersteller "klasischer" Barcode-Reader immer noch voll im Geschäft sind. Ich stell mir gerade eine Supermarktkasse vor, an der mit nem iPhone gescannt wird - also wirklich! Ein Billigst-Tintenpisser aus dem Mediamarkt wird auch nicht in einen Ticketautomaten eingebaut - warum wohl. Ich hoffe, du verstehst, was ich meine ...
Max D. schrieb: > Wen 1000 Tasten zu teuer sind, dann kann man auch an jede Box noch > einen > Ident-Code kleben (der halt nicht in den EANs vorkommt) und kann die > dann so neu-zuweisen. Bei prof. Pick-by-Light-Systemen wird z.B. eine Busleitung verlegt und die einzelnen Einheiten aus Anzeige und Bestätigungstaste pieksen sich bei der Montage (Magnet oder Doppelkleber) an beliebiger Stelle durch die Isolierung hindurch. Eine andere Variante ist die Montage auf einer Trägerschiene, die ähnlich einer KNX-Hutschiene für den Schaltschrank aufgebaut ist, also Strom und Daten berietstellt und die mechanische Fixierung übernimmt. Dadurch können die Einheiten sehr kostengünstig produziert und platziert werden. Jede Einheit hat eine fabrikseitige ID, die an den Steuercomputer gesendet wird, sobald die Taste gedrückt wird. Erfolgt die Erstmontage nach einem vorher festgelegten Plan, ergibt sich dabei gleich automatisch die Zuordnung zu einem Fach. Die Zuordnung Ware-Fach erfolgt quasi in einem zweiten Level. Alles per Datenbank natürlich ...
:
Bearbeitet durch User
Um was für Dimensionen geht es denn hier, ich kenne ein Lager in dem man 10 Minuten laufen muß um in die Kantine zu kommen. Das wäre nicht ganz unerheblich was die Leitungslängen angeht, auch die Kosten und die Zeit sollte man vorher überschlagen. Nach meiner Erfahrung findet man sich auch in großen Lagern mit einem gescheitem System schnell zurecht. Unterteilung in Buchstabenbereiche, anschließend Gänge mit entsprechenden Nummerbereichen 1..100 101..200 und logisch angeordnete Fächer links oben 1 rechts unten 100, das ist allerdings Logistisch eine Herausforderung.
>Wobei theoretisch auch WS2812er gehen sollten, aber die mit ihrem RGB >eigtl. schon Overkill sind. Nein sind sie nicht, geeigneter sind aber eigentlich "led pixel module" vom freundlichen Chinesen. Preiswert, leicht zu installieren, ob hell genug müsste man mal ausprobieren. Vor allem wie eine Lichterkette leicht zu installieren. Damit kann man dann auch: Rot leuchten wenn Mindeststückzahl unterschritten und ähnliche Spässe. Viel Erfolg hauspapa
Frank M. schrieb: >> Auch da reicht ein 8-Bit Controller. > > Das sehe ich allerdings nicht so. Du brauchst die Zuordnung Barcode -> > LED. Bei ca. 1000 Artikeln reicht da ein µC nicht aus. Das ist kompletter Unsinn. Die üblichen EAN13 Barcodes enthalten 13 dezimale Digits, können also maximal 10^13 verschiedene Codes enthalten. Die nächstgrößere Zweierpotenz ist 2^44 oder anders ausgedrückt: man braucht 6 Bytes pro Code, wobei vier Bits davon erstmal vollkommen ungenutzt bleiben. Für 1000 LED-Positionen benötigt man zehn Bits, da 2^10=1024. Von den zehn Bits kann man vier in den vier freien des Artikelcodes speichern, verbleiben sechs, also nur noch ein zusätzliches Byte, von dem dann zwei Bits frei bleiben würden. Nutzt man diese Bits gleich noch für zusätzliche LED-Positionen, kann man sogar 4096 LEDs adressieren. Zusammenfassend: Pro zu speicherndem Artikel werden genau 7 Bytes (44Bit Artikelcode und 12Bit LED-Adresse) benötigt und damit kann man dann jedem gespeicherten Code eine von 4096 LEDs zuordnen. Bei voller Ausnutzung des Speicherformates für 4096 Artikel wären also 4096*7=28.672 Bytes erforderlich. Diese Datenmenge paßt schon in den Flash eines ATMega32 völlig problemlos rein, der ist nämlich 32.768 Bytes groß, es blieben also satte 2k für das Programm. Und, du wirst es kaum glauben, es gibt µC mit noch weitaus mehr Flashspace... "Da reicht ein µC nicht aus"... Bullshit... Man muß einfach nur trivialste Rechenaufgaben lösen und Programmieren können, dann geht das völlig problemlos und man ist dann sogar in der Lage, selbstständig zu erkennen, dass es völlig problemlos geht... Das einzige (aber eigentlich auch nur klitzekleine) Problem ist, eine dreizehnstellige Dezimalzahl in ASCII-Repräsentation in eine Binärzahl zu konvertieren. Kinderkram für jeden Programmierer, der diese Bezeichnung auch nur andeutungsweise verdient. Sollte sich auf einem AVR@20MHz in deutlich unter einer ms realisieren lassen. Dauert also nichtmal annähernd so lange wie die Übertragung des Scan-Ergebnisses von einem üblichen Handscanner zum µC. Wie gesagt: Kinderkram. Zusätzlich, nur als Tip: wenn man das Problem richtig durchdenkt, erkennt man, dass man bei der Speicherung des Codes problemlos weitere 4 Bit einsparen kann, womit sich bei gleichbleibendem Speicherbedarf des Speicherformats die Möglichkeit ergäbe, sogar 2^16, also 65536 LEDs zu adressieren. Ich überlasse es dir, herauszufinden, welche Bits des EAN-Codes man einsparen könnte... Wenn dir das gelingt, hast du dann endlich tatsächlich eine Anwendung für den RasPi gefunden? Um den Datenbestand von 2^16 Artikeln zu speichern, wäre dann ja schon fast ein halbes Megabyte Speicher erforderlich. Nope, auch dann wird's noch nix mit der Notwendigkeit für einen RasPi, denn natürlich gibt es reichlich µC, die völlig problemlos auch mit solchen Speichermengen umgehen können. Nicht zuletzt übrigens den, der im RasPi werkelt, denn, ob du es glaubst oder nicht: auch das Herz des RasPi ist letztlich "nur" ein µC... Aber darüber hinaus: Auch dieses Problem wäre immer noch selbst mit einem AVR8 in einem für die Praxis völlig ausreichendem Maße lösbar. In dieser Größenordnung der Daten und bei den relativ langsamen Anbindungen günstigen Speichers (z.B. SD-Card) müßte man dann allerdings tatsächlich langsam anfangen, sich über die Effizienz der Implementierung von Suchvorgängen in dem Datenbestand Gedanken zu machen...
Du willst also jedesmal wenn ein neuer Artikel kommt den Flash des AVRs neu programmieren, viel Spaß würde ich sagen.....
> Das ist kompletter Unsinn. Die üblichen EAN13 Barcodes enthalten 13 > dezimale Digits, können also maximal 10^13 verschiedene Codes enthalten. > Die nächstgrößere Zweierpotenz ist 2^44 oder anders ausgedrückt: man > braucht 6 Bytes pro Code, wobei vier Bits davon erstmal vollkommen > ungenutzt bleiben. Kleine Korrektur: Der EAN-Code enthält nur 12 nutzbare Stellen, die 13. ist eine Prüfsumme. Damit ist sie von den restlichen 12 Stellen abhängig und redundant - nicht zu Adressierung zu gebrauchen.
> - danach hält der Picker Ausschau, wo die nächste Zahl in "seiner" Farbe > aufleuchtet - meist wegeoptimiert in unmittelbarer Nähe >> meist wegeoptimiert Bimm -> wech "Ihr Fach wurde wegoptimiert" -O0 Hihi
Frank E. schrieb: > Kleine Korrektur: Der EAN-Code enthält nur 12 nutzbare Stellen, die 13. > ist eine Prüfsumme. Damit ist sie von den restlichen 12 Stellen abhängig > und redundant - nicht zu Adressierung zu gebrauchen. Das ist eigentlich richtig, aber nicht zu empfehlen. Immer die Komplette Nummer speichern (13 Stellen). Das vermeidet Verwirrung ist macht den Code einfacher.
c-hater schrieb: > Das ist kompletter Unsinn. Du willst also jedes Mal den µC neu flashen, wenn ein Artikel hinzukommt oder den Platz wechselt? Das nenne ich kompletten Unsinn. > "Da reicht ein µC nicht aus"... Bullshit... Für die geschilderte Kinderkram-Anwendung reicht es natürlich. Aber professionell ist anders. > Man muß einfach nur trivialste Rechenaufgaben lösen und Programmieren > können, dann geht das völlig problemlos und man ist dann sogar in der > Lage, selbstständig zu erkennen, dass es völlig problemlos geht... Klasse! Nur will so niemand arbeiten - mit einem Flash-Gerät und einem C-Compiler (oder noch besser: Assembler!) in den Fingern, wenn sich mal wieder was ändert. Ich glaube nicht, dass der TO so eine Bastellösung haben will. > Wie gesagt: Kinderkram. Ja, für hochnäsige Bastler ist das Kinderkram. Für einen Otto Normaluser ist Dein Kinderkram allerdings keine anwendbare Lösung. Ich hoffe nun abschließend, dass Du nochmal so richtig hier durch die Decke gehst. Ich liebe es, wenn Du mit Arroganz nur so strotzt, dabei mit dem Fuß aufstampfst, laut Buzzwords wie "Bullshit!" schreist und Dich dabei zum Affen machst... das macht mir richtig Spaß :-) Bin jetzt schon gespannt auf den Ton, den Du nun anschlagen wirst. Hoffentlich ist da noch eine Steigerung drin :-)
:
Bearbeitet durch Moderator
Max D. schrieb: > Du willst also jedesmal wenn ein neuer Artikel kommt den Flash des AVRs > neu programmieren, viel Spaß würde ich sagen..... Das ist doch trivial. Ein AVR kann seinen Flash selber umprogrammieren. Da muß man nicht unbedingt mit dem Programmer ran...
Frank E. schrieb: >> Das ist kompletter Unsinn. Die üblichen EAN13 Barcodes enthalten 13 >> dezimale Digits, können also maximal 10^13 verschiedene Codes enthalten. >> Die nächstgrößere Zweierpotenz ist 2^44 oder anders ausgedrückt: man >> braucht 6 Bytes pro Code, wobei vier Bits davon erstmal vollkommen >> ungenutzt bleiben. > > Kleine Korrektur: Der EAN-Code enthält nur 12 nutzbare Stellen Spoiler... Du hättest mein Posting einfach mal bis zum Ende lesen sollen...
Melanie T. schrieb: > Die modernere Option ist hier das Bestaetigen ueber ein Smartphone, da > diese billiger sind als die requisite Anzahl Taster - Mechanik ist > teuer! Aber vielleicht hat nicht jeder Lust, immer mit einem angewachsenen Smartphone herumzulaufen, schon gar nicht, wenn er dabei ist, Ware aus irgenwelchen Fächern zu greifen und in Tüten zu füllen.
c-hater schrieb: > Du hättest mein Posting einfach mal bis zum Ende lesen sollen... Vielleicht solltest du das als Wink mit dem Zaunpfahl nehmen und dich etwas kürzer fassen ;-)
Frank M. schrieb: > Du willst also jedes Mal den µC neu flashen, wenn ein Artikel hinzukommt > oder den Platz wechselt? Das nenne ich kompletten Unsinn. Du weisst offensichtlich nichtmal, dass sich ein AVR auch selber flashen kann. Das nennt sich "self-programming". Bootloader z.B. nutzen das regelmäßig, die Anwendung dieser Fähigkeit ist aber natürlich nicht auf Bootloader beschränkt, sondern kann genauso dazu benutzt werden, um Datenbestände im Flash zu aktualisieren. Damit hast du dich übrigens für jede weitere Diskussion von vornherein als "inadäquater Gesprachspartner" geoutet. Oder weniger vornehm: als krass unwissender Vollidiot. > Bin jetzt schon gespannt auf den Ton, den Du nun anschlagen wirst. > Hoffentlich ist da noch eine Steigerung drin :-) Genügte das da oben, oder muß ich noch deutlicher werden? Fuck off!
c-hater schrieb: > Du weisst offensichtlich nichtmal, dass sich ein AVR auch selber flashen > kann. Das nennt sich "self-programming". Bootloader z.B. nutzen das > regelmäßig, die Anwendung dieser Fähigkeit ist aber natürlich nicht auf > Bootloader beschränkt, sondern kann genauso dazu benutzt werden, um > Datenbestände im Flash zu aktualisieren. Das weiß ich natürlich, ich habe schon mehrere Bootloader geschrieben und schon einige hier veröffentlicht - u.a. einen, der 60 ATtinys gleichzeitig auf einmal in einem Rutsch neu programmiert. :-) Und die Benutzeroberfläche, damit der User seine 1000 Artikel komfortabel verwalten kann, packst Du natürlich auch noch in Deinen Micky-Maus-µC? Genial! > Damit hast du dich übrigens für jede weitere Diskussion von vornherein > als "inadäquater Gesprachspartner" geoutet. Oder weniger vornehm: als > krass unwissender Vollidiot. Danke für die nette Einschätzung. Aber man sollte sich schon über seinen Gesprächspartner schon genauer informieren, bevor man solche Geschütze auffährt :-) > Genügte das da oben, oder muß ich noch deutlicher werden? Fuck off! Das war jetzt wirklich schwach. Schade.
:
Bearbeitet durch Moderator
c-hater schrieb: > [ganz viel] Du hast insofern recht, als dass der Barcode einfach aus der Fachnummer bestehen kann - der Adressraum ist groß genug. Dann braucht man natuerlich keine Datenbank. Da aber die EAN eines Standardbauteils selten der Fachnummer im Lager entspricht, ist es vermutlich sinnvoller, in die sowieso vorhandene Lagerverwaltung zu jedem Teil eine Fachnummer einzugeben und mit der LED-Suche zu verheiraten. Dann spart man sich den Extra-Barcode, braucht aber einen größeren Controller - wegen der Netzwerkanbindung. Beide Varianten sind möglich, beide Varianten sind sinnvoll. Was der TO möchte, muss er selbst wissen - gefragt hatte er nach "ich lese die EAN und eine LED geht an". Vermutlich will er also bereits vorhandene Barcodes nutzen.
:
Bearbeitet durch User
Frank M. schrieb: > Das weiß ich natürlich Scheint mir aber nach deinen bisherigen Einlassungen gerade nicht so... > ich habe schon mehrere Bootloader geschrieben Geschrieben? Eher: raubkopiert und minimal angepaßt... > Und die Benutzeroberfläche, damit der User seine 1000 Artikel > komfortabel verwalten kann, packst Du natürlich auch noch in Deinen > Micky-Maus-µC? Genial! Selbst das wäre prinzipiell problemlos möglich. Ein GUI für die Eingabe zweier numerischer Werte ist ja nun auch auf einem µC nicht gerade Raketentechnik... Ist aber natürlich sowieso garnicht nicht nötig, denn die mobilen Geräte müssen zum Akku-Laden ja sowieso regelmäßig auf's Dock. Natürlich würde man diese erzwungene Mobilitätspause dazu nutzen, die Daten mit einer Zentrale zu synchronisieren. Und auch das ginge dann ganz ohne Programmiergerät und Assembler oder Compiler. Z.B. über eine triviale RS232-Verbindung. Und wenn man noch mehr Echtzeit braucht, kann man die Dinger auch einfach mit Funkmodulen ausstatten, um sie auch während des Mobileinsatzes auf dem Laufenden zu halten. Alles absoluter Kinderkram, für dich aber scheinbar schon weit jenseits des Machbaren... Und die "Zentrale" solcher Aktivitäten braucht wiederum auch kein RasPi zu sein. Dafür kann man dann einfach einen ganz normalen PC hernehmen oder gleich den Datenbankserver. Einen Richtigen, nicht das Kinderspielzeug, was auf einem RasPi lauffähig ist...
S. R. schrieb: > Du hast insofern recht, als dass der Barcode einfach aus der Fachnummer > bestehen kann Du hast das nicht begriffen. Ich ersetze keinesfalls die EAN durch irgendeine fiktive Fachnummer. Ich bringe die EAN einfach nur in eine effizientiere Repräsentation/Codierung oder wie auch immer man das nun nennen will. Der Punkt ist: für diese Anwendung ist schlicht nicht mehr nötig. Dafür genügt es, den Weg von der 13stelligen Dezimalzahl zu der wesentlich speichereffizienteren Binär-Darstellung umzusetzen. Der springende Punkt ist aber: das geschieht ohne jeglichen Verlust an Information. Es wäre also auch jederzeit möglich, die Transformation in die Gegenrichtung vorzunehmen, also wieder die ursprüngliche EAN darzustellen, wenn das nötig wäre. Ist es in dieser Anwendung aber eben nicht... Für eine Fachnummer-Datenreduktion würden übrigens wohl wesentlich weniger als 44 (bzw. 40) Bit genügen. So fein aufgeteilt ist kein Lager...
c-hater schrieb: > Geschrieben? Eher: raubkopiert und minimal angepaßt... Bevor man so etwas frech behauptet, sollte man sich schon mal vorab informieren, z.B. durch Klick auf das Icon rechts neben dem Benutzernamen. :-) Dort findest Du unter anderem: AVR-Bootloader über UART, 2-Draht-Busse, Ethernet oder auch - exotischer - über die Soundkarte eines PCs. Raubkopiert? Dann nenne mir die Quellen, von der ich kopiert haben soll. Diese wirst Du nicht finden. Denn das sind alles Bootloader mit Alleinstellungsmerkmalen. Hier noch ein direkter Link auf einen Artikel, welcher einen ATTiny-Bootloader rein theoretisch behandelt: http://www.mikrocontroller.net/articles/Konzept_f%C3%BCr_einen_ATtiny-Bootloader_in_C Glaubst Du wirklich im Ernst, dass ich dieses Konzept raubkopiert habe? Aber nun zum Thema: > Selbst das wäre prinzipiell problemlos möglich. Ein GUI für die > Eingabe zweier numerischer Werte ist ja nun auch auf einem µC nicht > gerade Raketentechnik... Der TO wird bereits eine Lagerverwaltung haben, schließlich spielt sich das nicht in seinem Kinderzimmer ab. Und wenn er die nicht hat, dann wirds mit einer Artikelnummer nicht getan sein. Dann brauchst Du noch eine Artikelbezeichnung, technische Daten dazu, Verpackungseinheiten (damit der User bei einer Bestellung von "1 Stück" nicht eine Hunderter-Tüte einpackt) und andere Infos. Das machst Du nicht mit einer "GUI" auf einem 2-Zeiligen LCD-Display. Abgesehen davon programmiert man so eine Anwendung eher auf einem Rechner mit einem OS, z.B. mit einem RasPI. Der verarbeitet eine Bestellung, kann dann die LED-Leuchtbefehle durchaus an einen ATmega weitergeben, welcher dann die entsprechenden LEDs einschaltet und Bestätigungs-Knöpfe an den Regalen zum Rechner wieder zurückgibt. Der Rechner wiederrum hakt die Positionen auf der Bestellliste ab und zeigt bei "vergessenen Picks" die entsprechenden Positionen an, damit der User nochmal losdackeln kann. So eine Anwendung ist viel effektiver und schneller für einen Rechner mit OS zu entwickeln. Die eigentlichen LED-Befehle und Button-Rückmeldungen kann ja durchaus ein ATmega machen. Dafür braucht der aber über die einzelnen Artikel NICHTS zu wissen. Das nenne ich eine professionelle Lösung. Alles andere wie selbst-prgrammierender µC ist und bleibt eine Bastellösung, die zudem viel aufwändiger programmiert werden muss.
:
Bearbeitet durch Moderator
c-hater schrieb: > Du hast das nicht begriffen. Ich ersetze keinesfalls die EAN durch > irgendeine fiktive Fachnummer. Ich bringe die EAN einfach nur in eine > effizientiere Repräsentation/Codierung oder wie auch immer man das nun > nennen will. Die Zuordnung zwischen EAN und Fach ist willkuerlich, setzt also eine konstant aktuell gehaltene Datenbank voraus. Und da ein Lager sowieso eine Datenbank fuer den Lagerbestand hat, ist es sinnvoll, diese auch mitzubenutzen. > Der Punkt ist: für diese Anwendung ist schlicht nicht mehr nötig. Dafür > genügt es, den Weg von der 13stelligen Dezimalzahl zu der wesentlich > speichereffizienteren Binär-Darstellung umzusetzen. Ja. Das hält die Datenbank klein. Aber das hilft dir genau garnicht bei der Pflege der Tabelle, weil du jetzt statt einer Datenbank (Lagerbestand) zwei Datenbanken pflegen musst. Problem gelöst. Lösung schlechter als Problem. ;-)
S. R. schrieb: >> Der Punkt ist: für diese Anwendung ist schlicht nicht mehr nötig. Dafür >> genügt es, den Weg von der 13stelligen Dezimalzahl zu der wesentlich >> speichereffizienteren Binär-Darstellung umzusetzen. > > Ja. Das hält die Datenbank klein. > Aber das hilft dir genau garnicht bei der Pflege der Tabelle, weil du > jetzt statt einer Datenbank (Lagerbestand) zwei Datenbanken pflegen > musst. Wirklich lustig wird es erst dann, wenn ein Produkt auf mehrere Fächer verteilt ist und noch das Haltbarkeitsdatum berücksichtigt werden muss! Und wenn man das dann noch auf mehrere Lagerhäuser verteilt und kosten, zeit- und kapazitätsorientiert nutzen will, dann braucht man fast so eine Softwarelösung wie Amazon!
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.