Hallo Zusammen, Ich baue gerade eine Steuerung mehrerer Ventilinseln mittels RS485. Hauptsteuereinheit ist ein RPi, der mit 10-20 Atmega slaves kommuniziert, welche dann die 12V Ventile entsprechend schalten. Max. Kabellänge sind dabei insgesamt ~20m also sehr überschaubar. Das funktioniert an sich auch schon ganz gut. Nun habe ich zwei fast baugleiche Setups hier und bei einem von beiden kommt es jetzt immer häufiger vor, dass die Kommunikation nur mit den ersten zwei Slaves funktioniert und die dahinterliegenden nicht mehr erreicht werden. Das zweite Setup funktioniert weiterhin einwandfrei, obwohl die Topologie nahezu identisch ist. Der Fehler tritt sowohl mit verdrillten als auch nicht verdrillten Kabeln auf. Im Anhang ist ein grober Schaltplan vom Setup. Für Tipps wie ich die Kommunikation stabilisieren könnte wäre ich euch sehr dankbar. Für die Bias Widerstände (braun im Bild) hab ich testweise schon verschiedene Größen eingesetzt, die 510R scheinen da für mein Setup ideal. Es scheint auch keinen Unterschied zu machen, ob der Bus einfach oder doppelt terminiert ist (rot im Bild, nur am letzten Slave natürlich). Würde eine galvanische Trennung der Signale helfen oder ist das overkill und das Problem woanders? Danke und LG
Angehängte Dateien:
Felix schrieb: > Für die Bias Widerstände (braun im Bild) hab ich testweise schon > verschiedene Größen eingesetzt, die 510R scheinen da für mein Setup > ideal. Es scheint auch keinen Unterschied zu machen, ob der Bus einfach > oder doppelt terminiert ist Bei 20m muss man beidseitig terminieren. Am BUS, NICHT an den Teilnehmern! > (rot im Bild, nur am letzten Slave > natürlich). > Würde eine galvanische Trennung der Signale helfen Nein. >oder ist das overkill Ja. > und das Problem woanders? Ja. Im einfachsten Fall ein Wackelkontakt. Es kann aber auch an der fehlenden/falschen Terminierung liegen, siehe Wellenwiderstand.
:
Bearbeitet durch User
Felix schrieb: > und das Problem woanders? Hast du mal einfach mit einem Oszi an den Bauteilen gemessen, wie das Signal überhaupt aussieht? Passt das zu dem, was die Bauteile laut Datenblatt erwarten und brauchen?
:
Bearbeitet durch Moderator
Falk B. schrieb: > Bei 20m muss man beidseitig terminieren. Am BUS, NICHT an den > Teilnehmern! Nur um ganz sicherzugehen. "Am Bus" meint zw. den Leitungen A und B!? D.h. so wie in der Skizze wär's richtig? (also die roten 120R nur einmal am letzten Slave natürlich)
Felix schrieb: > so wie in der Skizze wär's richtig? Nein, in der Skizze hast du an den Bus-Teilnehmern terminiert. Der Bus sind die horizontalen Leitungen darüber. Diese gehören ganz links und ganz rechts (an ihren Enden) terminiert. So: https://www.janitza.de/files/topics/wissen/Wissensdatenbank-Technischer-Anhang-Bilder/RS485-Schnittstelle-12.png https://servicecenter.linemetrics.com/wp-content/uploads/2017/01/Modbus_anleitung_oH_mB_new.jpg
Felix schrieb: > Nun habe ich zwei fast > baugleiche Setups hier und bei einem von beiden kommt es jetzt immer > häufiger vor, dass die Kommunikation nur mit den ersten zwei Slaves > funktioniert und die dahinterliegenden nicht mehr erreicht werden. Definiere "nicht erreicht". Wie stellst du fest, dass du Fehler hast? Was passiert, wenn du mal die ersten beiden Geräte der beiden Setups gegeneinander austauschst?
Peter D. schrieb: > Welche Baudrate, welcher Quarz am AVR? Baudrate aktuell 9600. Reicht für meine Anwendung völlig aus. Die Slaves sind Atmega328P mit "Standardquarz" 16MHz (IQD LFXTAL003240).
Über die GND leitung darf bei der leitungslänge nur wenig strom fließen, damit die signale innerhalb der commom mode range der transceiver bleiben. wie viel strom wird auf den 12V verwendet?
Lothar M. schrieb: > Definiere "nicht erreicht". Wie stellst du fest, dass du Fehler hast? > > Was passiert, wenn du mal die ersten beiden Geräte der beiden Setups > gegeneinander austauschst? Mit "Nicht erreicht" meine ich, dass bei Nachrichten teilweise Start-Bytes fehlen oder die gar nicht korrekt gelesen werden können. Woraufhin die Verarbeitung natürlich nicht funktioniert. Habe bereits die potentiell defekten Teile getauscht und auch komplett ausgetauscht, scheint also in der Tat irgendein struktureller Fehler zu sein.
Wenn du mit 20 mal 120 ohm belastest sind das 6 ohm über der leitung. Klar läuft das nicht. Lies dem stefan sein post und mach das so.
Felix schrieb: > die dahinterliegenden nicht mehr erreicht werden. Dann mußt Du wohl debuggen. D.h. empfangen sie nicht, senden sie nicht, treten Fehler auf usw. Z.B. ein kleines Text-LCD anschließen oder mit ein paar LEDs.
flip schrieb: > Über die GND leitung darf bei der leitungslänge nur wenig strom fließen, > damit die signale innerhalb der commom mode range der transceiver > bleiben. VCM darf -7..+12V betragen, da muß also schon sehr viel Strom über GND fließen.
Felix schrieb: > scheint also in der Tat irgendein struktureller Fehler zu sein. Frag mal irgendwen, ob er dir ein Oszi leihen kann. Denn das, was du grade versuchst, ist wie anhand von feuchten Flecken auf einem Parkplatz auf den Defekt eines Autos zu schließen... Offenbar hast du nämlich mit deinem Bus und dem Herumprobieren nicht so viel Glück wie andere und musst doch noch messen. Dazu mein Kommentar im zweiten Abschnitt des Beitrag "Re: WS2812b flackern / 3600 LED Matrix" Oder andersrum: egal, ob so ein Bus auf Anhieb tut oder auch nicht tut, ich messe schon beim ersten versendeten Byte, ob die Pegel passen. Und wenn der Bus nicht tut, dann wird sofort auf dem Bus gemessen. Wie soll man sonst feststellen, ob was nicht geht? Geschickterweise kann man da z.B. Buskollisionen ganz einfach erkennen (wenn einer der Slaves den Bus nicht korrekt freigibt oder aber die Treiber zu spät einschaltet). Und man kann auch gleich mal die Baudrate kontrollieren...
:
Bearbeitet durch Moderator
Pepe T. schrieb: > Wenn du mit 20 mal 120 ohm belastest sind das 6 ohm über der leitung. > Klar läuft das nicht. Lies dem stefan sein post und mach das so. Bist Du der rechte Pepe aus der Schweiz, der massive Probleme mit der Rechtschreibung hat? Nebenbei: Bei 6 Ohm funktioniert der Bus nicht. Da der TO schrieb: "Das funktioniert an sich auch schon ganz gut.", folgt daraus: Elektrotechnik ist ebenfalls nicht Dein Ding.
Bei diesem "Schaltplan" (nicht Schaltplan) der mir sehr hemds- ärmelig vorkommt darf man schon mal nach Abblock-Kondensatoren fragen. Diese sind ja bei hemdsärmeligen Aufbauten und Makern durchaus unbeliebt oder auch unbekannt. Im schlimmsten Fall sogar als unnötig eingestuft. Ob das eine oder andere hier zutrifft wage ich nicht zu be- urteilen, wage aber das Thema in den Raum zu werfen ..... Auch der Aufbau innerhalb der einzelnen RS485-Zelle sollte ein Thema sein, abgesehen vom gesamten "Schaltplan" (nicht Schaltplan), der mehr Spekulation als Erkenntnis mit sich bringt.
Felix schrieb: > dass die Kommunikation nur mit den ersten zwei Slaves > funktioniert Dann einfach mal in diese beiden eine Firmware brennen, die DE permanent diasbled. Wenn dann die dahinter liegenden wieder funktionieren, ist die HW in Ordnung und es ist ein SW-Problem.
Lothar M. schrieb: > Frag mal irgendwen, ob er dir ein Oszi leihen kann. Werde mich mal umhören. Ist bestimmt interessant, bevor ich hier weitere Verrenkungen mit Kabeltypen, Leiterlängen, Optokopplern mache. uff basse schrieb: > Bei diesem "Schaltplan" (nicht Schaltplan) der mir sehr hemds- > ärmelig vorkommt darf man schon mal nach Abblock-Kondensatoren > fragen. Am DCDC Wandler und am IC selbst sind welche verbaut je nach Datenblatt d. Bauteils. Am MAX85 nicht nochmal separat, da recherchiere ich nochmal. Peter D. schrieb: > Dann einfach mal in diese beiden eine Firmware brennen, die DE permanent > diasbled. Wenn dann die dahinter liegenden wieder funktionieren, ist die > HW in Ordnung und es ist ein SW-Problem. Gute Idee, werde ich mal versuchen. Mich wundert halt, dass es bei manchen funktioniert und bei manchen eben nicht, ist ja überall die gleiche Hard- und Software.... Softwareseitig fehlende Startbytes zu kompensieren erscheint mir irgendwie nicht die feine englische Art.
Dass du die gesamtanzahl an 120ohm R auf ZWEI reduzieren musst hast du begriffen?
Pepe T. schrieb: > Dass du die gesamtanzahl an 120ohm R auf ZWEI reduzieren musst hast du > begriffen? Lies doch wenigstens mal den Thread, vor du noch zigmal diesen alten Gummi durchkaust. Denn Felix schrieb: >>>> also die roten 120R nur einmal am letzten Slave natürlich
Lothar M. schrieb: > Pepe T. schrieb: >> Dass du die gesamtanzahl an 120ohm R auf ZWEI reduzieren musst hast du >> begriffen? > Lies doch wenigstens mal den Thread, vor du noch zigmal diesen alten > Gummi durchkaust. Denn passiert halt, wenn die Skizze das Problem nicht treffend beschreibt
Hallo Zusammen. Hab den Fehlerteufel gefunden. Nach vielem Hin und Her montieren. An den Atmegas ist jeweils noch ein Analogsensor angeschlossen. Da bin ich davon ausgegangen, dass der nix mit der Kommunikation zu tun hat, daher hab ich ihn auch gar nicht eingezeichnet (Sorry). Jedenfalls scheint der defekt zu sein, da nach einem Austausch das gesamte Ding wieder funktioniert. Sensor, Atmega und MAX485 hängen am selben DCDC-Converter. Kann ich das irgendwie besser abkapseln, um sowas zukünftig zu vermeiden? Danke für eure Ratschläge! Solch fachlich versierte zweit-, dritt- viert- Meinungen sind beim Entwickeln Gold wert!
Felix schrieb: > Sensor, Atmega und MAX485 hängen am selben DCDC-Converter. Kann ich das > irgendwie besser abkapseln, um sowas zukünftig zu vermeiden? Da mußt Du schon Informationen zu dem unbekannten Sensor mit unbekanntem Anschluß an den AVR rausrücken.
Angehängte Dateien:
Es ist ein Feuchtigkeitssensor (Schaltplan laut DB siehe Anhang). Dessen AOut ist mit einem 1MOhm Pulldown (definierter Status falls n.c., verfälscht Sensorwert nur minimal) direkt am Analog IN vom Atmega.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.