Hallo,
ich versuche gerade eine Motorsteuerung, die noch in einem laufenden
System hängt, anzusteuern. Leider gibt es keine Doku dafür.
Auf der Platine befinden sich ein PIC16F1619 und ein CAN-Transceiver vom
Typ MCP2561.
Mein erster Gedanke war daher gleich CAN-Bus. Mit einem CAN-Hat (MCP2515
CAN-SPI Receiver) an einem Raspberry habe ich leider keinen Teilnehmer
gefunden.
Also habe ich den MCP2515 ausgelötet und einen Logikanalyzer angesteckt.
Was mir folgendem Daten geliefert hat:
-> 1 Bit = 52µs => Baud-Rate 19200
-> 97 Bit lang
-> zyklisch gesendet alle 20ms
-> Daten: 0000 0100 0111 0100 0000 0011 0101 0000 0011 0000 0000 0011
0011 0100 0011 1111 0000 0000 0011 0000 0000 0110 0000 0000 0
Von der Länge her könnte es ein CAN-Bus sein, jedoch ist die
Geschwindigkeit sehr gering und bei weiterer Analyse der Platine habe
ich entdeckt, dass RX/TX auf Pin 4 und 5 vom PIC hängen. Das sind beim
PIC16F1619 lediglich Timer-Eingänge. Der PIC hat keinen CAN Receiver und
daher muss das Protokoll softwareseitig realisiert sein.
Ich werde nun einen Analyzer programmieren, welcher die übertragenen
Daten vergleicht und beim ersten Auftreten ausgibt. Dadurch kann ich die
gesendeten Kommandos in der Steuerung detektieren und eventuell eine
Struktur erkennen.
Daniel schrieb:> 0000 0100 0111 0100 0000 0011 0101 0000 0011 0000 0000 0011 0011 0100> 0011 1111 0000 0000 0011 0000 0000 0110 0000 0000 0
Aus dem Oszi-Screenshot meine ich UART-Frames zu erkennen. Mal
8n2-Format angenommen, wären das 11 Bit-Zeiten pro UART-Frame. Dazu
müsste auf die Stopbits gleich das Startbit folgen. Du hast da 97 Bits
aufgelistet. Wenn ich mir am Ende zwei Stopbits hinzu denke, komme ich
auf 99 Bits. Kommt da was sinnvolles bei raus?
mfg mf
Wenn das Signal wirklich vernünftig verschlüsselt ist, hast du ohne
Kenntnis des Schlüssels und des Schlüsselverfahrens keine realistische
Chance. Du kannst allenfalls die physikalische Übertragung (OSI Layer 1)
raustüfteln, also die übertragenen Rohdaten gewinnen, kommst aber nicht
an den Dateninhalt, i.e. die (entschlüsselte) Bedeutung ran.
p.s.
Aber mal ehrlich: Warum vermutest du, dass die Daten verschlüsselt sind?
Solange das Steuergerät in einer abgeschlossenen Anlage sitzt und damit
nicht eine Ultrazentrifuge für Uran-Anreicherung betrieben wird, kommt
doch kaum jemand auf die Idee, soetwas kryptographisch abzusichern.
Das könnte ein asynchrones serielles Protokoll mit 1 Startbit, 9
Datenbits, und 1 Stopbit sein. Die Pausen zwischen den einzelnen Frames
haben eine variable Länge, was aber bei asynchroner Übertragung ja legal
ist. Im Beispiel schwanken die PÜausen zwischen 0,5 und 4,5 Bit-Zeiten:
1
Start Daten Stop Pause
2
—————————————————————————————
3
0 000010001 1 1,0
4
0 100000000 1 1,0
5
0 101000000 1 1,0
6
0 000000000 1 1,0
7
0 011010000 1 4,5
8
0 000000000 1 1,0
9
0 000000001 1 0,5
10
0 000000000 1 4,0+
11
—————————————————————————————
Das 9. Bit ist kein Parity-Bit, da die Anzahl der 1-Bits im Beispiel
teilweise gerade, teilweise aber auch ungerade ist.
Daniel schrieb:> ich entdeckt, dass RX/TX auf Pin 4 und 5 vom PIC hängen. Das sind beim> PIC16F1619 lediglich Timer-Eingänge. Der PIC hat keinen CAN Receiver und> daher muss das Protokoll softwareseitig realisiert sein.
Ich habe zwar jetzt das erste Mal in das Datenblatt von dem PIC
geschaut, aber für mich sieht das so aus als ob Pin 5 RX vom EUSART ist
und TX auf fast jeden Pin gelegt werden kann.
Mich wundert nur, dass Pin 4 auch noch der Reset Pin ist.
Edit: wie man auf dem Bild erkennen kann hängt der Transceiver auf Pin 5
und 6 mit RXD und TXD.
Edit2: ich habe den 14 Pinner genommen, das macht aber nichts, RX und TX
können wohl frei verschoben werden, Pin 12 ist nur default für RX vom 20
Pinner.
Rudolph R. schrieb:> Daniel schrieb:>> ich entdeckt, dass RX/TX auf Pin 4 und 5 vom PIC hängen. Das sind beim>> PIC16F1619 lediglich Timer-Eingänge. Der PIC hat keinen CAN Receiver und>> daher muss das Protokoll softwareseitig realisiert sein.>> Ich habe zwar jetzt das erste Mal in das Datenblatt von dem PIC> geschaut, aber für mich sieht das so aus als ob Pin 5 RX vom EUSART ist> und TX auf fast jeden Pin gelegt werden kann.> Mich wundert nur, dass Pin 4 auch noch der Reset Pin ist.>> Edit: wie man auf dem Bild erkennen kann hängt der Transceiver auf Pin 5> und 6 mit RXD und TXD.>> Edit2: ich habe den 14 Pinner genommen, das macht aber nichts, RX und TX> können wohl frei verschoben werden, Pin 12 ist nur default für RX vom 20> Pinner.
War ein Fehler vom mir, meinte RC4 und RC5 statt Pin4 und Pin5. Du hast
aber recht, EUSART RT/TX kann an jeden Pin gemapped werden (habe ich im
Datenblatt übersehen). Somit könnte es wirklich über die USART
Schnittstelle ausgewertet werden.
Meine Analyse mit einen RS232-USB Kabel und IO Ninja hat jedoch nichts
brauchbare ergeben. Mit 19,2k Baud und unterschiedlichen Konfigs für
Datenbreite, Stoppbits und Parity kamen keine konstanten Daten. Kann
leider keine 9Bit einstellen.
Etwas interessantes hat sich jedoch ergeben, als ich den Motortreiber
vom Bus getrennt habe:
- Das erste High Signal ist nur noch Halb so lang => 24µs = 1Bit
- Ein Response kommt vom Motortreiber unmittelbar auf den Request
Leider kann ich die gezielt getriggerte Aktionen mit meinem Logik
Analyzer nicht aus dem Datenstream herausfiltern, dafür baue ich gerade
ein Analysetool mit einem STM32. Kämpfe aber gerade noch mit einem
Timer-Interrupt, der nicht wie gewünscht funktioniert.
minifloat schrieb:> PS. Kannst du gesampelte Rohdaten von busanalyse.png posten? vcf- oder> sonstiges ASCII-Format?
Immer noch aktuell. Kann dein PC-Pszilloskop da ungefähr sowas hier
exportieren??
1
Timestamp Ch0 Ch1
2
0.000000 0 0
3
0.000001 1 0
4
0.000002 1 1
5
0.000003 0 0
Leute aus dem Forum versuchen den Kram dann auch auszuwerten. Mit den
Bildern kann man kaum was anfangen.
mfg mf
minifloat schrieb:> minifloat schrieb:>> PS. Kannst du gesampelte Rohdaten von busanalyse.png posten? vcf- oder>> sonstiges ASCII-Format?>> Immer noch aktuell. Kann dein PC-Pszilloskop da ungefähr sowas hier> exportieren??>
1
> Timestamp Ch0 Ch1
2
> 0.000000 0 0
3
> 0.000001 1 0
4
> 0.000002 1 1
5
> 0.000003 0 0
6
>
>> Leute aus dem Forum versuchen den Kram dann auch auszuwerten. Mit den> Bildern kann man kaum was anfangen.>> mfg mf
Ich kann eine CSV-Datei und eine MSD-Datei anbieten.
Auf der Hersteller-Seite kann man das Programm herunterladen und dann
die MSD Datei öffnen.
https://www.linkinstruments.com/mso28_setup_web_64bit.exe
Daniel A. schrieb:> Etwas interessantes hat sich jedoch ergeben, als ich den Motortreiber> vom Bus getrennt habe:> - Das erste High Signal ist nur noch Halb so lang => 24µs = 1Bit
Die verkürzten High-Phasen könnten daher kommen, dass du mit dem
Motortreiber auch gleich den Busabschluss (der evtl. im Motortreiber
integriert ist) entfernt hast. Ohne Busabschluss wird zwar schnell von
rezessiv nach dominant (high->low) geschaltet, aber nur sehr langsam
von dominant nach rezessiv (low->high), abhängig von parasitären
Kapazitäten und Kriechströmen. Das führt zu verlängerten Dominant-
bzw. Low-Phasen und damit zu verkürzten Rezessiv- bzw. High-Phasen.
Du kannst das nachprüfen, indem du dir mit deinem MSO-28 im Oszimodus
die Differenz zwischen CAN-H und CAN-L anschaust.
Verzeiht meine Laienhafte Frage,
aber wäre es nicht einfacher zu sehen ob man eine
ähnliche ggf besser dokumentierte Motorsteuerkarte findet gleichen
Herstellers, in der Hoffnung sie benutzt kompatible Formen der
Kommunikation?
Oder man meisselt den PIC auf und liesst sich durch was der Hersteller
da reingeschrieben hat, bildlich gesprochen.
mal wild geraten..
6 controlbits, 8 datenbits(oder vielfaches) und 8 stopbits (0x00)
und ein paritybit am Ende
klingt doch garnicht sooo an den Haaren herbeigezogen, oder?
Zufällig ...
0x01 (ersten 6 Controlbit) Start of Heading
0x1D (folgenden 8 Datenbit) Group Separator
0x06 (letzten 8 Datenbit) Acknowledge
sid schrieb:> Verzeiht meine Laienhafte Frage,> aber wäre es nicht einfacher zu sehen ob man eine> ähnliche ggf besser dokumentierte Motorsteuerkarte findet gleichen> Herstellers, in der Hoffnung sie benutzt kompatible Formen der> Kommunikation?>> Oder man meisselt den PIC auf und liesst sich durch was der Hersteller> da reingeschrieben hat, bildlich gesprochen.
Ja natürlich wäre es einfacher, wenn es ein Standardprodukt am Markt
geben würde, dann hätte ich es schon gekauft. Leider ist dem nicht so.
Es ist eine spezielle Anwendung mit über 60 Stk 12W Motoren.
Ich habe schon eine neue Platine auf STM32 Basis entwickelt mit ein paar
Zusatzfeatures, das dauert aber wieder 1-2 Wochen bis alles bei mir
ist... Bin aber unter Zugzwang und muss das Teil schnellstmöglich zum
Laufen bekommen.
Hätte auch schon überlegt den PIC mit neuer Software zu flashen.
Auslesen wird nicht möglich sein, da bestimmt das Lock-Bit gesetzt ist.
Ich probiere es aber trotzdem, sag niemals nie :-P
Mit etwas Glück kann ich ihm die Konfig-Bytes für die Schnittstelle
entlocken.
Yalu X. schrieb:> Die verkürzten High-Phasen könnten daher kommen, dass du mit dem> Motortreiber auch gleich den Busabschluss (der evtl. im Motortreiber> integriert ist) entfernt hast. Ohne Busabschluss wird zwar schnell von...
Das könnte eine Erklärung sein, denn der Bus-Abschluss war wirklich
nicht gesetzt, habe vergessen den Jumper am CAN-Board zu setzen.
Ich hätte vermutet, dass der Client den Bus auf Low zieht um seine
Anwesenheit zu Bestätigen. Bei weiterer Überlegung macht es aber keinen
Sinn, da der Signalverlauf danach gleich aussieht. Bin daher deiner
Meinung.
Vllt. hilft die Funktionsbeschreibung ein wenig bei der Auflösung:
- 8 High Side Treiber
- 10 Low Side Treiber
- 2 digitale Eingänge für Lichtschranke (Signal, Error)
- 2 Analogeingänge
- laut Beschreibung 2x RS485 Schnittstelle (jedoch mehrere Abweichungen
bei der Pin Belegung im Schaltplan, also nicht glaubwürdig)
Das Board dient zum Ansteuerung von bis zu 80 Motoren in
Matrix-Verkabelung (oder wie man das nennt).
Der Drehgeber ist sehr interessant realisiert. Es wird mit einem
Mikroschalter pro Umdrehung 2 Mal eine kurze Unterbrechung im Stromkreis
erzeugt. Der Mikroschalter ist nämlich am Öffner und Schließer Kontakt
kurzgeschlossen, sodass beide Schaltzustände den Motor laufen lassen.
Lediglich die kurze Unterbrechung von Offen auf Geschlossen wird im
Stromkreis eine Spitze verursachen, die der PIC sehr wahrscheinlich
misst. Eine Kreisförmige Nocke mit Flachstelle verursacht auf ca. 1/3
des Umfangs einen Offen-Zustand.
Jeder Motor soll genau eine Umdrehung machen. Daher denke ich, dass der
PIC nur die Position des Motors in der Matrix erhält und daraufhin die
Reihen und Spalte entsprechend ansteuert werden. Beim Zweiten Impuls
stoppt der Motor dann.
Aufgrund der bereits implementierten Funktion wäre es wünschenswert,
wenn ich das Teil ansteuern könnte.
Yalu X. schrieb:> Das könnte ein asynchrones serielles Protokoll mit 1 Startbit, 9> Datenbits, und 1 Stopbit sein.
Das habe ich mittlerweile auch rausgemessen und könnte wirklich die
Lösung sein.
Mein nächster Versuch vor dem Neubau wird also noch sein, das Teil mit
einem anderen Controller auszulesen. Mit einem FDTI-RS232-5V Kabel hatte
ich leider keine Chance, da es keine 9 Bit Datenlänge unterstützt.
Daniel A. schrieb:> Mein nächster Versuch vor dem Neubau wird also noch sein, das Teil mit> einem anderen Controller auszulesen. Mit einem FDTI-RS232-5V Kabel hatte> ich leider keine Chance, da es keine 9 Bit Datenlänge unterstützt.
Ja, aber die meisten µC (AV PIC, STM32 usw.) mit eingebautem UART können
das. Ansonsten kannst du ja immer noch einen Software-UART verwenden.
Daniel A. schrieb:> Yalu X. schrieb:>> Das könnte ein asynchrones serielles Protokoll mit 1 Startbit, 9>> Datenbits, und 1 Stopbit sein.>> Das habe ich mittlerweile auch rausgemessen und könnte wirklich die> Lösung sein.
ich denke es sind mindestens 10 bit und/oder variierend.
bei 151.5ms geht der Bus low als Start bit, high geht er erst bei 157ms.
das sind 11 Bitlängen, also 10 bit Information.
Weitere Frame Errors mit nur 9 bit bei 193ms, 276ms und 442ms (jeweils
start bit).
Da ich mit diesem recht komischen CSV nichts anfangen konnte hab ich mal
ein Script geschrieben um ein VCD für einen Kanal daraus zu machen.
Alle 1000 Samples sind binär entweder 11110110 oder 11110111, daher
enthält nur ein Kanal Informationen.
EDIT:
die MSD Datei hat als Zeitbasis 50µs, die CSV 500µs. Dementsprechend
sind alle Zeitangaben oben um den Faktor 10 zu groß. Wie auch immer wäre
eine etwas kleiner Zeitbasis besser bei deinen kurzen Pulslängen, so ca.
10µs oder weniger wären gut.
MSD:
0, 0us,0,-16.876,245,11110101,0,1500,0,00000000,
1, 50.000us,0,-21.3374000000001,245,11110101,0,1500,0,00000000,
2,100.000us,0,-21.3374000000001,245,11110101,0,1500,0,00000000,
CSV:
0, 0us,-44.174,-21.3374000000001,247,11110111,0,1500,0,00000000,
1,500.000us,-44.174,-25.7988,247,11110111,0,1500,0,00000000,
2, 1.000ms,-44.174,-21.3374000000001,247,11110111,0,1500,0,00000000,
K. S. schrieb:> Da ich mit diesem recht komischen CSV nichts anfangen konnte hab ich mal> ein Script geschrieben um ein VCD für einen Kanal daraus zu machen.> Alle 1000 Samples sind binär entweder 11110110 oder 11110111, daher> enthält nur ein Kanal Informationen.
Bit 0 ist Kanal 1 und dieser hing am Bus. Alle anderen Kanäle sind
random. Konnte es leider nicht anders exportieren..
Ich habe den Oszi Screenshot ausgedruckt und mit dem Messschieber
1 Startbit (LOW) | 9 Datenbits | 1 Stoppbit (HIGH)
gemessen. Denke also, dass das funktionieren würde.
Inzwischen hingen schon mehrere Arduinos am Bus, jedoch habe ich es noch
nicht geschafft 9 Bit über Softserial zu bekommen. Dazu wäre ein Hack in
der Library nötig und auf meinem MacOs finde ich die Libraries nicht :-(
Versuche daher gerade mit einem STM32-NUCLEO Board die Daten auszulesen.
Die Baudrate ist nebenbei bemerkt 9600. Habe einen 8N1 Stream ausgeben
und verglichen, sah ziemlich ähnlich aus.
Dann ist irgendetwas mit deinen exportierten Daten sehr sehr falsch.
die CSV enthält völlig andere Daten als die MSD, in der CSV ist ein 10
bit UART drin mit der Zeitbasis 500µs und einzelnen Datenpaketen. In der
MSD sind es 50µs Zeitbasis, ergibt immer noch nicht die 9600 Baud, aber
zumindest sieht das Signal in etwa aus wie auf den Bildern.
Mach das Bitte nochmal ordentlich bzw. überprüfe ob das mit der
Zeitbasis so stimmt. Selbst in der MSD ist ein Bit 50µs lang, das sind
immerhin 20k Baud. entweder ist da auch nur Müll drin oder beim Export
wird die Zeitbasis auf Müll gesetzt.
MSD:
HIER: v
58, 2.900ms,0,-21.3374000000001, 244,11110100,0,1500,0,00000000,
59, 2.950ms,0,-16.876, 245,11110101,0,1500,0,00000000,
60, 3.000ms,-44.174,-21.3374000000001,244,11110100,0,1500,0,00000000,
Wie man deutlich sieht ändert sich Kanal 1/ Bit 0 alle 50µs
In der MSD bekomm ich sowohl mit 9 als auch mit 10 bit Frame error,
irgend etwas stimmt da nicht.
Bis du ordentliche Daten lieferst bin ich hier raus.
Mein Python Script spuckt jetzt auch die UART Daten als Hex aus, aber
dafür brauch ich ordentliches Ausgangsmaterial, entweder als CSV oder
MSD, beides geht.
K. S. schrieb:> Dann ist irgendetwas mit deinen exportierten Daten sehr sehr falsch.
Das kann leicht sein. Das Programm für den Analyzer ist wirklich
schlecht und ich muss dafür sogar einen Windows PC laufen lassen.
Ich habe mehrmals gemessen und ein Bit ist 52-54µs lang. Baudrate von
19200 sieht jetzt besser aus.
Mein STM32 kann die Daten schon mal lesen und schreibt mir schon mal
Daten raus. Aber ich glaube da ist noch ein Fehler drin.
Daniel A. schrieb:> Ich habe mehrmals gemessen und ein Bit ist 52-54µs lang. Baudrate von> 19200 sieht jetzt besser aus.
19.2kBaud mit 20kHz Samplerate die du uns zur Verfügung stellst, fällt
dir was auf?
> Aber ich glaube da ist noch ein Fehler drin.
So wie es aussieht ist es eher 9N1 als 8N1. Auch hast du eine
Wiederholung alle 6 Byte, in der MSD Datei sind eher 8 Byte/
Übertragungen ein Paket.
Daniel A. schrieb:> Bin aber unter Zugzwang und muss das Teil schnellstmöglich zum> Laufen bekommen.
Im Hinblick darauf würde ich sagen poste schnellstmöglich vernünftige
und richtige Daten, alle die dir bis jetzt helfen wollen arbeiten mit
fehlerhaften Ausgangsdaten. Das heißt bei 19.2kBaud mindestents 100kS/s,
eher mehr. Und dann sollte man auch erwarten können dass wenn du schon
zwei verschiedene Dateiformate hochlädst beide denselben Inhalt haben
und nicht zwei völlig verschiedene Messungen enthalten.
K. S. schrieb:> 19.2kBaud mit 20kHz Samplerate die du uns zur Verfügung stellst, fällt> dir was auf?
Du kannst dir die Software MSO-28 herunterladen und den Datenstream
selbst exportieren und auch die Zeitbasis ändern. Ich denke, es ist ein
Fehler in der CSV-Export Funktion. Gemessen wurde mit 1ms/div bzw.
100kS, sieht man auch im Bild vom ersten Post. Die Daten stammen davon.
K. S. schrieb:> So wie es aussieht ist es eher 9N1 als 8N1. Auch hast du eine> Wiederholung alle 6 Byte, in der MSD Datei sind eher 8 Byte/> Übertragungen ein Paket.
Das hast du falsch verstanden. Ich lese den 9N1 Wert vom Bus,
konvertiere ihn im STM32 in 8N1 und gebe ihn über die zweite USART
Schnittstelle aus. Beide Signale habe ich mir am Oszi angesehen und bei
19,2kBaud stimmen die Länge für 1 Bit überein.
Ich habe mir den Signalverlauf ausgedruckt, mit dem Messschieber 11 Bit
eingestellt und überprüft wo es reinpasst. Könnten auch 9N2 sein, dann
wäre aber keine Pause zwischen den Daten.
K. S. schrieb:> Im Hinblick darauf würde ich sagen poste schnellstmöglich vernünftige> und richtige Daten, alle die dir bis jetzt helfen wollen arbeiten mit> fehlerhaften Ausgangsdaten. Das heißt bei 19.2kBaud mindestents 100kS/s,> eher mehr. Und dann sollte man auch erwarten können dass wenn du schon> zwei verschiedene Dateiformate hochlädst beide denselben Inhalt haben> und nicht zwei völlig verschiedene Messungen enthalten.
Beide Datensätze haben die selbe Ausgangsbasis. Am besten selbst mit dem
Oszi-Programm öffnen, geht auch ohne MSO-28. 100kS/s waren die
Messparameter.
Ich kann erst in einigen Stunden wieder an den Windows PC, versuche es
dann selbst nochmal zu konvertieren.
Daniel A. schrieb:> 100kS/s waren die Messparameter.
... von denen aber nur 20kS/s in der MSD- und 2kS/s in der CSV-Datei
angekommen sind. Nur in deinen Screenshots sind die vollen 100kS/s
erkennbar.
Daniel A. schrieb:> Beide Datensätze haben die selbe Ausgangsbasis. Am besten selbst mit dem> Oszi-Programm öffnen, geht auch ohne MSO-28. 100kS/s waren die> Messparameter.
Guck doch einfach mal auf die Bilder vom mir fünf Posts weiter oben. das
sind die Daten aus der CSV und MSD unverändert. willst du mir ernsthaft
erzählen dass das Daten von derselben Messung sind? Dann bleibt noch das
Problem, dass dort halt nur 20kSa drin sind und nicht die 100kSa, da
kann ich mit keiner Software der Welt was dran ändern. Du schon, wenn du
die Export Optionen richtig setzt.
> versuche es dann selbst nochmal zu konvertieren.
Das muss nicht sein, ich kann beide benutzen und dann eine ordentliche
Version hochladen. Die MSD ist nur eine CSV mit anderem Header, der
Inhalt ist gleich aufgebaut. Dass es trotzdem ein völlig anderer Inhalt
ist verwirrt schon etwas.
Daniel A. schrieb:> Das hast du falsch verstanden.
kann gut sein. in deinem Screenshot wiederholen sich Gruppen von 6 byte,
in der MSD Datei bilden 8 9N1 Übertragungen eine Gruppe. Entweder zeigt
dein Screenshot eine andere Messung, oder es fehlen Daten, oder ich habe
das falsch verstanden und der Screenshot enthält nicht die Daten die ich
denke.
Yalu X. schrieb:> und 2kS/s in der CSV-Datei
die enthält trotzdem einen gültigen UART mit 9N1 oder 10N1 und 1.92
kBaud (nicht 19.2k). Das ist aber schon alles, mehr hat der Inhalt nicht
mit dem Rest zu tun.
EDIT:
mein aktuelles Script im Anhang, es nimmt als Parameter ein oder mehrere
Dateinamen mit Endung (CSV oder MSD) und gibt ein VCD Datei (Value
change dump, nur Kanal 0, für mich zur Anzeige) und eine TXT Datei mit
den UART Daten aus. Konfiguration der Parameter findet noch im Script
selber statt, beim Testen war das einfacher.
K. S. schrieb:> Guck doch einfach mal auf die Bilder vom mir fünf Posts weiter oben. das> sind die Daten aus der CSV und MSD unverändert. willst du mir ernsthaft> erzählen dass das Daten von derselben Messung sind? Dann bleibt noch das> Problem, dass dort halt nur 20kSa drin sind und nicht die 100kSa, da> kann ich mit keiner Software der Welt was dran ändern. Du schon, wenn du> die Export Optionen richtig setzt.>>> versuche es dann selbst nochmal zu konvertieren.> Das muss nicht sein, ich kann beide benutzen und dann eine ordentliche> Version hochladen. Die MSD ist nur eine CSV mit anderem Header, der> Inhalt ist gleich aufgebaut. Dass es trotzdem ein völlig anderer Inhalt> ist verwirrt schon etwas.
Es stimmt, dass die CSV und MSD unterschiedlich sind. Woran das liegt
kann ich dir leider nicht sagen. In kürze kann ich wieder an den
Logik-Analyzer und dann checke ich die Daten bevor ich sie hoch lade.
Im Anhang findest du nun ein Bild von einem Low-Bit mit einem anderen
Oszi dem ich mehr vertraue.
Bit-Low Zeit: 52µs
Frequenz
Ich denke also, dass es 19200 Baud sind. Korrigiert mich bitte wenn ich
falsch liege.
K. S. schrieb:> mein aktuelles Script im Anhang, es nimmt als Parameter ein oder mehrere> Dateinamen mit Endung (CSV oder MSD) und gibt ein VCD Datei (Value> change dump, nur Kanal 0, für mich zur Anzeige) und eine TXT Datei mit> den UART Daten aus. Konfiguration der Parameter findet noch im Script> selber statt, beim Testen war das einfacher.
Welches Programm nutzt du zum weiteren Analysieren der Daten? Sieht ein
bisschen einfacher aus als das was ich gerade probiere.
Wunderbar, jetzt kann man was erkennen.
Daniel A. schrieb:> Welches Programm nutzt du zum weiteren Analysieren der Daten? Sieht ein> bisschen einfacher aus als das was ich gerade probiere.
zum Anzeigen/ testen benutze ich Pulseview, ist open source, kann aber
mit den etwas kompliziert aufgebauten MSD/CSV nichts anfangen, daher
konvertier ich nach VCD.
Dasselbe Script kann mit den richtigen Einstellungen (L15: timescale =
10, L29: UART_bit_cnt = 9 und L31: UART_baud = 5.2) auch direkt UART
Daten als Hex ausgeben. Frame Error (Stop bit = low) gibt es auch aus.
Hier mal die Ausgabe von deinem Teil Daten, hat mit runterladen ca. 30
Sekunden gedauert:
time: , MSB, LSB first
1.000ms, 011, 110
1.630ms, 100, 001
2.250ms, 140, 005
2.880ms, 000, 000
3.500ms, 0D0, 016
4.300ms, 000, 000
4.920ms, 001, 100
5.480ms, 000, 000
Jetzt zum eigentlichen Problem, um da irgendeine Chance zu haben etwas
zu entschlüsseln bräuchte man mehr Daten von bekannten Zuständen, am
Besten jeweils nur einen oder alle Motoren gleichzeitig ändern. Außerdem
wäre es gut wenn du die Initialisierung mitschneiden könntest, die
könnte auch wichtig sein für die Funktion.
Die alte MSD enthält drei mal dieselben Daten wie die Neue, alle 20ms
wiederholt.
Da das ganze Paket nur 72 Bit enthält wird es schwierig für über 60
Motoren (wie viele sind es denn genau?) mehr als an/aus zu übertragen.
Interessant wäre wie viele Zustände/Geschwindigkeiten man denn
einstellen kann, oder wird nur eine Sollposition vorgegeben und den Rest
macht der Treiber?
kannst du nochmals 1-2 Bilder von der Platine machen, aber diesmal bitte
so scharf dass man auch was lesen kann. bis jetzt sehe ich den Pic,
mcp256, 3 Shift register und 4 ULN2003A. das macht ohne Multiplexing
aber beim besten willen nur 32 Motoren und auch nur unidirektional, eher
24 da zwei ULN nur 4 Ausgänge sichtbar belegt haben und es nur 3 Shift
register gibt. Und Multiplexing ist mit ULN's auch nicht drin. schreib
mal so viel dazu was das Teil kann wie du weißt, das hat erheblichen
Einfluss auf die Menge der Übertragenen Daten udn damit auch auf das
Format.
K. S. schrieb:> Dasselbe Script kann mit den richtigen Einstellungen (L15: timescale => 10, L29: UART_bit_cnt = 9 und L31: UART_baud = 5.2) auch direkt UART> Daten als Hex ausgeben. Frame Error (Stop bit = low) gibt es auch aus.> Hier mal die Ausgabe von deinem Teil Daten, hat mit runterladen ca. 30> Sekunden gedauert:>> time: , MSB, LSB first> 1.000ms, 011, 110> 1.630ms, 100, 001> 2.250ms, 140, 005> 2.880ms, 000, 000> 3.500ms, 0D0, 016> 4.300ms, 000, 000> 4.920ms, 001, 100> 5.480ms, 000, 000
Vielen Dank. Das hilft mir zumindest schon mal die Daten auf dem STM32
zu verifizieren.
Bin gerade dabei ein UART Interface über DMA zu programmieren, damit ich
einen Analyzer in Python schreiben kann.
Mein nächstes Ziel wird es sein alle unterschiedlichen Codes
rauszufinden, indem ich die Funktion triggere und das Kommando somit
zuweisen kann.
Mit dem Datenstream im 50Hz Takt tue ich mir mit den jetzigen Werkzeugen
sehr schwer.
K. S. schrieb:> Da das ganze Paket nur 72 Bit enthält wird es schwierig für über 60> Motoren (wie viele sind es denn genau?) mehr als an/aus zu übertragen.> Interessant wäre wie viele Zustände/Geschwindigkeiten man denn> einstellen kann, oder wird nur eine Sollposition vorgegeben und den Rest> macht der Treiber?
Die Funktionsweise und den Aufbau hab ich weiter oben schon beschrieben.
Neues Frontalbild ist im Anhang. Hab leider von der Rückseite gerade
kein Foto, das ausbauen ist nicht so einfach...
Daniel A. schrieb:> Vllt. hilft die Funktionsbeschreibung ein wenig bei der Auflösung:> - 8 High Side Treiber> - 10 Low Side Treiber> - 2 digitale Eingänge für Lichtschranke (Signal, Error)> - 2 Analogeingänge> - laut Beschreibung 2x RS485 Schnittstelle (jedoch mehrere Abweichungen> bei der Pin Belegung im Schaltplan, also nicht glaubwürdig)
Verbaut ist das Teil in einem Snackautomat, die Treiberkarte steuert
einen 24VDC Motor mit max. 200mA. Da sich der Motor nur 1 runde Drehen
darf, unterbricht ein Kontakt sehr kurz 2x pro Umdrehung den Stromkreis.
Meine Vermutung ist, dass der PIC den Strom misst und somit den
Schaltpunkt detektiert.
Unterschiedliche Motorströme kann ich mir aufgrund des elektrischen
Aufbaus nicht vorstellen, da keine PWM-Nutzung ersichtlich ist. High und
Low Side sind mit ULN2003 ausgeführt. Auf der High-Side Schalten
Transistoren. Die Steuersignale kommen von 3 Stk. 8-Bit Shift Register.
Ich habe schon eine Ansteuerplatine eines anderen Herstellers mit
parallel Bus (ähnlich SRAM) gehackt. Dort war es ähnlich aufgebaut, aber
die Adressen und Funktionsweise konnte ich mir damals aus der
Verschaltung rauslesen. Der PIC ist diesmal eine richtige Spaßbremse :-(
Meine Vermutung ist daher, dass entweder der Wert der anzusteuernden
Position, oder die Reihe und Spalte übergeben werden.
Im Grunde ist es egal, es erzeugt beides ein eindeutige Bit-Muster das
man der Position zuweisen kann.
Bei dieser Anlage kann auch immer nur eine Reihe aktiv sein,
normalerweise aber mehrere Motoren pro Reihe.
Doppelspiralen, für die großen Produkte, sind bei diesem Gerät aber mit
Zahnrädern mechanisch gekoppelt, sodass in diesem Fall nur 1 Motor
verbaut ist.
Ich denke daher, dass sich der Wertebereich zwischen 1 und 80 bewegen
wird, oder die Reihe als Wert von 1-8 (4 Bit) und die Spalte als Wert
von 1-10 (4 Bit). Dies könnte daher in einem Byte abgebildet werden.
Die zyklische Kommunikation deute ich als Statusabfrage des
Lichtgitters. Das hängt nämlich auch noch auf diesem Board.
Das Lichtgitter befindet sich im untersten Bereich der Fallöffnung um
das Produkt zu detektieren. Bei anderen Geräten hat diese Aufgabe auch
immer ein PIC übernommen, der den Zustand speichert, welcher vom Master
wieder zurückgesetzt werden muss.
Der nötige Befehlssatz würde daher meiner Meinung nach lauten:
- Motor ansteuern -> mit Reihen und Spaltenanwahl (2x 4Bit) oder mit
Motoranwahl (6 Bit)
- Abfrage Motorstatus (dreht, steht, Fehler, ...)
- Lichtschranke abfragen
- Lichtschranke zurücksetzen
- Statusabfrage der Treiberkarte (eventuell nur ein Live Bit)
- Abfragen der Analogeingänge
Da es elektrisch ein Multislave System ist, denke ich auch, dass eine
Adressierung vorhanden ist.
das hilft schon mal sehr viel weiter beim Verstehen. Und wobei benötigst
du jetztt genau Hilfe?
kannst du z.b. 1-2 Sekunden lang Daten (mit dem Oszi/LA) aufnehmen und
einige Datensätze + Ereignis hier teilen? sobald das ungefähre
Datenformat entschlüsselt ist schreibt sich so ein Script zum Auswerten
deutlich leichter.
Wie sieht es mit den Antworten von der Platine aus, sind die interessant
bzw. kannst du die falls ja auch aufnehmen?
K. S. schrieb:> kannst du z.b. 1-2 Sekunden lang Daten (mit dem Oszi/LA) aufnehmen und> einige Datensätze + Ereignis hier teilen? sobald das ungefähre> Datenformat entschlüsselt ist schreibt sich so ein Script zum Auswerten> deutlich leichter.
Endlich habe ich es geschafft mit dem STM32 etwas zu empfangen:
Mit folgenden Einstellungen bekomme ich zyklische Daten:
19200 Baud
9 Bit
2 Stop Bit
Die Datenfolge lautet wie folgt und deckt sich mit der Analyse von dir:
0x110
0x001
0x005
0x000
0x016
0x000
0x100
0x000
Leider stoppt die Übertragung nach ca. 960 Bytes und startet nach einer
undefinierbaren Zeit wieder. Ich lese es mit folgendem Code aus:
Mittels eines Sniffer Programms habe ich es jetzt geschafft, die
unnützen Statusabfragen zu filtern und nur die getriggerten Kommandos
auszugeben.
Durch das ansteuern der Motoren konnte ich folgende Daten bekommen:
Byte 3: Eventuell Steuerbyte (0x01 = bei Motoren ansteuern, 0x05 bei Licht an, 0x04 bei Licht aus)
29
Byte 4: immer null bei Motoransteuerung
30
Byte 5: Spaltenanwahl (X)
31
Byte 6: Reihenanwahl (Y)
32
Byte 7: immer 0xx50 bei Motoransteuerug, eventuell bereits response des Motortreibers
33
Byte 8: CRC Prüfbyte
34
Byte 9: Ende, eventuell vom Master
Da ich in ein laufendes System sniffe, kann ich noch nicht genau sagen
ob Byte 7 oder 8 das Ende der Master Nachricht ist
Die Ansteuerung der Reihen und Spalten kann man aber schön erkennen. Die
Plätze sind wie erwartet binär Codiert entsprechend dem mechanischen
Aufbau.
Nach jeder Nachricht kommt immer die selbe Nachricht, deren Bedeutung
ist noch nicht kenne:
1
0x110 0x01 x0104 0x0
2
0x110 0x01
3
0x110 0x01
Danach oftmals noch diese Nachricht:
1
0x110 0x01 0x04 0x00 0x15 0x4 0x104 0x0
Wenn ich das Licht eingeschaltet ist dann sieht die Nachricht wie folgt
aus:
1
0x110 0x01 0x05 0x00 0x15 0x4 0x104 0x0
Welcher Teilnehmer was sendet ist hier noch nicht geklärt, daher ist der
Teil noch ein Rätsel für mich. Eventuell wird einer von euch daraus
schlau.
Als ich versehentlich einen Einlernmodus gestartet habe wurde folgendes
Kommando gesendet:
1
0x110 0x83 0x01 0x00 0x01 0x60 0x50 0x45 0x100
Danach kam sehr oft bis zum Ende des Einlernens folgende Folge:
1
0x110 0x01
2
0x110 0x01
3
0x110 0x15 0x01 0x04 0x00 0x15 0x04 0x104 0x0
und 1x die gleiche Folge mit 0x105 statt 0x104 beim vorletzten Byte.
Daniel A. schrieb:> Welcher Teilnehmer was sendet ist hier noch nicht geklärt, daher ist der> Teil noch ein Rätsel für mich.
wo misst du denn? ein CAN Bus hat einen Abschlusswiderstand, wenn ich
mich nicht täusche 120Ohm. Je nachdem ob/was für Abschlusswiderstände
wirklich vorhanden sind und was für Pegel jetzt vorhanden sind kannst du
auch einen kleinen Widerstand (evt. einige 10 Ohm) oder zwei
antiparallele Dioden (schottky Diode wäre besser) in den Signalweg
einschleifen, dann erkennt man mit einem Oszi anhand der Pegel wer
sendet und wer empfängt.
Kannst du nicht auch die TX/RX Pins zum Pic messen, da sollte doch
theoretisch dasselbe rauskommen?
EDIT:
ich hab noch ne gute Nachricht:
ich hab mal deine daten in "test_data.txt" gespeichert und folgendes
gemacht:
das Ergebnis (alle zahlen in hex, aber ohne 0x davor):
(berechnet, "CRC", differenz)
48, 48, diff: 0
54, 54, diff: 0
84, 84, diff: 0
35, 35, diff: 0
44, 44, diff: 0
74, 74, diff: 0
25, 25, diff: 0
28, 28, diff: 0
34, 34, diff: 0
64, 64, diff: 0
16, 16, diff: 0
24, 24, diff: 0
6, 6, diff: 0
8, 8, diff: 0
24, 24, diff: 0
44, 44, diff: 0
84, 84, diff: 0
F4, F5, diff: -1
F5, F6, diff: -1
74, 74, diff: 0
irgendwo ist noch ein kleiner Fehler im Code oder bei der Aufnahme der
Daten passiert.
der "CRC" scheint eine Summe von 0x83 bis 0x50 jeweils inkl., dann +15,
dann mod 255 zu sein.
wer sendet ist damit auch klar, außer den 0x00 müsste alles von dem
kommen der auch die Checksumme berechnet. Natürlich könnte die
Checksumme auch über empfangene Daten gehen, wäre aber etwas
ungewöhnlich.
Daniel A. schrieb:> Als ich versehentlich einen Einlernmodus gestartet habe wurde folgendes> Kommando gesendet:> 0x110 0x83 0x01 0x00 0x01 0x60 0x50 0x45 0x100
die 0x45 stimmen auch
Daniel A. schrieb:> Danach kam sehr oft bis zum Ende des Einlernens folgende Folge:0x110> 0x01> 0x110 0x01> 0x110 0x15 0x01 0x04 0x00 0x15 0x04 0x104 0x0
daraus kann ich noch keinen Sinn machen, da scheint keine erkennbare
Checksum drin zu sein. Das passt auch nicht zu dem normalen "Muster"
Die idle Übertragung scheint auch keien Checksum zu haben, das Feld ist
dort 0x00:
0x110 0x01 0x05 0x00 0x16 0x00 0x100 0x00
Obwohl das erste und letzte "Byte" 9Bit lang sind, scheint alles
dazwischen inkl. der Checksumme nur 8 bit lang zu sein.
Thomas Z. schrieb:> Nun ja ein Byte mit 0x110 wäre aber schon etwas seltsam. Das wird wohl> eher sowas sein:> 0x01 <Len> <der Rest>>> Thomas
Das System arbeitet mit 9 Bit und wird von einem STM32 in 8Bit
konvertiert und als Zeichenfolge am PC ausgegeben.
0x110 ist somit richtig.
K. S. schrieb:> wer sendet ist damit auch klar, außer den 0x00 müsste alles von dem> kommen der auch die Checksumme berechnet. Natürlich könnte die> Checksumme auch über empfangene Daten gehen, wäre aber etwas> ungewöhnlich.
In der Tat ist das ganze ein bisschen ungewöhnlich aufgebaut, hab auch
noch nie so ein "interessantes" Protokoll und Handshake gesehen.
Ich hab heute den schnellsten Weg gewählt und einfach den Client
abgeschlossen und einen Abschlusswiderstand am CAN Sniffer aktiviert.
Überraschenderweise geht der Master-Request bis inkl. 0x50. Also wie
folgt:
1
0x110 0x83 0x01 0x00 0x04 0x60 0x50
Die Antwort ist somit:
1
0x48 0x100
Es wird also wirklich der CRC im Client berechnet und zurückgeschickt.
Scheint als Art Acknowledge zu dienen, denn das Kommando wird vom Master
umgehend nochmal gesendet. Die Zeitverzögerung konnte ich mit dem
jetzigen System noch nicht aufzeichnen. Ist aber denke ich nicht weiter
von Belang.
K. S. schrieb:> irgendwo ist noch ein kleiner Fehler im Code oder bei der Aufnahme der> Daten passiert.
Das kann gut sein, bin noch bis 01:30 gesessen damit ich vernünftige
Daten bekommen habe und hab sie dann von Hand übertragen. Das Hirn war
willig doch die Augen schon schwach :-P
Zudem habe ich zwischenzeitlich keine Daten reinbekommen und sinnlos
Fehler gesucht, bis ich darauf gekommen bin, dass im Wartungsmodus keine
zyklische Übertragung stattfindet.
Die Checksum von 0x16 passt auf die ersten 4 Bytes. Danach kommt wieder
nur wirres Zeug.
Könnten abgebrochene Requests sein, bin mir nicht 100% sicher, da ich
dem STM32 auch nicht so recht vertraue. Könnte sein, dass das Schreiben
das Einlesen zu lang blockiert und Bytes verloren gehen.
Alternativ könnte auch alles 8N1 sein, nur die Datenpakete in der Mitte
haben alle eine Zero Parity, das würde erklären warum die länger sind.
Das würde auch erklären warum die Checksumme und Daten nur mit 8 bit
laufen.
Aus den ersten 0x110 würden dann 0x10
Aus den letzten 0x100 würden dann 0x00
das höchste Bit wäre dann jeweils schon ein fehlinterpretiertes Stop
Bit.
Wenn du die Zusatzfunktionen wie Anlernen oder Licht nicht brauchst ist
das Problem jetzt gelößt. Falls doch müsstest auch da mal die Richtung
rausfinden, denn die Pakete sind anders aufgebaut bzw. haben denke ich
keine Checksumme.
Der STM32 versteht nur 9N2, hab auch andere Varianten ausprobiert (8N1,
8N2, 9N1, 9N1.5).
Alle 8 Bit Einstellungen haben garnicht funktioniert. Bei 9N hat alles
ab 1 Stopp-Bit funktioniert. Am besten geht es mit 9N2. Die Daten sind
konstant und man erkennt ein Muster bei den getriggerten Daten.
Dass die Checksumme nur mit 8 Bit läuft ist denke ich ist
Softwareabhängig. Eventuell wollte sich der Programmierer nicht die
Arbeit antuen und noch das 9.Bit aus einer 16 Bit Zahl zu extrahieren um
es auf das USART Register zu schreiben. ;-)
S. R. schrieb:> Ich tippe ja schlicht darauf, dass ein 8 Bit-Protokoll verwendet> wird> und das neunte Bit fürs Framing benutzt wird.
Das kann der PIC16F1619 nicht, zumindest habe ich nichts in diese
Richtung im Datenblatt gefunden.
Daniel A. schrieb:> Das kann der PIC16F1619 nicht, zumindest habe ich nichts in diese> Richtung im Datenblatt gefunden.
Wie das neunte Bit zu interpretieren ist, entscheidet die Software
dadrin. Ich dachte an sowas wie eine Unterscheidung "Befehl/Daten"
(sieht man an Displays öfter), oder ein Synchronisations-Flag (=
Framing).
Wenn das so ist, dann trägt dieses Bit keine Daten im eigentlichen
Sinne. Das wiederum deckt sich mit der sinnigen Annahme, dass die
gesamte Verarbeitung nur 8-bittig ist, inklusive Checksum etc.
S. R. schrieb:> oder ein Synchronisations-Flag (=> Framing).
würde von allem bisher noch am meisten Sinn ergeben, der Master beginnt
mit einem 0x110 als Start, und der Slave endet mit einem 0x100, alle
dazwischen haben das neunte bit nicht gesetzt.
> Das wiederum deckt sich mit der sinnigen Annahme, dass die> gesamte Verarbeitung nur 8-bittig ist, inklusive Checksum etc.
das ist keine Annahme, das ist sehr sicher. Alle Nutzdaten die ich bis
jetzt gesehen habe sind nur 8 bit, und auch die Checksumme funktioniert
nur mit 8 bit, bei 9bit kommt nicht das Richtige raus.
Nur wie genau die berechnet wird weiß ich nicht:
Summe aller Daten + 0x0F mod 0xFF funktioniert.
aber auch alle Daten inkl. der 8bit von 0x110 (also 0x10) - 1 mod 0xFF
funktioniert.
Hier passt was nicht:
Daniel A. schrieb:> Mit abgestecktem Client bekomme ich nun folgende zyklische Nachricht:> Die Checksum von 0x16 passt auf die ersten 4 BytesDaniel A. schrieb:> Es wird also wirklich der CRC im Client berechnet und zurückgeschickt.
erstens müsste das 0x15 sein, und zweitens kann der Client keine
Checksum zurücksenden wenn er abgesteckt ist. Das wird nur Zufall sein
dass 0x16 fast passt.
Daniel A. schrieb:> Mit abgestecktem Client bekomme ich nun folgende zyklische Nachricht:> 0x110 0x01 0x05 0x00 0x16
das ist der Anfang der Idle Übertragung, danach würde vermutlich die
Antwort vom Slave 0x00 0x100 0x00 sein, oder zumindest ein Teil davon.
Man sollte die Checksumme auch nicht CRC nennen, denn es ist ja wirklich
nur eine Summe und nichts weiter. Ein CRC ist es auf jeden Fall nicht.
Was auch noch fehlt ist die Initialisierungs Sequenz, falls es eine
gibt. Irgendwoher muss der Master ja die Adresse(n) herbekommen, wenn da
wirklich wie behauptet ein Multi Slave System ist und die nicht alle
hardcoded sind.
Bin nun beim nächsten Schritt und sende ein paar Bytes in die
Treiberkarte rein. Der echte Master wurde abgeklemmt und der
Abschlusswiderstand auf meiner CAN Karte aktiviert.
Mit dem folgender Zeichenfolge hat es nicht funktioniert:
1
0x110 0x83 0x01 0x00 0x04 0x60 0x50
Das was am Bus rauskommt sieht am Oszi schon mal gut aus. Leider bewegt
sich nichts und ich bekomme keine Rückantwort.
Also wieder zurück zum Analysieren
Habe nun einen kompletten Dump im Einrichtebetrieb gemacht und dabei die
Motoren der ersten und zweiten Etage nach der Reihe angesteuert. Die
fünfte Ansteuerung schlug fehl, weil kein Motor montiert war. Es sollte
daher auch eine Fehlermeldung zurückkommen.
Die restlichen Ansteuerungen wurden erfolgreich abgeschlossen.
Der erste Wert in dump.txt ist der Timestamp (nach Einschalten) und
danach kommt der Hex-Wert.
Bis zum Zeitpunkt 10010ms vermute ich einen Overflow Error beim USART.
Der Timeout der Receive Funktion ist 1sec, danach wird bei TIMEOUT das
Overflow Flag gelöscht und neu empfangen. Es dauert immer ein paar Bytes
bis er wieder im Takt ist.
Ich lese sicherheitshalber 1kB in den RAM bevor ich sie übertrage.
ES IST GESCHAFFT => Mein Controller kann nun einen Motor ansteuern
Es müssen alle 8 Byte gesendet werden. Von 0x110 bis zur Checksumme
kommt alles vom Master. Der Client sendet nur 1 Byte zurück (0x110).
Jetzt muss ich nur noch die Bedeutung der Statusbits rausfinden.
Nachdem ich die Spiralen ansteuern kann kümmere ich mich jetzt um den
Lift. Dieser wird ebenfalls über einen seriellen Bus angesteuert.
Laut Anleitung ein I2C Bus. Ich hab die Platine dennoch demontiert und
unter die Lupe genommen.
Werde dafür einen neuen Thread anfangen. Dieses Problem ist für mich zu
95% gelöst. Nur das Diagnose Kommando habe ich noch nicht genauer
analysiert und ich weis noch nicht ob es eine Funktion gibt, die ohne
längere Motordrehung das Vorhandensein des Motors zurückgeben kann. Wäre
ein nettes Feature zum Einlernen der Positionen.