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
Hallo, versuche es mal mit LKterm. Damit kann man schon einiges über Skripte erledigen.
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.
awk (https://de.wikipedia.org/wiki/Awk) Infos: http://www.ostc.de/awk.pdf https://www-user.tu-chemnitz.de/~hot/unix_linux_werkzeugkasten/awk.html für Windows z.B. gawk (http://gnuwin32.sourceforge.net/packages/gawk.htm) - oder Powershell? -
:
Bearbeitet durch User
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.
ZOC ist aber kommerziell. Der Autor ist sehr freundlich und hat meine Fragen gern beantwortet.
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.
Oder einfach einen HP 4954A kaufen ...
>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
:
Bearbeitet durch User
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.
Angehängte Dateien:
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.