FlyingDoc Geschrieben March 1, 2016 at 08:50 Geschrieben March 1, 2016 at 08:50 Ich hake mich hier mal mit ein. Bei mir tritt das Problem der defekten Daten ebenfalls auf. ABer nicht immer. Die Schnittstelle wird zur Komunikation mit einem PC-Programm genutzt. So wie ich es bis jetzt mitbekommen habe kommt es ab und zu dazu, das die Schnittstelle nicht mit den korrekten Einstellungen arbeitet obwohl diese beim Auslesen korrekt sind. Wenn ich dann das Programm noch einmal neu starte funtioniert dann alles korrekt. Hab es getestet in dem ich an der Gegenstelle ein Terminalprogramm hab laufen lassen und geschaut hab was empfangen wird. Es scheint mir fast ein API Problem zu sein. Ich nutze die C++ API da mein Programm in C++ geschrieben wird und auf dem RED läuft. Tante Edit sagt: Es ist auch aufgetreten das die Einstellung mitten drin weg sind. Also wärend des Betriebes. Zitieren
Doncarlos Geschrieben March 1, 2016 at 09:52 Autor Geschrieben March 1, 2016 at 09:52 Hi, also ich hatte nun ohne weitere Tests das Bricklet an der Anlage laufen. - einmal hatt sich die Anlage aufgehängt - ein anderes mal sind nach 2 Tagen Laufzeit mit korrekten Daten wieder Schrottdaten gekommen. Allerdings anders schrottig; so ca. jeder 5-10 te Buchstabe war dann ein Punkt und die Länge hat noch so lala gepasst. Interessant war da auch, dass der Brickv gar keine Details mehr zum Red Brick angezeigt hat, er hat nur noch ewig aktualisiert. Nach einem Reboot ging es wieder. 2 Tage Laufzeit scheint eine Schallmauer bei meinem Aufbau zu sein. Ich hoffe ich komme dieses WE zu den versprochenen Messungen und Tests. Mittlerweile liegt auch ein galvanischer Trenner und ein USB-COM Adapter zuhause rum mit denen ich weiter testen kann. Zitieren
photron Geschrieben March 1, 2016 at 15:43 Geschrieben March 1, 2016 at 15:43 FlyingDoc, wie stellst du fest, dass das Bricklet nicht mit den richtigen Einstellungen arbeitet? Zitieren
FlyingDoc Geschrieben March 1, 2016 at 16:02 Geschrieben March 1, 2016 at 16:02 Am Müll den er sendet. Hab auf der Gegenstelle mit einem Terminalprogramm geprüft. Da ich genau weiss was ich sende weiss ich ja auch was ankommen müsste. Zitieren
photron Geschrieben March 1, 2016 at 16:19 Geschrieben March 1, 2016 at 16:19 FlyingDoc, wir haben gerade kurz in den Bricklet Code geschaut. Da ist auf den ersten Blick aber keine Möglichkeit drin, dass sich die Einstellungen im laufenden Betrieb von selbst ändern. Kannst du Testen, ob es wirklich, dass Neusetzen der Konfiguration ist, dass das Problem behebt? Oder ob es doch irgendetwas anderes ist, dass du beim Start deines Programms machst? Zitieren
Doncarlos Geschrieben March 1, 2016 at 16:21 Autor Geschrieben March 1, 2016 at 16:21 @Flyingdoc: Konntest Du eine zeitliche Abhängigkeit erkennen? Passiert das erst mit längerer Laufzeit oder auch schon vorher ? Zitieren
FlyingDoc Geschrieben March 1, 2016 at 21:14 Geschrieben March 1, 2016 at 21:14 Nein kann ich nicht. Es kann sowohl schon beim Programmstart als auch irgendwann mitten im Betrieb passieren. Die Anwendung ist dafür ausgelegt 24h am Tag/ 365 Tage im Jahr zu laufen. Zitieren
photron Geschrieben March 2, 2016 at 09:15 Geschrieben March 2, 2016 at 09:15 FlyingDoc, mit welchen Einstellungen nutzt du das Bricklet und hast du am PC noch eine richtige RS232 Schnittstelle, oder nutzt du eine weiteres RS232 Bricklet oder einen USB RS232 Adapter? Doncarlos' Einstellungen kenne ich schon. Ihr habt beide einen ähnlichen Aufbau, wenn ich das richtig verstehe. Also RED Brick mit Master Brick und RS232 Bricklet. Das RS232 Bricklet wird dann zur Kommunikation mit einem anderen RS232 Gerät (Heizung bzw. PC) genutzt. Welche RS232 und Bricklet Kabellängen benutzt ihr? Hintergrund ist, ich will hier mal einen Langzeittest aufbauen, um zu sehen, ob ich das Problem reproduzieren kann. Zitieren
FlyingDoc Geschrieben March 2, 2016 at 09:40 Geschrieben March 2, 2016 at 09:40 Einstellungen der RS232. 9600,Even,1,8,HFC unf SFC auf off Der Fehler tritt sowohl bei einer OnBoard Com Schnittstelle (Com1) als auch mit einer USB Com Schnittstelle auf. Die Kabellänge ist egal. Mein Testkabel ist gerade mal knapp 2m. Zitieren
Doncarlos Geschrieben March 2, 2016 at 13:03 Autor Geschrieben March 2, 2016 at 13:03 Meine RS232 Signale werden über ein 1m Cat5e Kabel zum Adapter/RS232Bricklet geführt. Das Bricklet ist mit einem 10cm Kabel am Master befestigt. Der Master steckt direkt am RED Brick. Ich könnte anbieten gewisse Ereignisse und Sachen mitzuloggen und so den Langzeittest zu unterstützen. Was mir in meinen Logs aufgefallen ist, dass die Verbindung oft wegbricht; dank "robustem" Ansatz mit Enumerierungs Event etc ist das ja egal; Aber warum bricht die Verbindung überhaupt weg ? RED+Master+RS232 sind ja fest miteinander verbunden. Mhh.. bisher hatt eich nur den CPU/Speicher Verlauf meines eigenen Programs im Blick, vielleicht sollte ich auch mal einen Blick auf den Brickd werfen. Zitieren
FlyingDoc Geschrieben March 4, 2016 at 09:30 Geschrieben March 4, 2016 at 09:30 Heute wieder festgestellt das die RS232 nur Müll sendet. Der RED lief ohne Neustart ein paar Tage. Programmneustart hat nichts gebracht. Erst nach dem Neustart des RED Brick konnte ich wieder über die Schnittstelle ordentlich Daten schicken. Zitieren
Doncarlos Geschrieben March 6, 2016 at 16:34 Autor Geschrieben March 6, 2016 at 16:34 Hallo, etwas schlauer bin ich jetzt auch. Ein bestellter Optokoppler bringt die Anlage sofort zum abschalten=> bringt also nichts irgendwelche Fehlspannungen oder sowas konnte ich nun auch nicht messen; die Masse ist auch durchgehend bis zum RED Brick ein bestellter USB-COM Adapter bringt auch den Laptop in die Lage ohne Probleme die Signale zu lesen. An der Stelle bin ich raus, das scheint ein elektrisches Problem zu sein.... Zitieren
photron Geschrieben March 10, 2016 at 11:08 Geschrieben March 10, 2016 at 11:08 Ich habe hier jetzt seit einer Weile einen Test laufen in dem das RS232 Bricklet alle 500ms eine Heizungsnachricht mit 19200 Baud 8N1 ohne Flowcontrol an meinen PC über ein FTDI Kabel sendet. Nach 6 bis 36 Stunden kommt die Heizungsnachricht nicht mehr korrekt an, sondern die einzelnen Zeichen sind teilweise durcheinander gewürfelt oder fehlen. Es kann auch sein, dass nur noch nicht-ASCII Zeichen mit Werten über 127 ankommen. Wir haben das jetzt soweit durchverfolgt, dass wir sicher sind, dass die Daten beim RS232 Chip auf dem Bricklet noch richtig ankommen, sie aber auf der RS232 Seite des Chip nicht wieder richtig herauskommen. Sprich irgendetwas veranlasst den Chip nicht richtig zu funktionieren. Eine weitere Feststellung ist, dass ein Reset des Bricks das Problem behebt. Ein bloßes Neusetzen der Konfiguration hat keinen Effekt. Es ist auch kein Problem mit der Baudrate. Wir müssen das noch weiter Debuggen, da es aber teilweise 36 Stunden dauert das Problem zu erzeugen wird sich das leider noch etwas hinziehen. Komisch ist dabei, das wir in unseren Tests während der Entwicklung des Bricklets dieses Problem nicht hatten. Wir haben dort allerdings auch ständig Daten in beide Richtungen gesendet. In euren beiden Fällen ist das Bricklet jedoch entweder nur Empfänger oder nur Sender. Möglicherweise hat das etwas mit dem Problem zu tun. vielleicht aber auch nicht, dass ist noch zu testen. Zitieren
FlyingDoc Geschrieben March 10, 2016 at 11:52 Geschrieben March 10, 2016 at 11:52 Das sind ja mal gute Neuigkeiten. Wie setzt ihr den Brick zurück? Zitieren
photron Geschrieben March 10, 2016 at 14:57 Geschrieben March 10, 2016 at 14:57 Den Master Brick resetten wir per Reste Knopf am Brick, oder Reset Knopf im Brick Viewer. Während des Resets passieren eine Reihe von Dinge. Wir versuchen gerade herauszubekommen was genau das Problem wieder beseitigt. Wie gesagt, dauert das leider recht lange. FlyingDoc, du könntest in deinem Aufbau testen, ob es hilft, wenn der PC periodisch irgendwelche Daten an den RED Brick sendet über RS232, damit nicht nur der RED Brick durchgehend sendet. Sprich ob das Problem wirklich damit zusammenhängt, dass dauerhaft nur in eine Richtung Daten gesendet werden. Zitieren
FlyingDoc Geschrieben March 11, 2016 at 07:25 Geschrieben March 11, 2016 at 07:25 Da müsste ich erst schnell ein Progrämchen schreiben. Aber das Programm das auf dem Rechner läuft und gesteuert wird, Antwortet auf die Steuerbefehle wenn diese richtig sind. Die Kommunikation ist also in beide Richtungen. Und da wo es im Einsatz ist, wird es 24h am Tag benutzt. Zitieren
Doncarlos Geschrieben March 13, 2016 at 09:29 Autor Geschrieben March 13, 2016 at 09:29 Hi, also ich hab nun hier einen Raspi3 vor mir liegen und hatte bis gerade eben noch ein ähnliches Problem. Allerdings war dort schon nach 2-3 Sekunden nur noch Blödsinn gekommen. Nach etwas Suchen hat sich beim neuen Raspi wohl etwas mit einem internen Taktgeber geändert. Ich hab das so verstanden, dass wenn der aus dem gleichgewicht kommt, eben die Nachricht auch dahin ist. Zitieren
FlyingDoc Geschrieben March 29, 2016 at 18:24 Geschrieben March 29, 2016 at 18:24 Hallo photron, gibt es inzwischen neue Erkentnisse beim RS232 Fehlverhalten? Im Moment setze ich den Master zurück wenn mein Programm feststellt das die Kommunikation nur noch Müll zustande bringt. Zitieren
photron Geschrieben March 30, 2016 at 07:47 Geschrieben March 30, 2016 at 07:47 FlyingDoc, leider noch nicht. Tests laufen noch. Zitieren
fritz-net Geschrieben July 14, 2016 at 17:51 Geschrieben July 14, 2016 at 17:51 Ich habe ein ähnliches Verhalten beim Senden. Aus AA 01 02 00 DE B1 wird manchmal AA 01 xx 00 xx B1 oder auch EA C1 80 F1 Baudrate ist auch bei mir relativ genau 57628 anstelle von 57600 ich verwende keine flow controll Bei mir ist das Verhalten ab dem zweiten mal verbinden zum bricklet und senden (2x) beim brick viewer selbst konnte ich das so noch nicht reproduzieren aber sobald der fehler da ist betrifft er auch den brickviewer Ich versuche noch herauszufinden wie sich das mit dem verbinden und trennen aus meinem Programm auswirkt. Dann könnte man das Problem wesentlich schneller lösen nach einem reset passt wieder alles für 1 mal. Zum empfangen verwende ich einen loopback adapter (mit einem logger dazwischen). Die empfangenen Daten entsprechen den gesendeten (die falsch sind) Zitieren
Doncarlos Geschrieben August 22, 2016 at 19:15 Autor Geschrieben August 22, 2016 at 19:15 ein halbes Jahr und kein Fortschritt ? RLY? Zitieren
borg Geschrieben August 23, 2016 at 13:21 Geschrieben August 23, 2016 at 13:21 Wir können das Problem hier leider nur alle paar Wochen reproduzieren und haben noch keine Lösung gefunden. Aktuell haben wir auch keine Ideen woran es liegen könnte . Zitieren
photron Geschrieben September 5, 2016 at 15:44 Geschrieben September 5, 2016 at 15:44 Alle paar Wochen ist vielleicht etwas übertrieben, aber durchaus mehrere Tage. Das RS232 Bricklet ist potentiell vom Plugin Ladeproblem betroffen, das in den aktuellen Brick Firmwares behoben wurde. Ich hatte das Bricklet an einem Master Brick mit Firmware 2.4.1 jetzt eine ganze Woche ohne Problem laufen. Das Problem könnte also behoben sein. Bitte testet eure Aufbauen mit der jeweils aktuellen Brick Firmware noch mal. Sorry, dass das hier so schleppend voran geht Zitieren
Doncarlos Geschrieben January 8, 2017 at 13:40 Autor Geschrieben January 8, 2017 at 13:40 Hallo, um was gehts bei diesem Plugin Ladeproblem ? Zitieren
borg Geschrieben January 9, 2017 at 09:07 Geschrieben January 9, 2017 at 09:07 um was gehts bei diesem Plugin Ladeproblem ? http://www.tinkerunity.org/forum/index.php/topic,673.msg22745.html#msg22745 Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.