Getränkeautomat MDB Raspberry o. Ä.

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 :(

Bevor nur alles schlecht geredet wird...kennt jemand vielleicht einfach 
einen Hersteller der das schon fertig vertreibt?

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

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,

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.

@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"