Ich habe ein paar dieser Netzwerk zu seriell Konverter bei Aliexpress gekauft und damit ein paar seltsame Effekte. Hat Irgendwer Erfahrungen mit den Dingern? https://www.usriot.com/products/serial-ttl-to-ethernet-module.html Gruß, Holm
Holm T. schrieb: > Hat Irgendwer Erfahrungen mit den Dingern? Bisher nicht. Liegt hier rum und wartet auf den Einbau. Was hast Du denn für Effekte?
Der TCP/IP Stack verhält sich teilweise seltsam, ich habe eine Art Packet-Krieg auf der Strippe, das USR Module sendet Connection Resets und mein BSD antwortet miteinem Zero Window Packet..worauf hin der USR Modul wieder ein Connection Reset schickt..das Ganze schaukelt sich auf. Ich habe bei USR den Support kontaktiert, die haben mir eine neue Firmware gemacht die sich von der vorhergehenden nur darin unterscheidet das der USR Modul nicht mehr nach einer Weile abstürzt und neu bootet... Gruß, Holm
Angehängte Dateien:
Ich bin jetzt dazugekommen das USR-TCP232-T2 Modul in mein Projekt zu
integrieren. Ich möchte den Wandler im TCP-Server oder im
UDP-Server-Mode betreiben.
Die Konfiguration wollte ich nicht mit dem Windows-Tool machen. Der
erste Versuch war es, dem Ding ein paar Hexwert zu schicken (0x55 0xBD
oder so).
Keine Reaktion, egal mit welcher Baudrate. Die Hexwerte muss man
wahrscheinlich über die Netzwerkschnitt hinschicken.
Nächster Versuch: AT-Kommandos
Das funktionierte so wie in der Anleitung beschrieben ("+++" und dann
ein 'a'), Schnittstelle auf 115200/8N1. Allerdings sind im Manual böse
Copy&Paste-Fehler drin :-/
Trotz Konfiguration gab es keine Kommunikation.
Dritter Versuch: Die Weboberfläche. Die meldet sich mit Version v4016
und man kann offensichtlich tatsächlich alles konfigurieren (im
Gegensatz zur AT-Schnittstelle). Die Einstellungen werden scheinbar erst
nach Restart gültig, aber die Kommunikation funktionierte. Auf der
PC-Seite habe ich netcat verwendet. Das kann sowohl TCP als auch
UDP-Kommunikation.
Heartbeat und das Löschen von alten TCP-Verbindungen habe ich
deaktiviert.
Connection Resets konnte ich nicht beobachten, dafür stimmt beim
ARP-reply die FCS nicht. Windows 7 nimmt das Paket trotzdem...
Ich habe die Module über den AT-Kommandosatz konfiguriert bekommen, man muß nur erst mal rausfinden was wo versteckt ist. Die conenction Resets traten bei mir im TCP-Server Modus auf, wenn die Telnet (oder netcat) session auf einen Timeout lief und die Maschine ein FIN Paket schickte. Statt einer normalen Beendigung gabs dann ein Connection Reset..das FreeBSD isteressanter Weise mit einem Zero-Window beantwortet (weiß nicht warum)..was dann wieder von mit einem Connection Reset des Modules beantwortet wird ...das ging mit der originalen Firmware so lange bis der USR-Modul abstürzte und rebootete. Ich habe eine neue Firmware erhalten, die stürzte nicht mehr ab, macht aber genau den selben Senf. Die Chinesen sehen nicht ein das ihr "a little nonstandard way" hier stört, angeblich würde sonst was Anderes nicht gehen. Da ich aber zu Hause nicht den Blumentopf überwachen will sondern 1000 Stück im Kundeneinsatz geplant waren war es das. Ich habe keine Ahnung was beim Kunden im Netzwerk läuft und ob ich den großen Laden damit lahm lege. Ich werde mir also was Anderes ausdenken müssen. Meine Anfrage nach SPI Interface wurde verneint, auf deutsch übersetzt wären die User zu blöde das einzusetzen weil es zu kompliziert sei..ja nee, is klar. Gruß, Holm
Angehängte Dateien:
Holm T. schrieb: > Die conenction Resets traten bei mir im TCP-Server Modus auf, wenn die > Telnet (oder netcat) session auf einen Timeout lief und die Maschine ein > FIN Paket schickte. Statt einer normalen Beendigung gabs dann ein > Connection Reset Bei mir verhält sich das Ding unauffällig, ich habe mir das trotzdem nochmal angeschaut. Ich bin jetzt mit TCP nicht so firm, aber das was im Wireshark zu sehen ist, sieht anders aus, als bei der Wikipedia: https://de.wikipedia.org/wiki/Transmission_Control_Protocol#Verbindungsabbau Zum einen ist das RST als Antwort auf FIN komisch und die Absende-IP des allerletzten ACK vom USR-TCP232-T2 ist völlig gaga. Offenbar ist der TCP-Stack von Windows relativ tolerant (und der vom USR-TCP232-T2 teilweise broken). Bei Gelegenheit schau ich mir das mal mit Linux an.
Ich habe letzte Woche ein USR TCP232-T2. Ich beobachte dasselbe Fehlverhalten mit diesem Modul wie seit 2 Jahren schon mit den TCP232-302: Wenn ich mit einem beliebigen Programm (netcat, hyperterm oder selbstgeschriebenen Programmen) versuche, beispielsweise ein etwa 50 kByte grosses File über die Socket-Verbindung zu senden, blockieren diese Module jedesmal nach etwa 20-25 s. Dann geht nichts mehr. Die Module sind bei mir als TCP-Server konfiguriert und die serielle Schnittstelle ist auf 9600 Baud eingestellt. Es kommen also auf der RS232-Seite nur etwa 20-25 kByte heraus. Ich habe auch noch ältere Module von USR IOT und zwar die TCP232-2. Diese funktionieren einwandfrei. Ich habe schon zweimal bei USR IOT Tickets aufgemacht aber die glauben mir nicht. Das Testprogramm von denen https://www.usriot.com/support/downloads/usr-tcp-test-testing-software.html funktioniert auch nicht. Hat jemand vielleicht diesen Effekt auch schon beobachtet ?
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.