Grüsst euch :-) Ich hab mal ein paar Fragen an die Modbus-Gemeinde. Am besten fange ich mal mit der Ausgangssituation an: Ein Kunde von mir hat ein Labor, in welchem gerade irgendwelche Laborgeräte mit Ventilationsanschluss installiert werden. Die Dinger stellen entweder ein 0-10V oder ein on/off-Signal bereit, welches ausgelesen und der entsprechende Frequenzumrichter des jeweiligen Dachventilators angesteuert werden soll. Dummerweise hat der Elektriker aber nur ein Kabel (2x2x0.8) pro Raum gezogen, so dass ich die Signale nicht einzeln in den Technikraum bekomme. Deshalb war meine Idee die Signale jeweils vor Ort mit einem uC auszulesen und die jeweiligen Zustände per Modbus übers Kabel zu schicken. Damit wäre das System auch ausbaufähiger, denn es kommen in Zukunft wahrscheinlich noch weitere Geräte dazu. Nun das Problem: Es ist im Prinzip eine Sterntopologie, da es 13 Räume gibt, zu denen jeweils eine Leitung aus dem Technikraum verläuft. Geschätzte Kabellänge dürfte bei 20-30m pro Kabel liegen. Ich habe bisher drei Möglichkeiten in Betracht gezogen, wobei ich nicht weiss, welche die bessere wäre, da ich Sterntopologie noch nie gemacht habe (so was macht man ja i.d.R. auch nicht). 1. Ich verbinde die USART des uC's mit 13 RS-485-Transceivern und aktiviere jeweils über DE/RE nur den Kanal, den ich abfragen möchte. Die Kommunikation soll eh über reines Master-Polling realisiert werden, entsprechend wäre das kein Problem, da die Slaves ohne Aufforderung keine Kommunikation zum Master aufbauen werden. 2. Ein paar 74HC4052 benutzen, entweder USART-seitig oder Modbus-seitig. Den müsste ich allerdings zweistufig aufbauen, um auf die entsprechende Kanalanzahl zu kommen. Hätte den Vorteil, dass das System masterseitig noch erheblich mehr Reservekanäle bekommen würde. 3. Im Netz hab ich den hier gefunden: https://www.tme.eu/Document/5b9a45dc09afb261dd63a93581ede578/ISL3152EIUZ.pdf Der eignet sich angeblich für eine Sterntopologie in rauer Umgebung, allerdings ist er auf 8 Kanäle begrenzt. Hier wäre also auch ein MUX oder eine Lösung wie in Nr.1 nötig. Was meint ihr dazu/was wäre hier eine solide Lösung, um die Mehrkanal-Fähigkeit zu erreichen? Mir geht's nicht um Bauteile-Sparen, wenn 13 RS-485-Chips die bessere Lösung sind, dann kommen die da rein. Das ist ein Custom-Projekt, entsprechend kommt's auf 100-200,- nicht an. Noch kurz zu den technischen Bedingungen: Baudrate kann winzig sein (600-2400), da die Abfrage 1x/sek stattfindet und jeweils nur 30Bits + CRC übertragen werden, also fast nichts. Die Kabel haben einen Folienschirm, sind aber wahrscheinlich nicht verdrillt. Es ist davon auszugehen, dass die Kabel zusammen mit den Versorgungsleitungen im Kabelkanal liegen, entsprechend sollte sicherheitshalber mit Störpotenzial gerechnet werden.
:
Bearbeitet durch User
Uwe H. schrieb: > Ein paar 74HC4052 benutzen Würde ich nicht machen, die sind eigentlich zu hochohmig, und Relaiskontakte sind keine elegante Lösung. Im Interesse der Ausbaufähigkeit würde ich modulare Platinen mit einigen RS485-Transceivern entwerfen und für ausreichend Ansteuersignale für die Zukunft sorgen - z.B. für 32 Leitungen 5 Auswahlsignale und auf den Platinen Mäuseklaviere zur Konfiguration. Georg
Uwe H. schrieb: > Grüsst euch :-) Servus! > 1. Ich verbinde die USART des uC's mit 13 RS-485-Transceivern > 2. Ein paar 74HC4052 benutzen, entweder USART-seitig oder Modbus-seitig. Modbus-seitig geht garnicht. Damit verschenkst du die ganzen guten Eigenschaften des RS-485-Transceivers. UART-seitig kommt es fast auf dasselbe raus wie Variante 1) wo 26 Steuersignale gebraucht werden. Deshalb wirst du bei 1) auch Multiplexer einbauen wollen (o.k., 26 I/O-Pins sind auch nicht soo viel). > 3. ISL3152E > Der eignet sich angeblich für eine Sterntopologie in rauer Umgebung, > allerdings ist er auf 8 Kanäle begrenzt. Interessante Idee, aber in deinem speziellen Fall unnötig. 2400 Baud über 30 Meter gehen mit einem langsamen (115kBaud) Transceiver auch ohne Abschlußwiderstände. Aber ich würde auf jeden Fall die 13 getrennten Transceiver spendieren, alleine um Fehler besser eingrenzen zu können. Die Variante 1) ist mir sympatischer, ein DE-Signal musst du auf jeden Fall erzeugen und das wird nur verteilt. Bei 2) kommt eine andere Logik dazu, auch vom Ablauf her. > Die Kabel haben einen Folienschirm, sind aber wahrscheinlich nicht > verdrillt. > Dummerweise hat der Elektriker aber nur ein Kabel (2x2x0.8) 2x2 steht normalerweise für paarweise verdrillt? > Es ist davon auszugehen, dass die Kabel zusammen mit den > Versorgungsleitungen im Kabelkanal liegen, entsprechend sollte > sicherheitshalber mit Störpotenzial gerechnet werden. Das könnte das größere Problem sein wenn genau nach Vorschrift gebaut wird. Normal müsste das Datenkabel wie ein 230V-Kabel isoliert sein oder der Kanal müsste eine Trennwand haben.
Also UART parallel auf 13+ Transceiver verteilen und über DE/RE den jeweiligen aktiven Kanal freigeben? Hat das schon mal jemand getestet, also mehrere Transceiver an einer UART? :-D Theoretisch spricht für mich erstmal nichts dagegen, aber ich frag besser mal nach. Denn oft kommen hier im Forum Hinweise auf etwas, woran man selbst nicht gedacht hat. Ich steh auch etwas mit dem ganzen unter Zeitdruck, da man selbstverständlich vorher erst 30 sinnlose Treffen und kilometerlangen Mailverkehr abhalten musste, bevor man endlich zu einer Entscheidung kam und man mit der Umsetzung beginnen konnte. Jetzt ist natürlich Zeitdruck ohne Ende, weil der Mist in 2-3 Wochen laufen muss. Deshalb will ich lieber dreimal nachfragen, denn eine neue Hauptplatine krieg ich im Falle von Störungen nicht mehr neu projektiert, ohne den Termin zu sprengen
:
Bearbeitet durch User
Bauform B. schrieb: > Das könnte das größere Problem sein wenn genau nach Vorschrift gebaut > wird. Normal müsste das Datenkabel wie ein 230V-Kabel isoliert sein oder > der Kanal müsste eine Trennwand haben. Wenn ich die Kabel selbst verlegt hätte, wäre es so gewesen. Hier haben aber irgendwelche Azubis die Kabel verlegt, die null Ahnung haben. Jetzt ist es zu spät, um noch irgendwas zu ändern, denn die Kabelschächte sind bereits dicht.
Bauform B. schrieb: > Die Variante 1) ist mir sympatischer, ein DE-Signal musst du auf jeden > Fall erzeugen und das wird nur verteilt. Bei 2) kommt eine andere Logik > dazu, auch vom Ablauf her. Mir ist Variante 1. auch am liebsten. Nur: Ich hab natürlich im Netz nach einer Lösung gesucht und festgestellt, dass überall MUXe als Splitter benutzt werden, um die UART mehrkanalfähig zu bekommen. Da stellt sich doch die Frage "Warum", wenn man theoretisch die UART einfach direkt auf die Transceiver aufsplitten könnte
Uwe H. schrieb: > 1. Ich verbinde die USART des uC's mit 13 RS-485-Transceivern und > aktiviere jeweils über DE/RE nur den Kanal Wenn immer nur ein Teilnehmer antwortet - und so sollte das bei einem RS-485 Bus ja eigentlich sein - könnte man auch immer alle Transeiver gleichzeitig aktivieren. Nur die RX der Transceiver muss man dann gegeneinander entkoppeln, damit sie nicht gegeneinander treiben. Entweder mit Dioden und Pullup oder mit UND-Gatter(n). Das verhält sich dann genau so wie ein Bus mit allen Teilnehmern.
:
Bearbeitet durch User
Olly T. schrieb: > Nur die RX der Transceiver muss man dann > gegeneinander entkoppeln, damit sie nicht gegeneinander treiben. > Entweder mit Dioden und Pullup oder mit UND-Gatter(n). Hilf mir bitte auf die Sprünge, denn davon hab ich keine Ahnung. Wenn ich "RE" bei den Tranceivern in Richtung der Standby-Slaves abschalte und nur jeweils den aktiven Kanal "enable" und höre, dürfte doch eigentlich selbst ohne zusätzliche Bauteile kein Problem auftauchen, da jeweils nur eine Magistrale zur UART durchkommt...? Oder hab ich hier einen Denkfehler?
:
Bearbeitet durch User
Ja, RE schaltet den Receiverausgang bei den Bausteinen die ich kenne hochohmig. Ein Pullup sorgt dann für zuverlässigen Ruhepegel. Was du dir noch anschauen solltest sind die Eingangsströme der 13 Transmitter und ob die von deinem Controller Ausgangsseitig parallel getrieben werden können. Sascha
Uwe H. schrieb: > Dummerweise hat der Elektriker > aber nur ein Kabel (2x2x0.8) pro Raum gezogen, so dass ich die Signale > nicht einzeln in den Technikraum bekomme. Damit kannst Du immerhin die Frickelvariante von RS485 (ohne GND-Leitung) hinbekommen, indem Du jeweils ein Paar für den Hinweg und eines für den Rückweg nimmst. Aber liegen in diesem neuen Raum keinerlei Netzwerkkabel? Uwe H. schrieb: > 1. Ich verbinde die USART des uC's mit 13 RS-485-Transceivern Du brauchst sogar nur 7 Transceiver, weil Du mit jeweils 2 Räumen einen sauberen Bus hinbekommst, der Master darf schliesslich auch in der Mitte sitzen.
Hmmm schrieb: > Damit kannst Du immerhin die Frickelvariante von RS485 (ohne > GND-Leitung) hinbekommen, indem Du jeweils ein Paar für den Hinweg und > eines für den Rückweg nimmst. Ich geh halbduplex ich nutze das zweite Paar eventuell für die Versorgungsspannung (9-12V), denn sonst kommen nochmal 13 Netzteile hinzu für ein paar mA Strombedarf plus höhere Sicherheits-Anforderungen an die PCB's. Damit wäre auch der gemeinsame GND vorhanden. > Aber liegen in diesem neuen Raum keinerlei Netzwerkkabel? Liegen, aber die sind alle reserviert. > Du brauchst sogar nur 7 Transceiver, weil Du mit jeweils 2 Räumen einen > sauberen Bus hinbekommst, der Master darf schliesslich auch in der Mitte > sitzen. Ist korrekt.
Sascha W. schrieb: > Ja, RE schaltet den Receiverausgang bei den Bausteinen die ich kenne > hochohmig. Ein Pullup sorgt dann für zuverlässigen Ruhepegel. Das ist Neuland für mich, ich hab noch nie einen Pullup in einem RS485-Netzwerk gesehen oder verwendet. Was verwendet man da i.d.R.? 10K? > Was du dir noch anschauen solltest sind die Eingangsströme der 13 > Transmitter und ob die von deinem Controller Ausgangsseitig parallel > getrieben werden können. Ich würde den hier benutzen: https://datasheets.maximintegrated.com/en/ds/MAX13080E-MAX13089E.pdf Von dem hab ich noch 50 Stück aus einem früheren Projekt hier liegen, ist ein hochqualitativer Chip. Soweit ich das erkennen kann, liegt die Stromaufnahme der Treiber im unteren uA-Bereich. Kannst Du bitte kontrollhalber auch noch mal drüber schauen?
Uwe H. schrieb: > Hmmm schrieb: >> Damit kannst Du immerhin die Frickelvariante von RS485 (ohne >> GND-Leitung) hinbekommen, indem Du jeweils ein Paar für den Hinweg und >> eines für den Rückweg nimmst. > > Ich geh halbduplex Ich meinte damit nicht Fullduplex-Betrieb, sondern Bus-Hinweg und Bus-Rückweg, damit es kein Stern (mit entsprechenden Reflexionen) wird:
1 | Slave 1 Slave 2 Slave 3 |
2 | || || || || || |
3 | || || || || || |
4 | || || || || || |
5 | Master ========== ========= |
Wobei ich davon ausgehe, dass bei den angesprochenen niedrigen Baudraten auch eine sternförmige Verkabelung funktionieren würde. Evtl. mal provisorisch zusammenklemmen, im Technikraum mit einem USB-RS485-Konverter Testdaten erzeugen und dann in den Räumen mit einem Oszi angucken. Uwe H. schrieb: > Das ist Neuland für mich, ich hab noch nie einen Pullup in einem > RS485-Netzwerk gesehen oder verwendet. Aus dem Receiverausgang kommt kein RS485. Es wird gerne übersehen, dass der Ausgang beim Abschalten des Receivers hochohmig ist, was beim häufig zu sehenden Verbinden von DE und !RE störend sein kann, aber bei der Konstellation mit mehreren Receivern praktisch ist.
Hmmm schrieb: > Ich meinte damit nicht Fullduplex-Betrieb, sondern Bus-Hinweg und > Bus-Rückweg, damit es kein Stern (mit entsprechenden Reflexionen) wird: > Slave 1 Slave 2 Slave 3 > || || || || || > || || || || || > || || || || || > Master ========== ========= > > Wobei ich davon ausgehe, dass bei den angesprochenen niedrigen Baudraten > auch eine sternförmige Verkabelung funktionieren würde. Evtl. mal > provisorisch zusammenklemmen, im Technikraum mit einem > USB-RS485-Konverter Testdaten erzeugen und dann in den Räumen mit einem > Oszi angucken. Wenn ich mit jeweils separaten Transceivern für jedes Kabel arbeite, ist es doch jeweils eine 1zu1-Verbindung, ähnlich wie eine Sternkonstellation über ein Repeaternetzwerk. Reflexionen dürften da eigentlich nicht auftreten. "Provisorisch anklemmen" geht nicht, denn ich habe noch nichts zum testen. Ich entwerfe gerade erst das PCB-Design und deshalb frage ich ja auch hier nach, ob das so klappen könnte :-) > Uwe H. schrieb: >> Das ist Neuland für mich, ich hab noch nie einen Pullup in einem >> RS485-Netzwerk gesehen oder verwendet. > > Aus dem Receiverausgang kommt kein RS485. > > Es wird gerne übersehen, dass der Ausgang beim Abschalten des Receivers > hochohmig ist, was beim häufig zu sehenden Verbinden von DE und !RE > störend sein kann, aber bei der Konstellation mit mehreren Receivern > praktisch ist. Hält der Atmel nicht die RX/TX im Ruhezustand automatisch auf High? Müsste ich nochmal checken, aber soweit ich mich erinnere, war das so
Uwe H. schrieb: > Wenn ich mit jeweils separaten Transceivern für jedes Kabel arbeite Meine Idee war eine Alternative, um aus der sternförmigen Verkabelung einen Bus zu machen. Aber eben mit der Einschränkung, dass GND fehlen würde, da ist die Lösung mit mehreren Transceivern schon eleganter. Uwe H. schrieb: > "Provisorisch anklemmen" geht nicht, denn ich habe noch nichts zum > testen. Die Verkabelung ist ja schon da, da könnte man sich das Reflexionsverhalten schonmal mit Fertighardware angucken. Uwe H. schrieb: > Hält der Atmel nicht die RX/TX im Ruhezustand automatisch auf High? TXD ist bei eingeschaltetem UART in Ruhelage auf High-Pegel. RXD (wo der RS485-Receiver dranhängt) bleibt ein hochohmiger Eingang, Du solltest also mindestens den internen Pullup aktivieren, damit kein Müll empfangen wird, wenn gerade kein Receiver eingeschaltet ist. Auf den RS485-Bussen die Bias-Widerstände nicht vergessen, damit es auch dort keine undefinierten Pegel gibt.
Ich sehe in der sternförmigen auch Verkabelung kein Problem für einen RS485 "Bus". Bei unseren Steuergeräten für die Zutrittskontrolle gibt es vier Anschlussklemmen, die parallel an einen Tranceiver-Chip gehen. An diese Klemmen sind dann die einzelnen Kabel für mehrere Ausweisleser angeschlossen. Das Bild von Hmmm trifft das ganz gut. Bei deiner Leitungslänge und Datenrate sollte das also mit einem Transceiver-Chip als Master funktionieren. Hört sich nach einem schönen Projekt an. Hast du schon eine MCU im Blick? Gut wäre, wenn deren UART das DE/RE gleich mitmachen kann.
Angehängte Dateien:
-
RS485-1.png
12 KB -
RS485-2.png
5,1 KB
Uwe H. schrieb: > Wenn > ich "RE" bei den Tranceivern in Richtung der Standby-Slaves abschalte > und nur jeweils den aktiven Kanal "enable" und höre, dürfte doch > eigentlich selbst ohne zusätzliche Bauteile kein Problem auftauchen Ja, wenn Du immer nur einen Transceiver aktivierst geht das so. Meine Idee war aber, immer alle gleichzeitig zu aktivieren. Der Master sendet also immer an alle. Natürlich unter der Voraussetzung, dass sich immer nur einer angesprochen fühlt und dann antwortet, wie das ja normalerweise an einem RS-485 Bus ist. Vorteil: Du muss nicht wissen, an welchem Teil-Bus Dein angesprochener Teilnehmer hängt. Die Ausgänge der Transceiver sind dann aber auch immer gleichzeitig aktiv und müssen deswegen entkoppelt werden, damit sie nicht gegeneinander treiben (die nicht angesprochenen geben dauerhaft "high" aus). Das geht entweder mit einem (bzw. mehreren) "Und"-Gatter(n). RX ist high, wenn alle Transceiver "high" liefern und "low" sobald (mindestens) einer "low" sendet. Da immer nur einer senden darf, geht das. Das kann man auch mit Dioden und einem Pullup aufbauen. Vielleicht nicht ganz so elegant, aber einfacher erweiterbar, pro Transceiver braucht es nur eine zusätzliche Diode. Bei 1 MBit/s würde ich das nicht mehr machen, aber bei ein paar kBit/s sollte das problemlos gehen. Siehe angehängte Bilder.
Auswahl des aktiven Transceivers per DE/RE hat gegenüber dem vorigen Broadcast-Prinzip einen klaren Vorteil: Ein defekter Ast ist leicht identifizierbar und legt nur sích selbst lahm. Koppelt man alle Äste, ist mit einem defekten Ast u.U. die ganze Steuerung nachhaltig tot und zur Diagnose muss man Stecker ziehen. So nebenbei ergibt sich auch ein deutlicher Unterschied im Spitzenstrom. Ein RS485 Abschluss frisst recht viel Strom, und bei 13 gleichzeitig aktiven Ästen merkt man das.
:
Bearbeitet durch User
Olly T. schrieb: > Uwe H. schrieb: >> Wenn >> ich "RE" bei den Tranceivern in Richtung der Standby-Slaves abschalte >> und nur jeweils den aktiven Kanal "enable" und höre, dürfte doch >> eigentlich selbst ohne zusätzliche Bauteile kein Problem auftauchen > > Ja, wenn Du immer nur einen Transceiver aktivierst geht das so. > > Meine Idee war aber, immer alle gleichzeitig zu aktivieren. Der Master > sendet also immer an alle. Uwe sprach vom Abschalten von RE, d.h. gesendet wird an alle, empfangsseitig wird immer nur der Receiver aktiviert, von dessen Bus man gerade eine Antwort erwartet. So kann man die Receiver-Ausgänge einfach parallelschalten, man braucht nur einen Pullup für die Umschaltzeiten.
Uwe H. schrieb: > Von dem hab ich noch 50 Stück aus einem früheren Projekt hier liegen, > ist ein hochqualitativer Chip. Wobei ich angesichts der niedrigen gefragten Datenrate das bei einigen davon mögliche slew rate limiting nutzen würde.
Hmmm schrieb: > Uwe sprach vom Abschalten von RE, d.h. gesendet wird an alle, > empfangsseitig wird immer nur der Receiver aktiviert, von dessen Bus man > gerade eine Antwort erwartet. (prx) A. K. schrieb: > Auswahl des aktiven Transceivers per DE/RE hat gegenüber dem vorigen > Broadcast-Prinzip einen klaren Vorteil: Ein defekter Ast ist leicht > identifizierbar und legt nur sích selbst lahm. Koppelt man alle Äste, > ist mit einem defekten Ast u.U. die ganze Steuerung nachhaltig tot und > zur Diagnose muss man Stecker ziehen. > > So nebenbei ergibt sich auch ein deutlicher Unterschied im Spitzenstrom. > Ein RS485 Abschluss frisst recht viel Strom, und bei 13 gleichzeitig > aktiven Ästen merkt man das. Genau das war auch mein Gedanke
Olly T. schrieb: > Siehe angehängte Bilder Super, danke für den Hinweis und die Bilder :-) Die Idee ist gut
Hallo Uwe, ich habe Dir gerade eine PN mit ein paar Informationen zu einer sehr ähnlichen Baugruppe mit acht RS485-Schnittstellen geschickt, die ich kürzlich entwickelt habe. Die ließe sich in Windeseile für Deine Zwecke anpassen.
(prx) A. K. schrieb: > Auswahl des aktiven Transceivers per DE/RE hat gegenüber dem vorigen > Broadcast-Prinzip einen klaren Vorteil: Ein defekter Ast ist leicht > identifizierbar und legt nur sích selbst lahm. Das stimmt natürlich. Mein Vorschlag würde sich eben wie ein großer Bus verhalten. Ob das ein Vor- oder ein Nachteil ist, muss der TE entscheiden. ;-) > So nebenbei ergibt sich auch ein deutlicher Unterschied im Spitzenstrom. Ja, auch das muss man berücksichtigen. Hmmm schrieb: > Uwe sprach vom Abschalten von RE, d.h. gesendet wird an alle, > empfangsseitig wird immer nur der Receiver aktiviert, von dessen Bus man > gerade eine Antwort erwartet. > > So kann man die Receiver-Ausgänge einfach parallelschalten, man braucht > nur einen Pullup für die Umschaltzeiten. Ja, ich schrieb ja, dass das so gehen würde. Man braucht dazu halt für jeden Teil-Bus ein separates Signal und muss wissen, welcher Teilnehmer auf welchem Teil-Bus hängt, aber das sind beides keine unlösbaren Probleme.
Olly T. schrieb: > und muss wissen, welcher Teilnehmer auf welchem Teil-Bus hängt Das kann der Master selbst herausfinden, indem er beim Start (oder in gewissen Abständen / bei Bedarf) nacheinander alle Äste nach den gesuchten IDs abklappert.
:
Bearbeitet durch User
Andreas S. schrieb: > Hallo Uwe, > > ich habe Dir gerade eine PN mit ein paar Informationen zu einer sehr > ähnlichen Baugruppe mit acht RS485-Schnittstellen geschickt, die ich > kürzlich entwickelt habe. Die ließe sich in Windeseile für Deine Zwecke > anpassen. Hab's mir gerade angesehen, tolle Arbeit. Sieht ungefähr so aus wie mein Plan im Kopf :-)
Jungs, ich danke euch für die Ratschläge und die hilfreichen Tipps. Ich setz mich morgen mal an den Compi und entwerfe die Platine. mal sehen, was dabei rauskommt
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.