Hallo, ich habe ein Digiforce 9310 von burster über die Ethernet-Schnittstelle mit dem lokalen Netzwerk verbunden. Mit der Software DigiControl hab ich das Gerät gesucht und es wird als online angezeigt (die IP Adresse habe ich per Hand in das Gerät eingegeben und der Port ist der Standardport). Ich kann ebenfalls das Gerät von meinem PC aus anpingen. Wenn ich aber versuche über das Hyperterminal mit dem Gerät zu kommunizieren, kann ich keine Verbindung aufbauen. Meine Frage: Ist es möglich mit dem Gerät per Ethernet-Schnittstelle zu kommunizieren? Wenn ja, wie? Ich habe schon versucht bei den Ansprechpartner von burster anzurufen, aber die Techniker befinden sich momentan alle noch im Urlaub. LG Böckle
:
Verschoben durch User
Böckle schrieb: > Meine Frage: Ist es möglich mit dem Gerät per Ethernet-Schnittstelle zu > kommunizieren? Wenn ja, wie? steht doch alles in der doku Dieser UDP-Port darf zur Kommunikation nicht durch eine Firewall geblockt werden. Der Standard UDP-Port im Auslieferungszustand ist im DIGIFORCE sowie im DigiControl 9310 der Port 8364. Wie das Protokoll aussieht, konnte ich auf die schnelle nicht finden.
War Hyperterminal nicht ein Programm für die serielle Schnittstelle ? Bei irgendwas über Netzwerk hätte ich jetzt ein Programm wie Putty erwartet.
Putty ist eher fuer FTP. Fuer ein freies Protokoll wuerde man mit einen Compiler, Library und Sockets anfahren, und dann entweder, TCP oder UDP Sockets verwenden.
fop schrieb: > War Hyperterminal nicht ein Programm für die serielle > Schnittstelle ? > Bei irgendwas über Netzwerk hätte ich jetzt ein Programm wie Putty > erwartet. Hyperterminal ist kein Problem, die Kommunikationseinstellungen müssen aber richtig konfiguriert werde. Als aller erste würde ich ein Oszilloskop an Bus anschließen und die Signale bzw. Protokoll überprüfen: -Wie sehen Signale in beide Richtungen beim Ping aus -Was wird bei der Übertragung über Hyperterminal gesendet. P.S.: es ist relativ egal, ob es über Hyperterminal oder Putty kommuniziert wird. Ich denke: da stimmen nicht irgend welche Einstellungen.
Erstmal vielen Dank für die vielen und schnellen Antworten! Ich habe es jetzt mit einem anderen (offenen) Port probiert, wie es Peter vorgeschlagen hat, aber leider ohne Erfolg. Alex T. schrieb: > Als aller erste würde ich ein Oszilloskop an Bus anschließen und die > Signale bzw. Protokoll überprüfen: > -Wie sehen Signale in beide Richtungen beim Ping aus > -Was wird bei der Übertragung über Hyperterminal gesendet. Ich werde es jetzt mal über Bus probieren. Den RS232 wollte ich nicht benutzen...
Böckle schrieb: > Port probiert, wie es > Peter vorgeschlagen hat, aber leider ohne Erfolg. wie hast du es probiert? auch beachtet das es UDP ist?
Böckle schrieb: > Ich werde es jetzt mal über Bus probieren. Den RS232 wollte ich nicht > benutzen... Es ist alles Bus: sowohl RS232 als auch Ethernet ;) Und bei beiden würde ich zuerst mit dem Oszilloskop oder Busmonitor arbeiten. So ist es einfacher.
Alex T. schrieb: > Es ist alles Bus: sowohl RS232 als auch Ethernet ;) > Und bei beiden würde ich zuerst mit dem Oszilloskop Ethernet mit dem Scope? Respekt, für Gigabit musst du ja ein feines Teil haben MfG Klaus
Klaus schrieb: > Ethernet mit dem Scope? Respekt, für Gigabit musst du ja ein feines Teil > haben Ok, für Ethernet ein Busmonitor verwenden.
https://www.burster.de/fileadmin/user_upload/redaktion/Documents/Products/Manuals/Section_9/BA_9310-Vxxx0_DE.pdf UDP ab Seite 19
:
Bearbeitet durch User
Peter II schrieb: > wie hast du es probiert? auch beachtet das es UDP ist? Bei meinem PC blockiert die Firewall keine Ports, von daher hätte es auch mit dem Standardport funktionieren müssen. Alex T. schrieb: > Es ist alles Bus: sowohl RS232 als auch Ethernet ;) > Und bei beiden würde ich zuerst mit dem Oszilloskop oder Busmonitor > arbeiten. So ist es einfacher. Ok, bin noch nicht so erfahren mit Hardware ^^' bin im 1. Semester (Technische Informatik) und habe bis jetzt nur programmiert. Mein Ausbilder hat mir eben noch Wireshark ans Herz gelegt. Er fande die Idee mit dem Oszilloskop gut, aber bisschen viel und ich soll schauen, ob es eine einfachere Lösung gibt.
Alex T. schrieb: > Ok, für Ethernet ein Busmonitor verwenden. Das Debuggen von TCP/IP, insbesondere wenn man die Gegenstelle schon mal pingen kann, spielt sich auf einer ganz anderen Ebene ab. Da braucht man sowas wie Wireshark und TCP Knowhow, aber weniger einen Busmonitor. RS232 und Ethernet mit TCP/IP in einen Topf zu werfen ist nicht zielfördernd. MfG Klaus
Mit Putty, Hyperterm o.ä. kannst Du nur über TCP kommunizieren. Handelt es sich um einen UDP-Port, brauchst Du schon einen passenden Client, der genau für diese Hardware gedacht ist.
Brummbär schrieb: > Mit Putty, Hyperterm o.ä. kannst Du nur über TCP kommunizieren. > Handelt es sich um einen UDP-Port, brauchst Du schon einen passenden > Client, der genau für diese Hardware gedacht ist. Ich hatte mir erhofft, dass mich da die besagt Software DigiControl von burster weiterbringt. Kennst du sonst noch andere Software für meinen Fall? Klaus schrieb: > Das Debuggen von TCP/IP, insbesondere wenn man die Gegenstelle schon mal > pingen kann, spielt sich auf einer ganz anderen Ebene ab. Da braucht man > sowas wie Wireshark und TCP Knowhow, aber weniger einen Busmonitor. > RS232 und Ethernet mit TCP/IP in einen Topf zu werfen ist nicht > zielfördernd. Danke für den Tipp Klaus :) versuche mich gerade in die Funktionsweise rein zu fitzen...
Klaus schrieb: > Alex T. schrieb: >> Ok, für Ethernet ein Busmonitor verwenden. > > Das Debuggen von TCP/IP, insbesondere wenn man die Gegenstelle schon mal > pingen kann, spielt sich auf einer ganz anderen Ebene ab. Da braucht man > sowas wie Wireshark und TCP Knowhow, aber weniger einen Busmonitor. Ich habe gedacht, dass Wireshark ein Bus-Monitor-Programm ist. Vielleicht irre ich mich.
Ich habe jetzt bei dem Filter in Wireshark die IP des Gerätes eingegeben mit Match destination: ip.dst == x.x.x.x leider kam dabei aber nichts mehr raus... bin gerade hilflos
Brummbär schrieb: > Mit Putty, Hyperterm o.ä. kannst Du nur über TCP kommunizieren. > Handelt es sich um einen UDP-Port, brauchst Du schon einen passenden > Client, der genau für diese Hardware gedacht ist. Kann man da nicht in den Programmeinstellungen zwischen UDP und TCP wählen?
Alex T. schrieb: > Ich habe gedacht, dass Wireshark ein Bus-Monitor-Programm ist. > Vielleicht irre ich mich. Nein, du irrst dich nicht. Aber so gings los Klaus schrieb: > Alex T. schrieb: >> Es ist alles Bus: sowohl RS232 als auch Ethernet ;) >> Und bei beiden würde ich zuerst mit dem Oszilloskop > > Ethernet mit dem Scope? Respekt, für Gigabit musst du ja ein feines Teil > haben Und ein Bus-Monitor-Programm, das keine extra Hardware braucht sondern auf dem eigen Rechner mitläuft, mit einem Scope in einen Topf zu werfen ist einfach daneben. MfG Klaus
Böckle schrieb: > Ich habe jetzt bei dem Filter in Wireshark die IP des Gerätes > eingegeben > mit > Match destination: ip.dst == x.x.x.x > leider kam dabei aber nichts mehr raus... bin gerade hilflos Ne blöde Frage: ist Wireshark für UDP geeignet (weiß ich wirklich nicht) Vielleicht lohnt es sich selbst eine einfachen UDP-Client zu schreiben? Z.B. in C#, C++ oder LabVIEW??
Klaus schrieb: > Und ein Bus-Monitor-Programm, das keine extra Hardware braucht sondern > auf dem eigen Rechner mitläuft, mit einem Scope in einen Topf zu werfen > ist einfach daneben. Meine Fehler: 1) ich habe an die hohe Frequenzen von Ethernet nicht gedacht 2) Nach dem Wort "Busmonitor" musste ich das Wort "Programm" schreiben. Gebe ich zu.
Alex T. schrieb: > Ne blöde Frage: ist Wireshark für UDP geeignet (weiß ich wirklich nicht) > > Vielleicht lohnt es sich selbst eine einfachen UDP-Client zu schreiben? > Z.B. in C#, C++ oder LabVIEW?? Bei deiner Frage kann ich dir leider auch nicht helfen, werde mir jetzt einen eigenen Client bauen.
Moin, Alex T. schrieb: > Ne blöde Frage: ist Wireshark für UDP geeignet (weiß ich wirklich nicht) Ja. Aber wenn das Geraet von sich aus nichts sendet, kann wireshark auch nix mitsniffen. Gruss WK
Dergute W. schrieb: > Ja. Aber wenn das Geraet von sich aus nichts sendet, kann wireshark auch > nix mitsniffen. Ja stimmt... jemand muss was senden, also ohne eigenen UDP-Client wird es gar nichts gehen.
:
Bearbeitet durch User
Du könntest im Prinzip auch einen bereits existierenden Packet Generator wie https://nmap.org/nping/ verwenden, dann musst Du den Packet Generator nicht noch neu erfinden.
Alex T. schrieb: > Ja stimmt... jemand muss was senden, also ohne eigenen UDP-Client wird > es gar nichts gehen. Mal mit netcat und Freunden probieren. Tools für TCP/IP gibts ja zu Hauf, ist ja die Basis für alle heutigen Netzwerke. MfG Klaus
Alex T. schrieb: > Meine Fehler: 1) ich habe an die hohe Frequenzen von Ethernet nicht > gedacht > 2) Nach dem Wort "Busmonitor" musste ich das Wort "Programm" schreiben. > > Gebe ich zu. [Klugscheißermodus] Die Frequenzen sind nicht das wirkliche Problem, eher die Kodierung der Signale. Für RS232 ist ein Scope (oder LA) mit einem Protokolldecoder schon die richtige Wahl [/Klugscheißermodus] MfG Klaus
> Für RS232 ist ein Scope (oder LA) mit einem Protokolldecoder schon die > richtige Wahl Was ist LA?
:
Bearbeitet durch User
Dergute W. schrieb: > Alex T. schrieb: >> Ne blöde Frage: ist Wireshark für UDP geeignet (weiß ich wirklich nicht) > > Ja. Aber wenn das Geraet von sich aus nichts sendet, kann wireshark auch > nix mitsniffen. Ich konnte mit Wireshark einige Pakete abfangen von dem Gerät, indem ich über Digicontrol den Port des Gerätes zur Laufzeit geändert habe. 1.) Der UDP-Client den ich habe funktioniert, aber leider wird nichts vom Digiforce empfangen da... 2.) ... die Nachrichten vom Digiforce verschlüsselt sind. Hat zufällig jemand Erfahrung mit verschlüsselten Paketen? In der Doku steht, dass man dies über die Konfig ändern kann. Geht es auch ohne?
Böckle schrieb: > Ich konnte mit Wireshark einige Pakete abfangen von dem Gerät, indem ich > über Digicontrol den Port des Gerätes zur Laufzeit geändert habe. dann zeige sie doch mal. > Hat zufällig jemand Erfahrung mit verschlüsselten Paketen? ich glaube nicht das sie verschlüsselt sind, vermutlich sieht du nur nicht den unterschied zwischen eine Binären Übertragung und einer wirklichen Verschlüsselung.
Peter II schrieb: > dann zeige sie doch mal. 0020 02 30 2c 32 2c 30 .< ..... ...0,2,0 0030 2c 30 2c 39 33 31 30 2c 56 32 30 31 30 30 32 2c ,0,9310, V201002, 0040 33 36 37 39 39 37 20 20 20 20 2c 32 32 2e 30 36 367997 ,22.06 0050 2e 32 30 31 31 2c 30 30 30 30 30 30 30 30 30 31 .2011,00 00000001 0060 2c 30 2c 33 2c 31 32 2c 30 2c 30 2c 30 2c 30 2c ,0,3,12, 0,0,0,0, 0070 66 66 66 66 30 30 30 30 2c 61 30 31 63 38 64 63 ffff0000 ,a01c8dc 0080 2c 56 32 30 31 30 30 30 2c 30 2c 30 30 2d 34 30 ,V201000 ,0,00-40 0090 2d 39 64 2d 33 66 2d 61 65 2d 32 66 2c 30 2c 30 -9d-3f-a e-2f,0,0 00a0 2c 30 2c 30 2c 30 2c 30 03 f5 ,0,0,0,0 .. Das sind die Daten aus dem 2. Paket von dem Gerät. Hoffe du/ihr kannst/könnt damit mehr anfangen als ich.
Peter II schrieb: > ich glaube nicht das sie verschlüsselt sind, vermutlich sieht du nur > nicht den unterschied zwischen eine Binären Übertragung und einer > wirklichen Verschlüsselung. Ich erkenne da schon einen Unterschied, sieht mehr nach Hex aus. Aber warum zeigt der UDP-Client keine Kommunikation mit dem Gerät an, funktioniert aber z.B. an meinem PC?
Böckle schrieb: > Das sind die Daten aus dem 2. Paket von dem Gerät. Hoffe du/ihr > kannst/könnt damit mehr anfangen als ich. nicht wirklich weil ich das gerät nicht kennen, und keine Ahnung was es macht. Aber die Übertragung sieht doch überhaupt nicht verschlüsselt aus, ist doch alles Klartext. du musst nur den Rechten Rand beachten, die Hexzahlen in der Mitte sind nur eine andere Darstellung davon.
Peter II schrieb: > Aber die Übertragung sieht doch überhaupt nicht verschlüsselt aus, ist > doch alles Klartext. > > du musst nur den Rechten Rand beachten, die Hexzahlen in der Mitte sind > nur eine andere Darstellung davon. Danke, dass hilft mir schon einmal weiter. Ich verstehe aber nicht ganz, was sie bedeuten sollen. In der Doku stehen unter dem Punkt "Aufbau und Fragmentierung von UDP-Telegrammen" nur: Format mit Daten (Wenn Antwort auf Befehl mit Frageform) <STX>Schlüssel,Kennung,Status,Nummer,Daten<Endezeichen>Blockcheck Format ohne Daten (Wenn Fehler oder auf Befehl ohne Frageform) <STX>Schlüssel,Kennung,Status,Nummer,<Endezeichen>Blockcheck Zudem ist der Status laut Doku nur so gekennzeichnet: Status: 0: alles o.k. 1: NAK 2: nicht benutzt 3: Timeout auf serieller Schnittstelle 4: STX nicht erkannt 5: Kennung nicht erkannt 6: ETX nicht erkannt 7: Checksummenfehler 8: Keine Antwort 9: unknown error A: Messung läuft B: Unerlaubte Host-IP-Adresse (statisch) C: Unverschlüsselte Nachricht empfangen, obwohl nicht erlaubt D: Ungültige Schlüssel Kennung E: Gerät wurde von einem anderen Master gesperrt (MAST! Befehl) Im Protokoll stehen aber andere Buchstaben und Symbole.
Böckle schrieb: > Im Protokoll stehen aber andere Buchstaben und Symbole. welche meinst du, zeige es ein genaues Beispiel.
Peter II schrieb: > welche meinst du, zeige es ein genaues Beispiel. Zum Beispiel an dem Paket welches ich vorns geschickt habe: die ganzen Punkte bzw. Kommas, Bindestriche/Minuszeichen, die Buchstaben V und f
Böckle schrieb: > Zum Beispiel an dem Paket welches ich vorns geschickt habe: die ganzen > Punkte bzw. Kommas, Bindestriche/Minuszeichen, die Buchstaben V und f dafür müsste man wissen, wo du nutzdaten vom UDP anfangen, es könnte sein das das noch reste vom UDP und IP Header sind. Eventuell mal screenshot vom Wireshark zeigen Du hast du das Protokoll: <STX>Schlüssel,Kennung,Status,Nummer,<Endezeichen>Blockcheck Was ist der Blockcheck?
.0,2,0,0,9310, V201002,367997 ,22.06.2011,00 00000001,0,3,12, 0,0,0,0,ffff0000 ,a01c8dc,v201000 ,0,00-40-9d-3f-a e-2f,0,0,0,0,0,0 .. 9310 ist das Gerät 22.06.2011 ist das Herstellungsdatum 00000001 ist der Name des Gerät v201002 ist die Version und 367997 ist die Seriennummer Peter II schrieb: > Was ist der Blockcheck? Blockcheck (nur bei serieller PC-Schnittstelle) Zur Vermeidung von Übertragungsfehlern aktivieren Sie Blockcheck! Diese Einstellung ist nur bei Datenformaten mit 8 Datenbits möglich. Ist aber standardmäßig ausgeschalten.
.0,2,0,0,9310, V201002,367997 ,22.06.2011,00 00000001,0,3,12, 0,0,0,0,ffff0000 ,a01c8dc,v201000 ,0,00-40-9d-3f-a e-2f,0,0,0,0,0,0 .. Also gehe wir davon aus, dass: ->.0,2,0,0 den Status und den angibt ->9310, V201002,367997 ,22.06.2011,00 00000001 die Kennung ist dann würde noch das übrig bleiben: 0,3,12,0,0,0,0,ffff0000 ,a01c8dc,v201000 ,0,00-40-9d-3f-a e-2f,0,0,0,0,0,0 0 steht für alles o.k. und 3 für Timeout auf serieller Schnittstelle (stimmt theoretisch auch, Anbindung ist nur über Ethernet). Wofür steht dann aber die 12?
Böckle schrieb: > Also gehe wir davon aus, dass: > ->.0,2,0,0 den Status und den angibt Fehler von meiner Seite. Meinte STX und Schlüssel.
Böckle schrieb: > 9310 ist das Gerät > 22.06.2011 ist das Herstellungsdatum > 00000001 ist der Name des Gerät > v201002 ist die Version und 367997 ist die Seriennummer Es ist doch alles gut: das Gerät sendet ein Info-String, wie es auch sein soll. Also, die Kommunikation wurde aufgebaut.
:
Bearbeitet durch User
Alex T. schrieb: > Es ist doch alles gut: das Gerät sendet ein Info-String, wie es auch > sein soll. > > Also, die Kommunikation wurde aufgebaut. Ja ich bin auch schon glücklich, dass mir das Gerät überhaupt etwas mitteilt. Ich kann aber über hyperterminal trotzdem keine Verbindung finden. Ich möchte ja die Befehle finden, auf die das Gerät reagiert, z.B. einen Test starten oder ein Ergebnis bzw. den Status holen. Soll ich das Gerät direkt per Ethernet an meinen PC anschließen oder gibt das keinen Unterschied im Vergleich zum Netzwerk?
Böckle schrieb: > Alex T. schrieb: >> Es ist doch alles gut: das Gerät sendet ein Info-String, wie es auch >> sein soll. >> >> Also, die Kommunikation wurde aufgebaut. > > Ja ich bin auch schon glücklich, dass mir das Gerät überhaupt etwas > mitteilt. > Ich kann aber über hyperterminal trotzdem keine Verbindung finden. Nochmal: ich habe Zweifel, dass es über Hyperterminal etwas gehen wird. Ich vermute, dass der Hyperterminal kein UDP-Protokol unterstützt. Und ich denke, dass UDP ein anderen Header hat als TCP, deswegen werden wahrscheinlich deine "Hyperterminal TCP-Packete" vom Gerät einfach nicht erkannt. Also, wie schon mal oben geschrieben, an deiner Stelle würde ich einen Beispiel-Programm-Kode in irgendeiner dir bekannten Programmiersprache für UDP-Server und UDP-Client suche. Diese verstehen, ein bisschen rumspielen (zuerst Kommunikation am Computer zwischen UDP-Server und Client aufbauen, mit Wireshark beobachten und mit Daten vom Gerät vergleichen). Danach kannst Du deinen UDP-Client an das Gerät entsprechend anpassen.
:
Bearbeitet durch User
Alex T. schrieb: > Nochmal: ich habe Zweifel, dass es über Hyperterminal etwas gehen wird. > Ich vermute, dass der Hyperterminal kein UDP-Protokol unterstützt. Und > ich denke, dass UDP ein anderen Header hat als TCP, deswegen werden > wahrscheinlich deine UDP-Packete vom Gerät einfach nicht erkannt. Sorry, du hast natürlich recht. Hterm arbeitet wenn dann mit TCP/IP... Alex T. schrieb: > Danach kannst Du dien UDP-Client an das Gerät entsprechend anpassen. Den Client hatte ich mir gestern noch gebaut (in C#). Ich schau mal, ob ich meinen Fehler finde oder ob ich noch was anpassen muss. Die Kommunikation zwischen Client und Server am PC funktioniert ja schon mal. Danke euch für die Mühe :-)
Böckle schrieb: > Sorry, du hast natürlich recht. Hterm arbeitet wenn dann mit TCP/IP... Echt. Wusste ich gar nicht. Ist dir der Unterschied zwischen TCP und UDP bekannt? Nicht alle Programme, die Unterstützung für TCP/IP bieten, haben auch UDP.
Dirk B. schrieb: > Echt. Wusste ich gar nicht. > > Ist dir der Unterschied zwischen TCP und UDP bekannt? > Nicht alle Programme, die Unterstützung für TCP/IP bieten, haben auch > UDP. Ja hab ich doch gesagt, dass Hterm UDP nicht anbietet, aber TCP/IP schon. Ist jetzt auch egal, ich kann über meinen UDP-Client als Sender und mit Wireshark als Listener mit dem Digiforce kommunizieren. Problem ist also gelöst. Danke nochmal an alle :)
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.