Moin,
vielleicht kann mir ja jemand einen Tip geben:
Ich arbeite hier mit einem von irgendeiner Firma selbstgestrickten
Protokoll welches über den RS485 Bus tickert.
Datenanzeige funktioniert z.B. mit H-Term einwandfrei. Ich würde nun
aber gerne das Protokoll prüfen, Checksummen validieren, Informationen
herauslesen was welches Byte an welcher Stelle bedeutet(also ich weiß
das natürlich größtenteils, würde das aber gerne automatisch anzeigen
lassen)
Ich kann nun natürlich ein komplettes Programm bauen, Daten einlesen,
irgendwie anzeigen usw usw. was mit viel Aufwand verbunden wäre
Gibt es evtl schon etwas fertigeres, was z.B. über eine
Scriptsprache/Plugins erweiterbar ist und ich nur noch die
Protokollauswertung implementieren muss und ich schon mehr Hilfsmittel
zur Visualisierung geben hätte. Also eine Art Framework
Später wäre es natürlich schön, wenn ich mir Datenpakete auch selbst
generieren könnte zum Testen, aber das wäre nur nice to have und da
rechne ich nicht damit das es da Möglichkeiten gibt
Oder sind die Anforderungen insgesamt zu speziell?
Danke für Input
dunky schrieb:> Ich kann nun natürlich ein komplettes Programm bauen
Na dann mach das, es ist ja nicht wirklich schwierig zu schreiben. Mit
Delphi oder Lazarus und einer Comport-Komponente ist sowas in einer
halben Stunde fertig geschrieben.
Immerhin hast du dann etwas, das du wirklich an deine Bedürfnisse
anpassen kannst.
W.S.
Ziemlich einfach wird es mit einem Kommandozeilen-tool.
Sorge dafür, dass Du eine SW bekommst, sie irgendwie ein oder n Zeichen
aus der Schnittstelle lesen kann. Und dann printe jedes Zeichen in hex
raus. Mit Zeilenumbruch beim Anfang eines neuen telegramms.
Und dann füge nach und nach Auswertungen, Parameter etc hinzu.
Speichern? Die ersten paar tausend Zeilen einfach kopieren.
Mehr? In eine Textdatei pipen.
Analysieren? Mit jedem Tool, z.b. Excel, regulären Ausdrücken,
Verarbeitung? Programm erweitern.
Für all das brauchst Du weder Fileoperationen noch GUI.
Wenn du sowieso über Scripts das Protokoll zerlegen willst, warum nimmst
du dann nicht einfach eine Scriptsprache für das öffnen des Ports?
In Python sind das scheinbar 3 Zeilen an Code.
Interessanter wird es je nach Protokoll den Anfang/Ende des Frames aus
der Bytewurst herauszufinden.
danke für den ganzen Input. Werde mal testen.
Python oder ähnliches wäre natürlich auch eine Idee, aber da muss auch
viel drumherum gestrickt werden. Ich wußte halt nicht, ob es sowas wie
WireShark(was man imho auch erweitern kann wenn man weiß wie) auch mehr
für serielle Schnittstellen gibt.
N. M. schrieb:> Wenn du sowieso über Scripts das Protokoll zerlegen willst, warum nimmst> du dann nicht einfach eine Scriptsprache für das öffnen des Ports?
Ganz meine Meinung.
Vor allem kann man das dann in der Script-Sprache schreiben die man
kann, und ist nicht an die des Terminal-Programms gebunden.
Die paar Minuten Arbeitszeit die man verliert weil man einen Port
aufmachen muss, hat man ganz schnell wieder herinnen.
Ich würde allerdings Tcl verwenden. ;-)
Gibt es auch Terminalprogramme, die statt 8 auch 9 bit übertragen? Oder
verhindert das die PC-Hardware.
HTerm kann jedenfalls nur 5-8 Bit, wobei man das Parity-Bit auch
manipulieren könnte. HTerm kennt auch 1 1/2 Stopbits, das hatten früher
die Fernschreiber mit 45,45 Bd. Cutecom kann nur 1 oder 2 Stopbits.
>selbstgestrickten Protokoll welches über den RS485 Bus tickert
genau das ist hier auch der Fall. Im 9.Bit wird Daten/Befehlsbyte
unterschieden, wie man es von Textdisplay nach "Industriestandard"
kennt.
Das Terminalprogramm muss die Datenrichtung auf dem Bus automatisch
umschalten. Dazu gibt es USB-RS485-Wandlersticks (sogar bei Conrad) mit
FTDI oder CH340 Chip.
Die Umschaltung macht anscheinend ein Mosfet, der die Sendedatenleitung
über Vorwiderstand am Gate hat. Vermutlich bleibt das Gate einfach
kapazitiv aufgeladen, bis ein Byte durchgelaufen ist, dann wird der
RS485-Treiber auf Empfang umgeschaltet.
Christoph db1uq K. schrieb:> Das Terminalprogramm muss die Datenrichtung auf dem Bus automatisch> umschalten.
Was muss man denn bitte zum Mitlesen umschalten?
Wenn es nur um Mitlesen ginge.
Ein PC hat normalerweise keine RS485-Schnittstelle, und die
Datenrichtungsumschaltung ist für RS232 unnötig. Also muss ein
Schnittstellenwandler diese Info irgendwoher bekommen. Die Datenangaben
dazu sind sehr dürftig bis nicht vorhanden. Ich habe nur eine Schaltung
gefunden, in der das so mit einem Mosfet gelöst ist.
Conrad Nr. 1020913 (15,12 €, es gibt anderswo auch Preise um 3€) ist so
ein Beispiel. Wie die Richtungserkennung und -umschaltung funktioniert
steht nirgends.
https://cdn-reichelt.de/documents/datenblatt/A300/RB-RS485_2017_01.pdf
hier ist die Schaltung mit dem Mosfet
dunky schrieb:> Ich wußte halt nicht, ob es sowas wie> WireShark(was man imho auch erweitern kann wenn man weiß wie) auch mehr> für serielle Schnittstellen gibt.
Gibt es schon. Die Dinger nennen sich protocol-Analyzer und kosten
typischerweise ein paar tausend Euro.
Ansonsten magst du vielleicht freie Software verwenden: Sigrok und
PulseView. https://sigrok.org/
Ich würde es allerdings auch scripten.
Wenn man das Protokoll grundsätzlich kennt, also wie ein Packet
aussieht, dann kannst man es über eine RS485->USB Wandler am PC mitlesen
und jedes Packet z.B. per UDP ins Netzwerk schicken.
Dazu für Wireshark einen entsprechenden dissector (z.B. in LUA)
schreiben und fertig. Wenn das Protokoll komplex genug ist, kann sich
dieser Aufwand durchaus lohnen. Wireshark ist sehr gut zur Auswertung
von Protokollen geeignet.
Das PC-Programm muss dazu "nur" den Port des RS485 Wandlers öffnen, die
Daten mitlesen, die Packet herausfilter und über UDP versenden.
Vorteil: Alles kostenlos. Nachteil: Man muss halt etwas programmieren
können bzw. es lernen wollen.
Christian P. schrieb:> Das PC-Programm muss dazu "nur" den Port des RS485 Wandlers öffnen, die> Daten mitlesen, die Packet herausfilter und über UDP versenden.
Du brauchst es noch nicht Mal über eine richtige Schnittstelle
versenden. Man kann auch die empfangenen RS485 Daten intern auf eine
Wireshark PIPE umleiten.
Den hier hatte ich eigentlich gemeint
Conrad 2149078-AW mit CH340 Chip, Onlinepreis 3,89 €, Filialpreis 4,18
€
Ich meine immer noch, das Terminalprogramm sollte einen zeitlichen
Abstand zwischen Senden uns Empfangen beherrschen. RS232 ist im Prinzip
"vollduplex", Senden und Empfangen ist völlig entkoppelt, solange man
keinen Handshake benutzt. RS485 ist "halbduplex", wenn das automatisch
schalten soll, braucht man einen zeitlichen Sicherheitsabstand. HTerm
und ähnliche wissen nichts davon.
Das betrifft natürlich nicht das reine Mitlesen. Oben stand aber auch
für später "Datenpakete auch selbst generieren" auf der Wunschliste.
Für die Saleae Logic Analyzer gibt es High Level Analyzer die in Python
geschrieben werden können:
https://support.saleae.com/extensions/high-level-analyzer-quickstart
Der LA kann erstmal serielle Protokolle interpretieren, mit dem Vorteil
das man hier das Ping Pong Timing genau sieht.
