Hallo Zusammen, hat jemand Erfahrungen mit der in Getränkeautomaten gängigen Schnittstelle MDB? Ich besitze einen (bzw. ein kleiner Verein) Sielaff Getränkeautomaten bei dem wir gerne loggen würden welche Getränke zu welcher Uhrzeit genommen wurden. Beispiel: 2013-02-06_18-02-09_Schacht1 2013-02-06_18-05-30_Schacht6 2013-02-06_19-31-02_Schacht3 ... Man könnte das natürlich auch noch weiterspinnen, z.B. - Preis mitloggen (Schächte können ja unterschiedliche Preise haben) - Zahlung via RFID - Leermeldung eines Schachtes per Mail o. Ä. Angeschlossen soll das "Modul" ans Netzwerk so dass die Logdaten gleich geholt werden könnten. Bereits vorhanden ist ein RaspberryPi den man dafür hernehmen könnte. Theoretisch kann man aber auch ein anderes Board nutzen. Die Kosten müssten da das nur ein kleiner Verein ist allerdings klein gehalten werden. Hat da also schon jemand Erfahrung oder sogar so etwas schon mal realisiert bzw. jemand Lust so etwas zu bauen? Gruß Lukas
Wie viele Monate hats Zeit! Haste Ahnung von RFID? Kannst programmieren? Oder biste jemand der ein Modul kauft und meint alles damit machen zu können. Verstehts due Protokolle? Such das Protokoll MDB im Internet ( frei zu finden) und arbeite dich durch einige 100 Seiten Doku. Manni PS: Für einige xT€ bekommste von mir/uns e genau so ein komplett System!
Hi Manni, primär wichtig ist nur das Mitschreiben der Verkäufe. Alles Andere ist nur "Spinnerei" und überhaupt nicht wichtig. Es gibt ja auch Telemetriemodule die von z.B. den "Großen Automatenbetreibern" genutzt werden, leider findet man dazu schwer etwas im Netz. Vielleicht hast du ja einen Geheimtipp? Mir fehlt dazu aktuell die Zeit um mich intensiv genug in das Protokoll rein zu arbeiten, darum hoffe ich auf jemand der das schon hinter sich hat bzw. bereits so etwas realisiert hat. Gruß Lukas Leider kann ich dir kein 4-stelliges Budget bieten da sich das der Verein keinesfalls leisten kann :(
zu rfid kann ich das hier empfehlen http://www.pollin.de/shop/dt/MDQ5OTgxOTk-/Bausaetze_Module/Bausaetze/Bausatz_RFID_125kHz_Empfaenger.html
>Mir fehlt dazu aktuell die Zeit um mich intensiv genug in das Protokoll >rein zu arbeiten, darum hoffe ich auf jemand der das schon hinter sich >hat bzw. bereits so etwas realisiert hat. Dann wirds wohl bei Zettel und Bleistift bleiben müssen;)
Bevor nur alles schlecht geredet wird...kennt jemand vielleicht einfach einen Hersteller der das schon fertig vertreibt?
Hi, ich habe die gleiche Spinnerei :) Benutze ein RFID System von ELV für die Eingangstüre mit einen Arduino. Das gleiche System soll letztenendes zum Bezahlen genutzt werden. Wie sind deine Fortschritte? LG Andi
Hallo, bin zwar etwas spät dran für diesen Beitrag aber vielleicht hilft es ja trotzdem weiter. Der MDB-Bus der in den heutigen Verkaufsautomaten verwendet wird, wird fast ausschließlich zu Zahlungszwecken benutzt. Die eigentlichen Verkaufsdaten werden in einem EVA-Protokoll meistens direkt von der Automatensteuerung ausgelesen und werden nur selten über den MDB-Bus übertragen. Um den MDB-Bus zu nutzen bzw. zu protokollieren, muss der Mikrocontroller in der Lagen sein Daten mit 9600 baud und 9 Datenbits zu verarbeiten. Ob das mit dem Raspberry Pi möglich ist kann ich nicht sagen. Bei dem MDB-Protokoll verwendet der VMC (Vending Master Control, also die Steuerung) 9-Bits um zu kennzeichnen das es sich um einen Befehl handelt und die Zahlungseinheit verwendet bei der Antwort die 9-Bits um die Checksumme zu Signalisieren. Die restlichen Daten werden mit 8-Bit ausgetauscht. Wie gesagt, ob das mit dem Raspberry Pi möglich kann ich nicht sagen.
Das will der TE doch alles gar nicht wissen. Der sucht(e) doch nur einen billigen Jakob der das für ihn macht. Für nen Bier und ne Rote am Vereinsfest. Die einzige Möglichkeit so jemanden zu finden wäre wenn dieser in dem Verein wäre.
Hallo leute ich möchte oder besser bin dabei auch ein solches projekt zu realisieren. augenblicklich hängt es an dem raspberry pi auch unser verein wollte eine getränkeautomaten in seinen vereinsräumen aufstellen um der ständigen last mit den nichtbezahlten getränken herr zu werden. zurzeit ist in planung/realisierung ein normaler betrieb mit münzen später vllt auch scheinen eine rfid technik für bargeldloses bezahlen füllstandsüberwachung der einzelnen schächte also der normale betrieb funktioniert zumindest schon mal testweise mit einem einfachen uart verbindung pc <-> rasbperry nächster schritt wird nun sein dem rasbperry das MDB protkoll beizubringen hier gibts ja einiges zu berücksichtigen nicht nur das zu dem start, stop und 8 datenbits ein modebit mitgesendet wird sonderen auch das die richtigen werte zugeordnet werden. :D es gibt eine menge befehle man kann sich aber glaub ich auf die wichtigesten beschränken nachlesen kann man das in gekürzter fassung hier https://reaktor23.org/de/projects/mate_dealer/mdb_protokoll#muenzprueferwechsler um das bezahlen mit rfid chip zu realsieren sollte man, so meine meinung, eine datenbank anlegen und dort dann das guthaben hinterlegen aktuell kann man zwar nur das guthaben mit phpmyadmin direkt in die datenbank eintragen soll aber später automatisch gehen mal sehen wie weit ich komme. ergo soll man später wählen können zwischen einzahlung und normalbetrieb bei einzahlung wird das eingeworfene geld gezählt und dann in die DB eingetragen danach alles resetet. Mein Problem ist zurzeit das ich nicht ganz mit dem uart zurecht komm da ich theoretisch zwei brauche einen für die RFID technik und einen für das MDB Protokoll, weiß aber auch nicht ob das so einfach mit deo PI klappt wie ich mir das vorstelle
Hallo, meine Antwort kommt vielleicht auch etwas verspätet, aber in Sachen MDB-Bus und Sielaff-Automaten (FK und Robimat) kann ich dir sehr gut weiterhelfen. Denn selbst habe ich für unsere Firma ein Kreditsystem entwickelt was wir in Sielaff-Getränkeautomaten mehrfach einsetzen. Auch auf dem Raspy entwickelte ich in letzter Zeit diverse Projekte. Den Raspy direkt an den MDB-Bus zu hängen halte ich für nicht sinnvoll. Allein wegen 9N1 würde ich dir empfehlen einen Mikrocontroller einzusetzen. Zudem musst du den Master sowie den Slave abhören um alle Informationen zu erhalten. Dann kannst du Daten wie Schachtanwahl, Schachtausgabe, Leeranwahl, Preis und Art der Bezahlung abhören und an den Raspy zur Weiterverarbeitung übergeben. Ich kann dir eine BGR mit Mikrocontroller anbieten, die die Kommunikation Master und Slave vom MDB-Bus abhört und über USB weitergibt. Das hatte ich mir damals selbst entwickelt um unser eigenes System zu entwickeln. Gruß dayton
Hi dayton von der Idee den RASPY an die den MDB zu hängen bin ich auch schon von abgekommen. hatte die Spannungen durch Spannungsteiler auf 3,3V runterbekommen nur den RASPY nicht davon überzeugen können die ankommenden Signale zu verarbeiten, würde daher gerne dein Projekt verwenden um zu lauschen was auf dem MDB vor sich geht. Mir war es bis jetzt nur wichtig mit dem Münzprüfer eine Kommunikation hinzubekommen. Die anderen Befehle sollen alle vom RASPY erledigt werden. Ich muss jediglich vom Münzprüfer erfahren was eingeworfen wurde und ob es einen Abbruch gab (Geldrückgabe). Befehle an den Münzprüfe wären dann nur die Geldrückgabe. Ist so was möglich, nur mit einzelnen befehlen zu arbeiten? Oder muss man wirklich die gesamte Kommunikation nachbauen in diesem Fall?
Hallo, ich wäre ebenso an der Software von dayton interessiert. Wäre es möglich die zu erhalten? Viele Grüße Martin
Hallo, mich würde das Projekt und die Software interessieren . Wie komme ich daran um diese zu testen. Könnte mann ggf auch per EXE den Controller anschliessen? Wäre es ggf möglich den Raspy per Telemetrie anzurufen und eine Fernabfrage zu machen? Beste Grüße Ralf
hallo Dayton, können wir uns einmal über deine Möglichkeit des auslesen des Sielaff-Getränkeautomaten unterhalten. Es geht um ein Großprojekt 100-150 Automaten welche vielleicht mit deiner Karte BGR mit Mikrocontroller ausgestattet werden können. Also melde dich bitte einmal bei mir. Vielen Dank bumbumb
Ich weiss, das ist ein alter Thread, aber das Thema scheint mit Angesichts der wiederkehrenden Antworten weiterhin aktuell zu sein... Das Problem beim MDB sind nicht nur die "9bit", sondern auch die relativ engen Timinganforderungen (5ms Timeout usw.). Das lässt sich m.E. nur mit einem RTOS oder eben einem externen Mikrocontroller (z.B. PIC; darauf achten, dass der uC einen UART mit 9bit Support hat) realisieren. Ferner muss noch auf galvanische Trennung der Datenleitungen (Optokoppler) und die sehr grosse Betriebsspannungsbreite beim MDB Bus (14...42V soweit ich mich entsinnen kann) Rücksicht genommen werden. Wer zu Faul ist, so etwas selber zu basteln, kann z.B. hier ein fertiges Modul kaufen: http://blog.abrantix.com/webshop/ Es wird gemunkelt, dass in Kürze auch ein Modul für den Raspberry Pi (HAT) verfügbar sein soll...
Hallo, ich greife dieses Thema noch einmal auf, da es immer noch nicht ganz gelöst ist. Ich verfolge ein ähnliches Projekt wie der TS und habe die Hardware von Abrantix gekauft, welche auch gut funktioniert. Die Platine, die per USB an den PC anzuschließen ist empfiehlt sich in Verbindung mit hterm sehr gut zum Testen der Kommunikation mit dem Automaten. Nun stehe ich allerdings da: MDB-Verbindung zum Automaten funktioniert und Kommunikation auch. Aber wie kann ich jetzt die Daten aus dem Automaten abgreifen? Hat das schon mal jemand gemacht? Kann mir da jemand helfen bitte? Danke! :)
Kevin G. schrieb: > Aber wie kann ich jetzt die Daten aus dem > Automaten abgreifen? Kevin G. schrieb: > Aber wie kann ich jetzt die Daten aus dem > Automaten abgreifen? Welche "Daten" willst Du abgreifen? Alle Businformationen von Master und alle Slaves? Das Abrantix-Modul (resp. der MDB2Pi HAT) kennt in drei Betriebsarten: MASTER: Der MDB Converter ist Busmaster, d.h. er "spielt Automat" SLAVE: Der MDB Converter verhält sich wie ein MDB Slave - also z.B. zur Emulation eines "Cashless Device" gemäss MDB-Spezifikation. Er leitet alle an ihn adressierten Messages an den PC/Raspi weiter resp. antwortet dabei auf Nachrichten, welche an ihn adressiert sind. SNIFFER: Der MDB Converter rein ist passiv und leitet alle MDB Master- und Slave- Meldungen an den PC/Raspi weiter. Diese Option ist ab Firmware-Version 3.X enthalten. Ich vermute, Du willst diesen als "SNIFFER" betreiben, oder? Hierzu kannst Du den Converter (sofern Firmware V3.x verwendet wird) in den "MDB Logging" Mode setzen (Command 0x19 0x02) - danach werden alle Messages vom Bus geforwarded. Auch beim Sniffen gilt natürlich: selber machen geht auch: Den Master kann man gemäss MDB-Spezifikation via Optokoppler abgreifen, die Slaves kann man z.B. impedanzentkoppelt via MDB Master RX Leitung mitschneiden. Noch besser wäre natürlich eine galvanische Trennung der RX-Leitung, was jedoch wegen des gemäss MDB Spezifikation zulässigen Idle-Stromes (ca. 100uA, das habe ich nicht genau im Kopf) relativ aufwändig wird (z.B. aktive Optokoppler mit Impedanzwandlung mit galvanisch getrennter Speisung). Softwaremässig muss man dann noch die Befehle gemäss MDB-Spez. (u.A. Timing für das Framing) auseinanderdröseln.
:
Bearbeitet durch User
@Marco Menti: Also streng genommen möchte ich die EVA DTS Daten haben (http://www.vending-europe.eu/en/standards_protocols/eva-dts.html). Also den Report vom Automaten, denn damit kann eine genaue Statistik erstellen. Soweit ich weiß wäre der Automat dabei der Master und die Platine müsste dabei als Slave gedipt werden. Firmware ist eine 3.x auf dem Gerät. Ich probiere es einmal mit dem Logging-Mode. Wie bekomme ich es dann wieder in den "normalen" Modus? Einfach vom Strom trennen? Zu dem letzten Absatz: Übernimmt nicht genau diese Funktion die Platine? Da ich von Elektronik nicht so viel verstehe verlasse ich mich da lieber auf jemanden, der das ordentlich bauen kann :D @Arno A.: Ich bin dem Link gefolgt und habe mich in das Projekt MateDealer mal eingelesen: https://reaktor23.org/projects/mate_dealer Ist echt ne coole Sache nur leider nicht das, was ich vor habe ;) Trotzdem danke! :)
Kevin G. schrieb: > Wie bekomme ich es dann wieder in den "normalen" Modus? > Einfach vom Strom trennen? Nein, der MDB Mode wird im EEPROM vom Controller gespeichert und überlebt damit auch einen Power-Cycle. Um den Modus zu ändern, muss erneut ein "Command 0x19 XX" ausgeführt werden. > Zu dem letzten Absatz: > Übernimmt nicht genau diese Funktion die Platine? Exakt. Ich wollte nur darauf hinweisen, dass man das auch selber machen kann - ist ja schliesslich ein Elektronikforum und keine Werbeplattform :->
Marco M. schrieb: > ist ja schliesslich ein Elektronikforum und keine > Werbeplattform :-> Stimmt :) Aber grundsätzlich kann ich die EVA DTS Daten mithilfe dieser Platine auslesen, oder? da wird jetzt nichts gefiltert, das das verhindert, richtig?
Mit EVA DTS kenne ich mich ehrlich gesagt (noch) nicht aus. Soweit ich das verstehe, kann auch mit Hilfe des MDB Protokolls EVA DTS übertragen werden - resp. mit Hilfe des MDB Sniffers ein MDB-Automat EVA DTS compliant gemacht werden. MDB-seitig sollte nichts gefiltert werden - solange die MDB Spezifikation eingehalten wird.
Hm, schade :/ Ich werde mit dem Sniffer-Modus mal rumspielen und schauen, ob ich was erreichen kann. :)
Hallo Marco, ich habe noch eine kurze Frage: Wie genau versetze ich die Platine in den Sniffermodus? Ich nutze hterm und versuche "19 02" als command zu schicken. Ist das richtig so? Wieso erhalte ich da einen Fehler? https://abload.de/img/unbenanntlyuy6.png
Kevin G. schrieb: > Ich nutze hterm und versuche "19 02" als command zu schicken. Mit hterm habe ich das nie versucht - ich habe immer mit dem mitgelieferten SDK gearbeitet. "19 02" ist nur "Command" plus "PayLoad". gemeint Das Ganze muss noch in ein STX...DLE ETX Frame gepackt (und DLE-escaped) werden, also HEX "02 19 02 10 03"
Hallo miteinander, ich weiss, einige Zeit her .. MDB anzuschliessen wird allerdings immer wieder gesucht. Bei uns (Qibixx) gibts sowohl ein Standaloone MDB-USB als auch ein MDB PI Hat interface dass man direkt auf den Pi stecken kann. Beide Geräte können einfachst sniffen, von Haus aus (in der Firmware) auch schon eine Cashless Device Emulation, und die gesamte Kommunikation ist ascii. Für die Snifferei reicht ein "X,1<CR>" auf der Schnittstelle und man bekommt die gesamten Protokolldaten mit 500uS Auflösung geschickt. Um EVA-DTS Datensätze zu übermitteln sollte man am besten ein "Universal Communication Device" implementieren, dass die Daten entgegennimmt und weiterleitet. Wer sich dran probieren möchte, am besten in Python, und am besten auf dem Pi, soll sich doch bitte bei mir melden, ich gebe den MDB Pi Hat dazu gratis ab wenn der Sourcecode dann auch veröffentlicht werden darf. Hier der Link zu den Produkten: [http://mdb.technology]. Einfach Kontaktform auf diesen Post hinweisen oder mich per email anschreiben (jr at qibixx). Versprochen: Gratis MDB Pi Hat und Versand innerhalb in Europa. Grüsse Johannes
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.