Bushack bei Vending Machine

[Daniel A. (daniel_a32)]

Hallo,

ich habe schon 2x hier im Forum einen Bushack von seriellen Systemen 
gepostet und war jedes mal erfolgreich. Es ist immer wieder interessant 
zu sehen wie unterschiedlich die Konzepte verschiedener Hersteller sind 
und möchte euch daher nun ein wenig mehr daran teilhaben lassen.

Ziel ist es, mit einem neuen STM32 Controlerboard so viel alte Hardware 
wie nur möglich anzusteuern.

Nun habe ich einen Trommelautomat aus dem Jahre 2008 hier. Elektronisch 
gesehen ist er mit 2 Boards ausgestattet, eines davon habe ich schon 
genauer unter die Lupe genommen und die wesentlichen Teile 
nachgezeichnet.

Hier kann der Schaltplan eingesehen und auch Kommentiert werden:
https://easyeda.com/cnc.auer/fas-driver
Videos und Fotos gibt es auch auf Instragram:
https://www.instagram.com/p/B6GFFvPpChS

Das ganze ist Teil eines kommerziellen Produkts, welches ich mit meinem 
Unternehmen gerade realisiere. Diese alten Automaten baue ich zum 
Großteil aber nur des Spaßes wegen um, daher ist kein großer Zeitdruck 
dahinter.

Sollte jemand dennoch Interesse haben beruflich mitzuwirken, dann kann 
er sich gerne bei mir melden. Wir suchen wieder neue Mitarbeiter ;-)

Aber nun zum Thema
Die Funktionen

Der Automat hat eine große Trommel mit 10 Ebenen. Jede Ebene verfügt 
über mehrere Fächer, in denen die Produkte gelagert werden.
Jede Ebene hat auch ein Schiebe-Fenster, welches über einen 24VDC 
Getriebemotor geöffnet wird. Ein Mikroschalter pro Fenster detektiert, 
ob das Fenster offen ist.

Die Trommel wird über einen 230VAC Motor mit einer hohen Untersetzung 
angetrieben. Direkt am Antriebszahnrad befindet sich ein 5V 
Quadratur-Encoder.

Auf dem Leistungstreiber-Board befindet sich ein Renesas (oder 
Mitsubishi) M30624 Controller mit Flash. Mein erster Gedanke war, diesen 
neu zu Programmieren und mir das Problem mit dem Bushack zu ersparen.
Meine Recherche hat jedoch ergeben, dass dieser Controller nicht neu 
programmiert werden kann, wenn man die vorher programmierte ID nicht 
kennt. Also entweder auslöten und neue MCU einlöten, oder Bus hacken.

Da die Leistungsansteuerung ziemlich gut gelöst ist, habe ich den 
Schaltplan für ein Neudesign schon mal nachgezeichnet.

Im Grunde ist das Prinzip sehr einfach. Pro Motor ist ein Relais 
vorhanden, welches den Motor mit einem Anschluss auf die H-Brücke legt. 
Ein zweites Relais legt den gemeinsamen zweiten Anschluss eines jeden 
Motors ebenfalls an die H-Brücke und somit kann jeder Motor in beide 
Richtungen mit nur einer H-Brücke angesteuert werden. Die Abschaltung 
geschieht über eine Strommessung und eine Op-Amp Schaltung, die ich 
nicht mehr nachgezeichnet habe. Würde das selbst über einen 
Analog-Eingang lösen.

Der Automat kam zerlegt zu mir und als ich ihn heute zusammengebaut 
hatte, funktionierte er auf Anhieb.
Daher nahm ich Abstand von einem Neudesign des Leistungstreiber-Boards 
und versuche nun die alte Elektronik anzusteuern.

Auf der Hauptplatine (mit dem Hirn) befindet sich ein Optokoppler, auf 
der Leistungstreiber Seite hingegen nicht. Man kann also sagen, es ist 
ein halber RS422 Bus.

Ich habe umgehend meinen Logic Analyzer dazwischen gehängt und einen 
Dump vom Datenstream gemacht. GND habe ich nur an einem der beiden 
Signale angeschlossen (Kanal 0 im Stream). Ich wollte vermeiden eine 
Masseschleife über den Logic Analyzer zu erzeugen. Interessanterweise 
kommt auf Kanal 7 auch etwas rein, das sich ein wenig mit Kanal 0 deckt. 
Ich denke also, dass es ein Response sein wird. Es könnte daher auch ein 
I2C Bus sein.

Leider kommen diese Daten zyklisch mit 3Hz daher und man muss erst die 
wichtigen Informationen rausfiltern um sie weiter Analysieren zu können.

Meine Schritte werden nun wieder wie folgt sein
1. Bussystem herausfinden, Bit, Datenrate usw.
2. Bussystem in STM32 einstellen und Daten auslesen
3. Filter erstellen und nur neue Kommandos ausgeben

Damit kann ich dann wieder sukzessive verschiedene Daten gewinnen, 
welche ich dann Vergleiche und somit die Struktur dahinter erkenne.

Ich vermute, dass in dem im Anhang befindlichen Stream (Sigrok 
PulseView) folgende Daten enthalten sind:
1. Außentemperatur
2. Innentemperatur
3. Systemzustand (Licht an/aus, Klimakompressor an/aus, Tür offen/zu, 
...)

Innentemperatur und Außentemperatur werden LCD Display angezeigt und 
kontinuierlich aktualisiert, somit ist es sehr wahrscheinlich, dass die 
Information drin steckt.

Da ich bei der Baudrate auf 9708Hz komme, könnte es UART mit 9600Baud 
und 1% Abweichung sein. Ich bin aber noch nicht auf vernünftige Daten 
gekommen und probiere daher noch mit anderen Bussystemen.

[Daniel A. (daniel_a32)]

Da die Signale keinen Sinn für mich ergeben haben, habe ich nochmal 
Einzelmessungen gemacht und dabei GND und Signal vertauscht.

Jetzt sieht es besser aus.
Leider läuft auf meinem MacBook sigrok-cli nicht, daher kann ich nicht 
komfortabel über die Shell analyiseren. :-(

Die Einstellungen sind
9707 Baud
8 Datenbits
Parity Even

Vllt. kann hier jemand schnell helfen die Daten zu analysieren.
Die Temperatur Betrug 10°C und 15°C (oder 14°C). Dies sollte in den 
Daten abgebildet sein.

[Daniel A. (daniel_a32)]

Die Daten aus dem Stream sehen nun wie folgt aus:

Request    ->  Response                  
89 12 42 44 44    -> A2 6 41 31 31 41        
89 12 41 44 43    -> A2 6 41 36 31 46        
88 1C      -> A6 6 31 32 30 30 30 30 43 46
89 12 42 44 44    -> A2 6 41 31 31 41        
88 1C      -> A6 6 31 32 30 30 30 30 43 46
89 12 41 44 43    -> A2 6 41 34 31 44

Ich denke daher, dass 0x88 0x1C ein Schreibkommando ist. Eventuell wird 
hier der Klimakompressor Status gesetzt.

0x89 0x12 könnte das Lese Kommando sein. Das dritte und vierte Byte das 
Register und das fünfte Byte die Prüfsumme.

Als ASCII ausgewertet kommt bei 89 12 41 44 43 folgendes zurück:
'A41' sowie 'A61'

Bei 89 12 42 44 44:
'A11'

Rückwärts ausgewertet ohne 'A' kommt somit 14, 16 und 11 raus. Das würde 
sich mit den angezeigten Daten so halbwegs decken.