Hallo Zusammen, ich möchte meine Heimautomation vernetzen. Bisher greife ich mit dem PC die Daten von nur einem Teilneher ab. Das geht auch sehr gut. Nun habe ich mein Protokoll erweitert. Mit einem Teilnehmer geht das auch. Sobald ich aber ein Netzwerk mit zwei Teilnehmern habe, hängt sich immer der Teilnehmer auf, der nicht angesorochen wird. Woran kann das liegen? Ich habe inzwischen die Vermutung dass der Bus irgendo nicht sauber schaltet. Vielleicht kennt sich jemand mit dem RS-485 und mehreren Teilnehern besser aus. Die Terminierung 120 Ohm ist am Anfang und am Ende des Busses. Die Pullups für VCC und GND sind an jedem Teilnehmer dran 680 Ohm. Eingesetzt wird der MAX3485 da ich nur mit 3,3 Volt und dem PIC18F97J60 arbeite. Ein Auszugder Hadware von der Schnittselle liegt bei. Die Umschaltung von Sende- und Empfangsbetrieb läuft automatisch. PC -> Slave Adr. 1 -> Slave Adr. 2 Grüße und Danke Ingo Kurz zum Aufbau: SP_COM.Write(Chr(&H53)) // 'S' Controller wird aufgeweckt System.Threading.Thread.Sleep(100) SP_COM.Write(Chr(STX)) '0 Startzeichen SP_COM.Write(Chr(cbo_Ziel.Text)) '1 Ziel SP_COM.Write(Chr(cbo_Quelle.Text)) '2 Quelle SP_COM.Write(Chr(cbo_Art.Text)) '3 ART SP_COM.Write(Chr(cbo_Par_1.Text)) '4 PAR1 SP_COM.Write(Chr(cbo_Par_2.Text)) '5 PAR2 SP_COM.Write(Chr(cbo_Par_3.Text)) '6 PAR3 SP_COM.Write(Chr(cbo_Par_4.Text)) '7 R/W SP_COM.Write(Chr(ETX)) '8 SP_COM.Write("\0")
Angehängte Dateien:
-
RS-485.png
4,4 KB -
RS-485.png
5,4 KB
:
Bearbeitet durch User
Ingo S. schrieb: > ich mein Protokoll erweitert. Mit einem Teilnehmer geht das auch. Sobald > ich aber ein Netzwerk mit zwei Teilnehmern habe, hängt sich immer der > Teilnehmer auf, der nicht angesorochen wird. Woran kann das liegen? Als erstes fehlt bei dir die Länge des Pakets und das ist unbedingt notwendig, ansonsten kann es passieren (wie bei dir) dass sich der Empfänger aufhängt !! Hier ist etwas, das bei mir in einem Netz mit 11 Teilnehmern ohne irgendwelche Probleme funktioniert: a) RxdPointer = 0, empfangenes Zeichen prüfen, wenn (Zeichen <> STX), wieder mit a) anfangen. b) nächstes Zeichen empfangen, wenn (Zeichen <> eigene Adresse), wieder mit a) anfangen. c) nächstes Zeichen empfangen, wenn (Zeichen <> Adresse des Masters), wieder mit a) anfangen. d) nächstes Zeichen empfangen, wenn (Zeichen > MaxMsgLen), wieder mit a) anfangen, ansonsten RxdPointer = empfangenes Zeichen. f) nächstes Zeichen empfangen, decr RxDPointer. g) Wenn (RxdPointer == 0) und (empfangenes Zeichen <> ETX), weiter mit a). ( Empfang in der Interrupt-Routine, Master kann alle Slaven ansprechen, Slaven können nur antworten).
Marc V. schrieb: > Als erstes fehlt bei dir die Länge des Pakets und das ist unbedingt > notwendig, ansonsten kann es passieren (wie bei dir) dass sich der > Empfänger aufhängt !! Nicht wenn das Protokoll eindeutige Trennzeichen definiert. Was hier der Fall zu sein scheint. Mit STX weiss jeder Slave, dass es neu losgeht, ob er ein ETX gesehen hat oder nicht. Unabhängig davon wäre aber eine CRC ratsam.
Der GND des Busses muss durchgezogen werden. Ohne 120 Ohm. Die muessen weg. Die Richtung muss per Protokoll umgeschalten werden, nicht automatisch. Miss doch mal mit einem Oszilloskop nach, welche Signale wo vorhanden sind.
торфкопф schrieb: > Der GND des Busses muss durchgezogen werden. Ohne 120 Ohm. Oh, Gott, RS485-Ground-Diskussion die 432616te in 3 - 2 - 1 ...
Ingo S. schrieb: > hängt sich immer der > Teilnehmer auf, der nicht angesorochen wird. wie äußert sich das genau? Antwortet er danach nicht mehr auf RS485-Kommunikation? Führt er seine Main-Loop nicht mehr aus? Spricht ein Hardware-Watchdog an? Geht er in einen Hardfault-IRQ (keine Ahnung ob PICs sowas haben)? Kommt Rauch aus dem Controller? ... Vielleicht mal mit dem Debugger, printf-Debugging, LED-Blinken, ... rausfinden, was das Ding tatsächlich treibt wenn es sich "aufhängt".
hab inzwischen mit dem Ozi gemessen. Muss was mit dem Protokoll zu tun haben. Die Teilneher laufen weiter. Doe Uhrzeit von der RTC auf den Teilnehmern läuft weiter. Werde wohl ne Checksumme usw. einbauen müssen. Der erste Teilnehmer schaltet definitiv nicht zurück. Danke für die Ideen. Ingo
Ich würde zusätzlich auch einen Timeout beim Empfang einbauen, wenn das Ende-Zeichen aus irgendeinem Grund nicht x Millisekunden nach dem Beginn des Paketes empfangen wurde hört er auf darauf zu warten und wartet stattdessen wieder auf das Startzeichen.
A. K. schrieb: > Nicht wenn das Protokoll eindeutige Trennzeichen definiert. Was hier der > Fall zu sein scheint. Mit STX weiss jeder Slave, dass es neu losgeht, ob > er ein ETX gesehen hat oder nicht. Ja, viele haben so gedacht und sind immer noch beim Fehlersuchen... In einem solchen Fall können binäre Daten nicht gesendet werden, da der STX im Paket vorkommen kann. > Unabhängig davon wäre aber eine CRC ratsam. CRC ist ratsam, kommt aber erst zum Schluss, LÄNGE ist viel, viel wichtiger, vor allem beim CAN oder RS485, wo mehrere Teilnehmer am Bus sind !!! Bernd K. schrieb: > Ich würde zusätzlich auch einen Timeout beim Empfang einbauen, wenn das > Ende-Zeichen aus irgendeinem Grund nicht x Millisekunden nach dem Beginn > des Paketes empfangen wurde hört er auf darauf zu warten und wartet > stattdessen wieder auf das Startzeichen. Ja, das kann auch als zusätzliche Handbremse eingebaut werden.
:
Bearbeitet durch User
Marc V. schrieb: > Ja, viele haben so gedacht und sind immer noch beim Fehlersuchen... > In einem solchen Fall können binäre Daten nicht gesendet werden, da > der STX im Paket vorkommen kann. Korrekt. Binärdaten sind in reinen Steuerungsprotokollen aber oft verzichtbar. Und mit Escape-Methoden wie in asynchronem PPP oder dem älteren SLIP gehen auch die. Auch ohne explizit übertragene Länge. Bei Steuerungsprotokollen haben in ASCII codierte Daten zudem den Vorteil, ohne speziellem Dekoder lesbar zu sein. Recht praktisch beim Debugging. Ich habe freilich nicht tiefer analysiert, ob das Protokoll hier frei von STX/ETX im Body der Message ist.
:
Bearbeitet durch User
A. K. schrieb: > Korrekt. Binärdaten sind in reinen Steuerungsprotokollen aber oft > verzichtbar. Und mit Escape-Methoden wie in asynchronem PPP oder dem > älteren SLIP gehen auch die. Auch ohne explizit übertragene Länge. Auch korrekt, aber ich stehe auf dem Standpunkt: So schnell und einfach wie möglich, so sicher wie möglich. > Bei Steuerungsprotokollen haben in ASCII codierte Daten zudem den > Vorteil, ohne speziellem Dekoder lesbar zu sein. Recht praktisch beim > Debugging. Ich habe dafür einen CAN/RS485-Sniffer und ein kleines (aber wirklich kleines) Programm fur PC, da sieht man gleich, ob alles richtig ist - Adressen, Befehle, Timing...
So, Nun läuft die Anwendung. Mit einer optimierten Abfrage des USART und einer Checksumme hat alles funktioniert. Das Problem ist also gelöst! Danke nochmals Ingo
Ingo S. schrieb: > So, Nun läuft die Anwendung. Mit einer optimierten Abfrage des USART und > einer Checksumme hat alles funktioniert. Das Problem ist also gelöst! in 5:03h. Respekt! Ich melde hiermit Zweifel an. wendelsberg
Ingo S. schrieb: > So, Nun läuft die Anwendung. Mit einer optimierten Abfrage des USART und > einer Checksumme hat alles funktioniert. Das Problem ist also gelöst! Ja, es lag bestimmt am falschen Checksum. Langsam verliere ich die Lust zu helfen...
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.