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
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.
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?
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:> 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.
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...
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.
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.
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.
