Announcement: there is an English version of this forum on Hi Leute, Ich hab mal wieder ein Thema, bei dem mein Wissen - Als Informatiker der das nur Hobbymäßig hin und wieder mal macht - wieder an seine Grenzen stößt. Ich plane ein Projekt, das ein mehr oder weniger eigenes Bussystem bekommen soll. Dafür hätte ich gern RS485 mit der Möglichkeit zu erkennen wenn kein Teilnehmer am Bus angeschlossen ist und wenn es möglich/sinnvoll ist Würde ich Power over Bus implementieren, damit der Kommunizierende Teil unabhängig vom Rest des Knotens ist. Ich hoffe es ist verständlich.... Damit ist das wichtigste gesagt. Damit ihr vllt meine Gedanken versteht, würde ich euch mal erzählen Wie ich an den Punkt gekommen bin. Es geht grundsätzlich darum eine Sammlung von Knoten zu haben, die auf bestimmte Weise miteinander reden können sollen. Wer das nicht Lesen Will, kann zum letzten Absatz skippen, da kommt der Teil, der für den Thread am wichtigsten ist! Meine persönlichen Anforderungen sind die folgenden: 1. Automatische Enumeration von Knoten 2. Automatische Addressierung von Knoten 3. Automatische Parametrierung wenn ein Knoten ersetzt wird 4. Pseudo masterless 5. Kein fixer Addressraum Ich hoffe die Eigenschaften sind richtig benannt und ihr versteht mich nicht falsch. Teilweise sind die Features auch nur abhängig vom Protokoll!!! Ich hab sie nur an mein ganzes Projekt, weswegen auch der Anspruch an den Bus ist, dass das möglich ist. Ich möchte meinen Bus möglichst billig haben und möglichst primitiv, also nehme ich UART als Basis. Das ist quasi auf jedem Mikrocontroller seit schon immer drauf, weswegen eine Riesige Bandbreite an Controllern zur Verfügung steht. Also kann potentiell jemand der später mal mein System erweitern möchte benutzen was er will. Da ich es für wenig sinnvoll halte entweder RS232 Signale oder direkt ttl UART über lange Kabel zu schicken - mir ist klar, dass RS232 problemlos größere Strecken schafft, aber es braucht eine Referenz zu Masse und ich würd gern die Möglichkeit haben den Bus galvanisch zu trennen. (Bitte korrigiert mich wenn man RS232 sinnvoll galvanisch getrennt benutzen kann!) Da UART aber nur eine Punkt-zu-Punkt Verbindung ist muss ich da tricksen. Der erste und aus meiner Sicht offensichtliche Gedanke wäre "Es gibt einen Master und beliebig viele Slaves. Die Rx Leitungen aller Slaves sind verbunden und gehen auf den Tx vom Master. Mit den Tx der Slaves und Rx des Master identisch." Da bin ich aber an dem Problem hängen geblieben, dass die Slaves dafür Addressen haben müssten. Ich will keine Addressen vorgeben und ich will im Master kein Polling machen müssen, deswegen ist das Design raus. Dann bin ich zum Schluss gekommen, dass eine Art Daisy-chain das sinnvollste ist. Also Master Tx -> Knoten 1 Rx ; Knoten 1 Tx -> Knoten 2 Rx ; ... ; Knoten N Tx -> Master Rx. Das passt ganz gut, denn dann geht die Kommunikation immer nur in eine Richtung und ein Knoten kann jederzeit entscheiden Eine Nachricht an den Master abzusetzen. Das ich keine Kommunikation zwischen Knoten brauche ist das so vollkommen brauchbar für mich. Dann hab ich drüber nachgedacht auf welchem Weg ich denn die Daten zwischen den Knoten übertragen möchte. Ich brauch kein Duplex, denn meine Kommunikation ist unidirektional. Ich brauch eine Robuste Kommunikation, die längere Strecken ab kann. Ich hätte gern möglichst Verbinder und Kabel, die verbreitet sind, damit man sie nicht von Hand anfertigen muss, wenn man nicht will. Am Anfang wollte ich entweder DB9 benutzen, weil der ein Paar Pins hat, die für andere Features vllt cool wären, aber irgendwie ist die Zeit von Seriell Kabeln langsam vorbei und die sind nicht mehr so einfach zu kaufen. Dann dachte ich an Telefonkabel mit RJ11 Steckern, aber auch deren Zeit ist langsam vorbei, außerdem sind RJ11 zu RJ11 Kabel auch relativ selten.... Schlussendlich bin ich bei RJ45 hängen geblieben, denn es hat genug Pins um ein paar der Features umzusetzen, es ist verbreitet und es hat Kabel, bei denen Egal ist welche Seite im Sender und welche im Empfänger steckt. Außerdem bekommt man Ethernet Kabel an jeder Ecke und selbst das bescheidenste Ethernetkabel - vorausgesetzt es hat alle 4 Paare - ist mehr als gut genug für meinen Bus. Da Ethernet Kabel ja schon mit twisted Pairs kommen, bin ich geneigt auch irgendwie ein RS485 oder so zu benutzen - Bietet sich ja geradezu an. Also ist mein Plan folgender: Ein Paar vom Master aus gesehen ist die Transmit Seite. In der Seite hängen die ganzen Knoten. Ein zweites Paar vom Master aus ist die Receive Seite und die wird entweder direkt verbunden, oder in jedem Knoten gepuffert - was potentiell sinn machen würde. Dann bin ich an einem Anderen Teil hängengeblieben, der mich gestört hat: Wie sieht das dann beim letzten Knoten aus? Muss der Letzte Knoten einen physischen Schalter haben um anzuzeigen, dass er der letzte Knoten ist? Wie sieht das aus, wenn der verpeilter User oder jemand mit bösen Absichten versucht damit knoten vom Bus zu trennen? Muss ich da ein spezielles Kabel haben, wo ein Paar auf einen extra Stecker gelegt wird und im Zweifel die Stecke zwischen dem vorletzten Knoten und dem Letzten auch neu verlegen, wenn ich einen weiteren Knoten anhängen will? Also hab ich mir überlegt, dass ich gern automatisch erkennen würde wenn ein Knoten der letzte ist und dass er dann automatisch seinen Ausgang mit dem Rückweg verbindet. Also am besten testen ob auf der Ausgangsseite des Knotens ein Busfault anliegt und dann automatisch umschalten. Jetzt hab ich herausgefunden, dass man Fehler im Bus bei RS485 "relativ einfach" erkennen kann, indem man zwei Fehlertollerante Receiver benutzt und bei einem die Polatität tauscht. Es muss dann wohl auch noch einen Abschlusswiderstand im Bus geben, damit die Busspannung bei Offenem Bus auch zusammenbricht, aber das ist ja kein Ding. Im besten Fall könnte ich zwischen Bus offen und Bus kurzgeschlossen unterscheiden, aber das ist nicht wichtig. Wichtig ist nur, dass ich rausfinden kann, ob da ein valider Teilnehmer angeschlossen ist und gut. Da dieses System aber nur funktioniert, wenn alle Teilnehmer im Bus Strom haben, hab ich mir überlegt wäre es vllt sinnvoll dass man über das Buskabel auch zumindest ein kleines Bisschen Strom mitschicken kann. RJ45 hat 4 Paare, also 8 Leitungen. Zwei Paare sind mit Hin- und Rückweg verplant, also bleiben noch zwei Paare übrig. Für ein anderes Feature das ich gerne umsetzen würde brauch ich das dritte Paar und dann bleibt noch ein einziges Paar über.... Ich hab also überlegt, ob ich mir das Paar als Versorgungsleitungen nehme. Dann bin ich ggf eingeschränkt in der Menge an Strom, die jeder Knoten ziehen kann. Viel lieber würde ich da doch Power over Bus auf den beiden ersten Paaren umsetzen, damit ich quasi den doppelten Querschnitt für meine Stromversorgung haben kann. (Vllt übertreibe ich da auch maßlos! Ich kann nicht gut einschätzen wie viel Strom ich über ein Adernpaar ziehen kann, bedenkt aber bitte das jeder Teilnehmer Strom ziehen soll, damit zumindest der Com Teil der Knoten immer Strom hat, wenn der Master Strom hat.) Ich hab vor auf dem dritten Adernpaar noch einen Can-bus parallel laufen zu lassen, der aber optional ist, falls die Knoten Daten übertragen wollen, bei denen die Latenz wichtig ist, oder wo Knoten untereinander kommunizieren wollen. Wieso da Can zum Einsatz kommt und nicht auch ein RS485 ist ne ganz andere Geschichte und hier nicht unbedingt relevant. Aber auch bei Can gäbe es die Möglichkeit Power over Bus zu machen, um den Knoten mehr Strom zur Verfügung zu stellen, sollte das in der Praxis notwendig werden. Zu meinem letzten Punkt mit dem Masterless: Es wird einen Master geben, der auch eine Sonderstellung einnimmt, aber die ist hauptsächlich darin, dass er Eine Stromquelle darstellt und dass eine normale und eine separate "Loop-in" Buchse bekommt, sollte man doch aus gründen physisch einen Ring legen wollen - auch wenn mir da momentan noch nicht klar ist, welcher konkrete Fall das sein soll. Ich will nur, dass die Kommunikation nicht daran gebunden ist, dass die Knoten von einem Master gepollt werden, sondern dass Knoten ggf Fehler oder Events an den Master melden können, ohne das auf dem Can-Bus zu tun. Der soll ja nur optional sein und das Feature mit dem Melden soll immer funktionieren. Desewgen auch die Daisychain! Jetzt kennt ihr meine Überlegungen dazu und jetzt kommt der Teil wieso ich das überhaupt Frage! Glaubt ihr es ist möglich Power over Bus und LoS-Detection gleichzeitig zu implementieren? Wenn nicht, bleibt ja noch imer PoB bei CAN. Und ich würde mal gern eine Einschätzung von euch hören, wie viel Strom man über ein einzelnes Adernpaar eines Ethernet Kabels bekommt. Ich würde die Spannung dabei möglichst auf einem geringen Maß halten, da ich nicht sicherstellen kann, dass ich da nicht mal mit Schraubklemmen hantiere und mich nebenbei selbst schocke.... Wahrscheinlich ist es auch einfacher mit kleineren Spannungen. Mein Ziel wären entweder 12V oder 24V am Master, wobei ich hoffe 12V sind ausreichend.
Ich fange mal von hinten an. Mit 12V kommst Du nicht weit. In der Praxis (z.B. bei ISDN oder PoE) werden 48V verwendet, weil das noch Kleinspannung ist und noch keinen Berührungsschutz benötigt. Wenn Du die Spannung halbierst, verdoppelst Du den Strom und vervierfachst Du die Verlustleistung im Kabel. Ganz blöde Idee, vor allem, wenn die Kabel länger werden PoE+ gemäß 802.3at arbeitet mit 600mA. Dabei liegen die 48V zwischen dem TX-Paar und dem RX-Paar an, wobei die Einspeisung über die Mittelanzapfung am Übertrager erfolgt. Alternativ über die ungenutzen Paare 4,5 und 7,8. Pro RJ45-Pin sind das also 300mA. Zu Deinem Bussystem hast Du Dir ja einige Gedanken gemacht. Du übersiehst aber den Hardwareaufwand dabei. Und Du vergisst dabei, dass Du alles selber machen musst und nichts fertig dazukaufen kannst, was woanders in Massen und damit billig produziert wird. Bei Amazon gibts beispielsweise ENC28J60 SPI-Ethernet-Breakout-Boards für teilweise unter 5€. Du wirst Dein proprietäres Businterface niemals für 5€ inkl. Leiterplatte und Buchse etc produzieren, selbst ohne Busspeisung nicht. Damit sind Deine ganzen Überlegungen sinnlos. Mit Standardlösungen kommst Du meistens besser weg. fchk
Stefan S. schrieb: > 1. Automatische Enumeration von Knoten > 2. Automatische Addressierung von Knoten > 3. Automatische Parametrierung wenn ein Knoten ersetzt wird > 4. Pseudo masterless > 5. Kein fixer Addressraum Also LocalTalk nach 30 Jahren nochmal neu erfinden? Da würde ich erstmal nachschauen, wie Apple das damals gemacht hat. Außerdem: Daisy-Chain ist unpraktisch. Wenn da mal bei einem Knoten ein Stecker rausrutscht oder ein Kabel versagt, ist der ganze Bus tot und der Fehler lässt sich nur schwer eingrenzen.
Das dicke AppleTalk-Buch kann man downloaden. Lesen. verstehen und dann notfalls wiederkommen. Warum machst du nicht gleich alles per CAN? Und RJ45 belegt mit eigener Funktionalität ist gelinde gesagt problematisch.
tl;dr Trotzdem folgender Hinweis: Hast dir schon mal NMEA 0183 angeschaut? Kann man sich sicher was davon abkucken. Oder NMEA 2000 (basiert auf SAE J1939/CAN)?
Frank K. schrieb: > Zu Deinem Bussystem hast Du Dir ja einige Gedanken gemacht. Du > übersiehst aber den Hardwareaufwand dabei. Und Du vergisst dabei, dass > Du alles selber machen musst und nichts fertig dazukaufen kannst, was > woanders in Massen und damit billig produziert wird. Bei Amazon gibts > beispielsweise ENC28J60 SPI-Ethernet-Breakout-Boards für teilweise unter > 5€. Stimmt vollkommen, aber wenn Ethernet für die Anwendung, die ich brauche geeignet wäre, dann hätte ich schon längst Ethernet genommen! Wenn ich das aber über Ethernet direkt machen wollte, dann müsste ich ein custom Protokoll darüber fahren und ich komme nicht mit viel weniger Aufwand und wahrscheinlich Kosten (Obwohl das vllt sogar noch passen könnte) weg, wenn ich meinen Bus so baue wie ich ihn vor habe mit Platine baue. Außerdem komme ich um die Kosten von einer Platine ja eh nicht rum, denn ich will ja keine Bus module bauen, sondern die sachen direkt in meine Platinenlayouts einabuen. Da müsste ich bei Ethernet auch auf ein bisschen mehr achten als mit dem langsameren RS485. Außerdem ist das ein Spaßprojekt und da kommt es mir nicht auf kosten an. Nosnibor schrieb: > Also LocalTalk nach 30 Jahren nochmal neu erfinden? Da würde ich erstmal > nachschauen, wie Apple das damals gemacht hat. Ich hab LocalTalk noch nie gehört, aber stimmt, ich kann mir das mal anschauen. Nosnibor schrieb: > Außerdem: Daisy-Chain ist unpraktisch. Wenn da mal bei einem Knoten ein > Stecker rausrutscht oder ein Kabel versagt, ist der ganze Bus tot und > der Fehler lässt sich nur schwer eingrenzen. Ich hab automatische Erkennung für Busfehler! Wenn zwischen Konten 8 und 9 jetzt plötzlich der das Kabel raus rutscht, erkennt Knoten 8 dass er der neue letzte Knoten ist und sagt dem Master bescheid. Dann weiß ich ganz genau, wo der Fehler sitzt. Ich weiß jetzt nicht, was das Problem da sein soll? Abdul K. schrieb: > Warum machst du nicht gleich alles per CAN? Und RJ45 belegt mit eigener > Funktionalität ist gelinde gesagt problematisch. Weil ich CAN allein für ungeeignet halte um größere Datenmengen darüber zu senden. Can ist bei mir aus Preisgründen eigentlich auf MCP2515 oder Controller mit Can eingebaut beschränkt und die können in der regel beide kein CAN-FD. Außerdem soll der CAN Bus ja nur optional sein für manche Spezialfälle, wo mein Bus zu hohe Latenzen hat. Außerdem könnte ich das mit CAN-FD machen, dann bleibt mir aber noch immer das Problem, dass ich am anfang einmal addressen vergeben muss ohne dass ich irgendwo im Flash ne Seriennummer abgelegt haben will. Das hab ich ausprobiert und zum laufen bekommen, ist mir aber zu viel aufwand das in Platformio immer einzurichten. Und auch hier wieder der Hinweis, dass das ein Spaß Projekt ist und ich wenig wert auf Sinnhaftigkeit legen möchte. Jester schrieb: > Trotzdem folgender Hinweis: Hast dir schon mal NMEA 0183 angeschaut? > Kann man sich sicher was davon abkucken. Oder NMEA 2000 (basiert auf SAE > J1939/CAN)? Ne hab ich nicht, mach ich nach dem freundlichen Hinweis aber. Vielen Dank dafür! Nema 0183 Hab ich mir grad mal auf Wikipedia angeschaut, sieht super interessant aus, aber Mein Protokoll sollte mehr Binärdaten haben, hat aber deutliche Ähnlichkeiten zu meinem prototyp protokoll spec. Nema 2000 Hab ich auch grad mal fix auf Wikipedia angeschaut und auch das ist interessant, aber hilft mir augenscheinlich relativ wenig. Ich schau mir beides aber morgen mal in ruhe ordentlich an.
Ich möchte aber nochmal Klarstellen, dass meine Frage hier hauptsächlich darauf abzielt, dass ich mir unsicher bin, ob ich LoS-Detection und PoB sinnvoll und stabil gleichzeitig benutzen kann. Wenn ich PoB benutzen möchte, dann Funktioniert das ja, indem ich zwischen dem Transceiver und dem eigentlichen Bus Kondensatoren einbaue, um das Spannungsoffset auszukoppeln und Spulen jeweils zu Masse und V_bus um die Bussignale auszukoppeln. Wenn ich LoS-Detection benutzen möchte, benutze ich zwei Receiver, wo bei einem A und B vertauscht werden und schaue wann beide eine logische 1 liefern. Das ist in dem Fall wenn entweder der Bus offen, oder kurzgeschlossen ist. Meine Sorge galt dem Zustand, dasss entweder durch Tolleranzen, oder Alterung die Kondensatoren gegen den DC-Offset durchlässig werden und ich nicht mehr 0V habe wenn der Bus offen ist. Die Ausgänge der Knoten müssten ja für die nächsten Knoten als Einspeisung fungieren und haben deshalb immer Strom. Wenn ich die Spannung über Zwei Adernpaare einkoppel, müsste ich mir zumindest um die Kondensatoren keine Gedanken mehr machen.
Frank K. schrieb: > Mit 12V kommst Du nicht weit. In der Praxis (z.B. bei ISDN oder PoE) > werden 48V verwendet, weil das noch Kleinspannung ist und noch keinen > Berührungsschutz benötigt. Wenn Du die Spannung halbierst, verdoppelst > Du den Strom und vervierfachst Du die Verlustleistung im Kabel. Ganz > blöde Idee, vor allem, wenn die Kabel länger werden Ist mir vollkommen klar, aber dann bräuchte ich entweder ein 48 Netzteil, oder ich müsste mir einen Step-UP in die Master Platine einbauen, um aus den 24V die ich eh überall als Versorgungsspannung brauche 48V zu machen. Das schien mir relativ unsinnig, zumal ich ja hoffentlich relativ wenig Strom brauche um nur den Mikrocontroller und die paar Transceiver zu versorgen. Frank K. schrieb: > PoE+ gemäß 802.3at arbeitet mit 600mA. Dabei liegen die 48V zwischen dem > TX-Paar und dem RX-Paar an, wobei die Einspeisung über die > Mittelanzapfung am Übertrager erfolgt. Alternativ über die ungenutzen > Paare 4,5 und 7,8. Pro RJ45-Pin sind das also 300mA. Hab nicht dran gedacht da selbst mal in den Spec zu schauen, aber vielen Dank, dass du das gemacht hast. Die Spannung über zwei Paare anzulegen ist mir garnicht in den Sinn gekommen, macht aber relativ viel sinn wenn ich es mir genauer überlege und im Zweifel würde ich das so machen.
Frank K. schrieb: > Du wirst Dein proprietäres Businterface niemals für 5€ inkl. > Leiterplatte und Buchse etc produzieren, selbst ohne Busspeisung nicht. > Damit sind Deine ganzen Überlegungen sinnlos. War auch nie mein Plan. Mein Plan war, dass ich einen Bus selbst entwerfe, der sich dazu eignet eine große Anzahl an Knoten und eine sehr große Menge an IO-Kanälen halbwegs schnell handhaben zu können und möglichst stabil, sowie diagnosefreundlich und idiotensicher zu sein. Außerdem wollte ich eine ganze Menge an Komfort Funktionen, die ganz viele Standard Busse heute garnicht haben. Und ich wollte einen Bus, der möglichst Primitiv für den Controller ist, damit ich als Demo zum Beispiel auch meinen Eigenbau von einem 6502 Computer als Master an den Bus hängen kann und weiß, dass das funktioniert. Und zu den 5€ wollte ich noch Loswerden, dass ich wenn dann nur Ethernet mit PoE benutzen würde, damit ich auch das die Kommunikation mit dem Knoten aufrecht erhalten kann, auch wenn die eingentlichen Knoten inaktiv sind. Leider hab ich von den ganzen Ethernet Modulen noch kein einziges mit PoE für 5€ gesehen. Also kommen das auf das 5€ Modul nochmal mindestens 5-10€ für einen PoE-Splitter drauf und dann bin ich wahrscheinlich fast bei dem Preis den mein Bus umgerechnet kostet. Auch wenn ich fürchte das klang oben alles sehr aggressiv klang, war das nicht so gemeint. PoE Funktioniert meines Wissens auf 100m, aber ich würde sagen das brauch ich nicht. Es kann natürlich auch sein, dass ich die Strumversorgung auch komplett über separate Kabel mache. Der Reiz daran war, dass man sehr kleine und stromsparende Knoten dann ja komplett via dem Bus versorgen könnte, wenn sie nur ein ganz einfacher Sensor oder ein einzelner Taster mit LED sind.
Auch wenn das bescheuert klingt, wollte ich ursprünglich eine Art Rückwandbus für eine pseudo SPS entwerfen, der alles kann was Siemens und Co können, aber in so einfach, dass ein Atmega, oder rein großer Attiny in einem Knoten ausreicht. Ich weiß, dass es da wahrscheinlich bessere Wege für gibt, aber ich wollte halt mein eigenes Ding entwerfen.
Man muß das Datensignal nicht über Kondensatoren einkoppeln. Das analoge Telefonsystem macht es über Trafos. Du hast zu wenig Hintergrundwissen und kein richtiges Konzept über den gewünschten Funktionsumfang. Vielleicht wäre Funk die bessere Lösung. Ist heutzutage sogar oft billiger. LoRa Außerdem hattest du doch schonmal so einen Thread angefangen. Ich erinnere mich dran.
Also Die Hardware sieht dann im groben so aus, dass es einen Eingang und einen Ausgang gibt. LoS-Detection braucht nur der Ausgang, also sollten drei Transceiver genügen. Wenn ich mir den günstigsten Chip bei reichelt hole, der einen Transceiver hat, kostet der 1€ und wenn ich mir die günstigsten Ethernet Buchsen ohne Übertrager hole, kosten die je 1.50€. Da komme ich auf 6€ und da der Kram ja eh auf einer anderen Platine integriert wird brauch ich die hier nicht mitrechnen. Okay, ich könnte jetzt den rs485 Repeater mitrechnen, den ich im Rückweg haben würde, aber das hab ich mal vernachlässigt, da ja nicht jeder Knoten einen braucht.
Stefan S. schrieb: > Ich weiß, dass es da wahrscheinlich > bessere Wege für gibt, aber ich wollte halt mein eigenes Ding entwerfen. Ich denke, das ist die eigentliche Hauptmotivation. Du hast da nämlich beispielsweise einige argumentative Brüche zwischen "Ich möchte meinen Bus möglichst billig haben" und "Außerdem ist das ein Spaßprojekt und da kommt es mir nicht auf kosten an.". Um Dir mal noch einen alternativen Weg aufzuzeigen: Sagt Dir die 20mA-Stromschleife (TTY) noch was, oder bist Du dafür zu jung? Stell Dir einen Stromkreis vor, in den alle Knoten eingeschleift sind. Ein Netzteil speist einen Strom(!) von 20mA ein (die Spannung wird automatisch nachgeregelt, bis der Strom auf 20mA ist). Jeder Knoten kann den Strom detektieren (z.B. über die LED eines Optokopplers), und jeder Knoten kann den Stromkreis (kurz) unterbrechen (z.B. über den Fototransistor eines zweiten Optokopplers). Jetzt definiere 1 als "Strom an", 0 als "Strom aus" und hänge die beiden Optokoppler an einen UART. Fertig ist die Stromschleife. Jeder Knoten empfängt alles, und jeder kann senden (aber nur einer zur Zeit). Funktioniert mit Klingeldraht über Kilometer. Der Leitungswiderstand spielt keine Rolle, weil das Netzteil ja den Strom auf 20mA regelt. Das gibts seit den 60'ern und wurde für Fernschreiber, Drucker, Terminals und sonstiges serielles verwendet. Galvanische Trennung bekommst Du quasi geschenkt. In der Industrie wird etwas ähnliches zur Übertragung analoger Messwerte verwendet, wobei dort der Stromkreis nicht unterbrochen wird, sondern der Innenwiderstand des Sensors gesteuert wird. Der Sensor versorgt sich mit dem Schleifenstrom auch selber. (4-20mA Stromschleife) fchk
Abdul K. schrieb: > Man muß das Datensignal nicht über Kondensatoren einkoppeln. Das analoge > Telefonsystem macht es über Trafos. Ich werde Wahrscheinlich die Chips von TI verwenden und TI gibt in einer Anwendungsnotiz explizit die Empfehlung das via Kondensatoren und Spuen zu Masse und V_bus zu tun. und wenn der Hersteller das so empfiehlt, wieso sollte ich das anders machen? Natürlich könnte ich das acuh via Übertragern machen, aber warum sollte ich? Zu Trafos und Spulen hab ich von TI fertige Formeln und zu den Trafos nicht. Abdul K. schrieb: > Vielleicht wäre Funk die bessere Lösung. Ist heutzutage sogar oft > billiger. LoRa Funk ist ganz explizit keine Lösung, da ich explizit an einem verkabelten Bus arbeite. Jedes Funksystem Bräuchte außerdem wieder inhärent irgendwelche addressen von Anfang an und du erinnerst dich, dass das nicht mit meinen Anforderungen vereinbar ist. Außerdem geht es darum einen Bus zu entwerfen und nicht darum einen Bus zu finden. Abdul K. schrieb: > Du hast zu wenig Hintergrundwissen und kein richtiges Konzept über den > gewünschten Funktionsumfang. Den habe ich sehr genau, auch wenn mein Hintergrundwissen über alle Symmetrisch übertragenen Busse mit Spannungstransport, die es in den letzten 100 Jahren gab vielleicht ein bisschen zu wünschen übrig lässt. Außerdem wäre es - finde ich ein bisschen vermessen zu erwarten, dass ein Informatiker, der das ganze in seiner Freizeit zum Spaß tut das selbe Hintergrundwissen besitzt, das zum Beispiel ein erfahrener Ingenieur der das schon seit 40 Jahren macht. Du scheinst aber in diesem Fall viel mehr zu wissen, also bitte erleuchte mich doch einfach, anstatt mir Unwissenheit vorzuwerfen. Abdul K. schrieb: > Außerdem hattest du doch schonmal so einen Thread angefangen. Ich > erinnere mich dran. Da hatte ich aber keinen Plan und kein Konzept. Dieses Mal hab ich deutlich mehr plan und mein Protokoll ist featurecomplete und abgeschlossen. Da diese Teile aber nicht relevant sind, hab ich sie hier nicht erwähnt. Damals wardas projekt und der kontext ein anderer
RS-485 würde ich nichtmal mehr mit der Kneifzange anfassen, erst recht nicht für Neuentwicklungen. CAN ist robust und vor allem super einfach. Die wichtigsten Sachen sind schon alle implementiert, ohne eine Zeile Software dafür schreiben zu müssen. Auch große Datenmengen (Bootloader) sind überhaupt kein Problem, man führt einfach eine Paketnummer mit. Der Hauptvorteil ist der echte Multimaster, jeder darf wirklich zu jeder beliebigen Zeit lossenden. Die Hardware kümmert sich intern um Arbitration und Retry. RS-485 über 2 Drähte ist eine Illusion. Kann funktionieren, muß aber nicht. Der GND-Versatz darf maximal +/-5V betragen, damit es noch klappt. Ist bei CAN genau das gleiche.
Abdul K. schrieb: > Du hast zu wenig Hintergrundwissen und kein richtiges Konzept über den > gewünschten Funktionsumfang. In der Findungsphase, und in der befindet sich der TO offensichtlich, würde ich mir bestehende Verfahren anschauen - inclusive deren Anwendung und Historie. Das frisst zwar Zeit, was aber bei einem Hobbyprojekt nicht schlimm sein sollte, aber es macht auch Spaß. Dabei lernt man zu verstehen, wieso LAYERs so wichtig sind (z.B. https://en.wikipedia.org/wiki/OSI_model) - und ganz nebenbei auch, Probleme wie das vom TO skizzierte, sauber zu strukturieren. Ethernet (https://en.wikipedia.org/wiki/Ethernet) stammt ursprünglich von Xerox und sollte die Idee eines ‚shared mediums‘ verwirklichend: Die „Vampir-Technk“ von 10-base-5, bei der ein physikalisch ein Kabel angebohrt wird, macht das „begreifbar“. Ansonsten siehe auch ALOHAnet (eine Art Paketradio). NMEA 0183 ist eine Schnittstelle, die sehr erfolgreich in der Schifffahrt eingesetzt wird. Das können kleine Segeljachten sein, um z.B. Tochter-Anzeigen im Cockpit anzusteuern - geht aber hoch bis Containerschiffe zum Vernetzten von Sensorik, Kartenplotter, Radaranlage, Navigationsempfänger jeglicher Couleur...
Peter D. schrieb: > CAN ist robust und vor allem super einfach. Er hat alles drin, was man zum Betreiben von Maschinen und sogar kompletten Fertigungsstraßen braucht. Und das Beste: das, was einen Bus kompliziert macht, nämlich die Arbitrierung und die Fehlerhandlung und sogar die Fehlerbehebung ist in die Hardware eingebaut und millionenfach erprobt. Abdul K. schrieb: > Du hast zu wenig Hintergrundwissen und kein richtiges Konzept über den > gewünschten Funktionsumfang. Und eines kommt dazu: in einem wirklich zuverlässig funktionierenden Bussystem stecken zigtausende Ingenieursstunden. Das sollte man sich mal richtig bewusst machen, wenn man einfach so von ganz vorne anfangen will... Zusammenfassend kann man sagen: > RS485 mit LoS detection und PoB möglich und sinnvoll? Möglich: ja. Sinnvoll: nein.
:
Bearbeitet durch Moderator
Peter D. schrieb: > CAN ist robust und vor allem super einfach. Die wichtigsten Sachen sind > schon alle implementiert, ohne eine Zeile Software dafür schreiben zu > müssen. Auch große Datenmengen (Bootloader) sind überhaupt kein Problem, > man führt einfach eine Paketnummer mit. Der Hauptvorteil ist der echte > Multimaster, jeder darf wirklich zu jeder beliebigen Zeit lossenden. Die > Hardware kümmert sich intern um Arbitration und Retry. Ich hab nie behauptet, dass CAN nicht ausreicht, aber ich möchte das halt so bauen, da ich zum Beispiel keine Lust hätte mir einen Bit-Bang Treiber für SPI zu schreiben, damit ich can machen kann auf einem 6502. Aber Das ist ja nicht Hauptanwendung, also nicht so wichtig. Der Bus wie ich ihn grad geplant hat braucht garkeine Arbitration, denn die Kommunikation ist unidirektional so dass kollisionen ausgeschlossen sind. Peter D. schrieb: > RS-485 über 2 Drähte ist eine Illusion. Kann funktionieren, muß aber > nicht. Der GND-Versatz darf maximal +/-5V betragen, damit es noch > klappt. Ist bei CAN genau das gleiche. Scheint aber in der Praxis ganz gut zu funktionieren, wenn ich mal si in richtung industrie schaue. Jester schrieb: > In der Findungsphase, und in der befindet sich der TO offensichtlich, > würde ich mir bestehende Verfahren anschauen - inclusive deren Anwendung > und Historie. Vielen dank, dass du es mal augesprochen hast! Jester schrieb: > Das frisst zwar Zeit, was aber bei einem Hobbyprojekt nicht schlimm sein > sollte, aber es macht auch Spaß. Dabei lernt man zu verstehen, wieso > LAYERs so wichtig sind (z.B. https://en.wikipedia.org/wiki/OSI_model) - > und ganz nebenbei auch, Probleme wie das vom TO skizzierte, sauber zu > strukturieren. Stimmt, ich hab mir verschiedene Dinge aus dem Smart home und Industriebereich bereits angeschaut, die alle ähnlich funktionieren und nicht besonders gut in meine Pläne passen. Unter anderem CAN-Open, Ethercat, Modbus rtu, modbus tcp, Profibus dp, profinet, KNX, dieses komische Protokoll das Eltako benutzt um ihren enocean bus zu bauen und noch andere. Die sind alle sehr interessant, aber ich glaub die sind alle nicht im Ansatz was ich suche. Leider sind die ganzen Rückwandbusse von den SPS-Systemen alle Proprietär und deshalb nicht zugänglich. Diese Busse können ganz viel von dem was ich will.
Lothar M. schrieb: > Er hat alles drin, was man zum Betreiben von Maschinen und sogar > kompletten Fertigungsstraßen braucht. Und das Beste: das, was einen Bus > kompliziert macht, nämlich die Arbitrierung und die Fehlerhandlung und > sogar die Fehlerbehebung ist in die Hardware eingebaut und millionenfach > erprobt. Vollkommen richtig! Lothar M. schrieb: > Und eines kommt dazu: in einem wirklich zuverlässig funktionierenden > Bussystem stecken zigtausende Ingenieursstunden. Das sollte man sich mal > richtig bewusst machen, wenn man einfach so von ganz vorne anfangen > will... Ich weiß, mir geht es bei diesem Projekt aber ausdrücklich um die Entwicklung und ein besseres Verständnis von anderen Bussen. Wenn dabei langfristig ein halbwegs robustes System raus kommt das ich in einem anderen Projekt recyclen kann, ist es super. Mir persönlich geht es aber auch darum einen kompletten Software-Stack und alles zu entwickeln um am ende einen raspberry Pi Hat zu haben, der mit ein paar demo boards reden kann. Und wenn das eh ein Spaß und engineering Projekt ist, dann finde ich das muss nicht unbedingt sinn machen, oder perfekt sein. Lothar M. schrieb: > Zusammenfassend kann man sagen: >> RS485 mit LoS detection und PoB möglich und sinnvoll? > Möglich: ja. > Sinnvoll: nein. Hast du da schonmal eine Anwendung gesehen, wo das gemacht wurde? Ich hab ums verrecken keine Einzige gefunden. Mich würde mal interessieren, wie das da gemacht wurde, wenn es eine gibt. Ansonsten freue ich mich sehr wenn ihr mir interessante oder exotische Busse nennt, damit ich ein bisschen mehr stöbern kann.
Stefan S. schrieb: > Ich hab nie behauptet, dass CAN nicht ausreicht, aber ich möchte das > halt so bauen, da ich zum Beispiel keine Lust hätte mir einen Bit-Bang > Treiber für SPI zu schreiben, damit ich can machen kann auf einem 6502. Musst Du ja auch nicht. Nimm einen NXP SJA1000 und hänge ihn an deinen 6502-Prozessorbus. Der SJA1000 kann sowohl den Intel-Bus (!RD, !WR) als auch den Motorola/MOS Bus (R/!W, E/PHI2). Dann kannst Du direkt auf die Register zugreifen. > Peter D. schrieb: >> RS-485 über 2 Drähte ist eine Illusion. Kann funktionieren, muß aber >> nicht. Der GND-Versatz darf maximal +/-5V betragen, damit es noch >> klappt. Ist bei CAN genau das gleiche. > > Scheint aber in der Praxis ganz gut zu funktionieren, wenn ich mal si in > richtung industrie schaue. In der Praxis wird in einem solchen Fall ein gemeinsames Spannungspotential auf andere Weite sichergestellt, um den Common-Mode Bereich eben nicht zu überschreiten. fchk
Frank K. schrieb: > In der Praxis wird in einem solchen Fall ein gemeinsames > Spannungspotential auf andere Weite sichergestellt, um den Common-Mode > Bereich eben nicht zu überschreiten. In der Regel entweder über die Masse der Versorgungsspannung, oder über PE (bei letzterem bin ich unsicher). Bei längeren Strecken wird glaub ich auch öfter eine extra Masseleitung oder so gelegt. Viele Geräte die realistisch nur in einem Schaltschrank auf kurzen Strecken verwendet wird - grad wenn sie günstiger sind - komplett auf die kompensation von common mode verzichtet. Zumindest hab ich schon ein paar günstigere auseinandergenommen und da war nix. Frank K. schrieb: > Musst Du ja auch nicht. Nimm einen NXP SJA1000 und hänge ihn an deinen > 6502-Prozessorbus. Der SJA1000 kann sowohl den Intel-Bus (!RD, !WR) als > auch den Motorola/MOS Bus (R/!W, E/PHI2). Dann kannst Du direkt auf die > Register zugreifen. Mega! Vielen dank für den Tipp! Nach sowas hab ich gesucht. Ich hab auch schon mit IsysBus, respektive Asysbus gespielt, der ja nur auf can aufbaut. Ich bin ein Mega Fan von CAN, aber für das Projekt mit meinem eigenen Bus wollte ich mich explizit nicht auf CAN stützen und hatte mich deshalb ein bisschen auf Ethercat gestützt. Ethercat macht ja ein ähnliches Daisychaining mit einem Loop, um große Datenmengen in echtzeit austauschen zu können.
Stefan S. schrieb: > Ich plane ein Projekt, das ein mehr oder weniger eigenes Bussystem > bekommen soll. Dafür hätte ich gern RS485 mit der Möglichkeit zu > erkennen wenn kein Teilnehmer am Bus angeschlossen ist und wenn es > möglich/sinnvoll ist Würde ich Power over Bus implementieren, damit der > Kommunizierende Teil unabhängig vom Rest des Knotens ist. Ich hoffe es > ist verständlich.... Ist es nicht wirklich. Wenn PoB implementiert ist/wird, ist die Detektion, dass es keinen Busteilnehmer gibt, doch recht trivial und von Hause aus sehr gut abgetrennt von der eigentlichen Kommunikation. > Meine persönlichen Anforderungen sind die folgenden: > 1. Automatische Enumeration von Knoten > 2. Automatische Addressierung von Knoten > 5. Kein fixer Addressraum Das ist relativ trivial. Das Protokoll muss einfach nur nur die Lücken vorsehen, in denen sich neue Busgeräte "melden" können. Und die Adressierung überlässt man Meister Zufall. Das allerdings ist dann doch ein Problem, zumindest für manche Busteilnehmer. Wenn die nicht auf extern eingespeisten Zufall (z.B. aus unique IDs des Chipherstellers) zurückgreifen können, dann wird es, je nach konkreter Hardware, schnell recht schwierig, in akzeptabler Zeit hinreichend Entropie zu gewinnen, um eine wirklich zufällige Adesse zu generieren. > 3. Automatische Parametrierung wenn ein Knoten ersetzt wird Das ist schwierig bis unmöglich. Dazu müsste es nämlich einen Mechanismus geben, der Art und Rolle des Knoten bestimmen kann. Art geht noch, der Knoten kann ja bei der Anmeldung neben seiner Adresse announcen, was er ist und was er kann. Dann ist es recht einfach, gleichartige Nodes zu Gruppen zusammen zu fassen. Aber die Rolle? Woher soll irgendwer (incl. der Node selber) die denn kennen? Beispiel: Fensterkontakt. Kann sagen: "ich habe Adresse 0x47110815" (natürlich zufällig selber ausgewählt) und kann sagen "ich bin ein Kontaktsensor mit einem Kontakt-Kanal". Aber die Node kann nicht sagen: "Es handelt sich um einen Fensterkontakt" und sie kann schon garnicht sagen "Und der ist am mittleren Fenster im Wohnzimmer". Woher soll sie das, zum Teufel wissen? Und woher soll sie (oder irgendwer sonst) wissen, dass sie eine gleichartige defekte Node ersetzt, die früher(tm) mal unter Adresse 0x08154711 zu erreichen war? Das kann nicht funktionieren... > 4. Pseudo masterless ...insbesondere nicht unter dieser Voraussetzung. Also Fazit: Du solltest erstmal lernen, logisch zu denken, bevor du dich an Protokolldesign wagst...
Stefan S. schrieb: > aufbaut. Ich bin ein Mega Fan von CAN, aber für das Projekt mit meinem > eigenen Bus wollte ich mich explizit nicht auf CAN stützen und hatte > mich deshalb ein bisschen auf Ethercat gestützt. Ethercat macht ja ein > ähnliches Daisychaining mit einem Loop, um große Datenmengen in echtzeit > austauschen zu können. Ja, und warum nimmst Du das nicht? Der Master braucht nur einen normalen Ethernet-Controller, und Ethercat Slave Controller gibts zu kaufen: https://www.microchip.com/en-us/products/high-speed-networking-and-video/ethernet/ethercat-technology-solutions fchk
c-hater schrieb: > Das ist schwierig bis unmöglich. Dazu müsste es nämlich einen > Mechanismus geben, der Art und Rolle des Knoten bestimmen kann. Das ist ein häufiges Problem. Wir haben z.B. ein Gerät mit 16 Steckplätzen, in die z.B. 3,5kV-Module gesteckt werden können. Natürlich weiß kein Modul, welche Linse es versorgt. Daher gibt es erstmal eine 4Bit-Slotadresse, mit der die Haupt-CPU die Module zuordnen kann. Weiterhin ist im EEPROM der Haupt-CPU der Hardwaretyp hinterlegt, wie alle Ausgänge verdrahtet und angeschlossen sind, welche aufeinander floaten usw. Erst dann kann die Steuersoftware alle Module richtig zuordnen. Ein gleichartiges Problem hat man auch mit 1-Wire Sensoren DS18B20. Jeder Sensor hat seine eigene Adresse. Damit ist aber noch lange nicht bekannt, welcher Sensor an welcher Meßstelle montiert ist. Um dieses Problem zu lösen, gibt es 2 Möglichkeiten. In einer Konfigurationsphase wird jedem Sensor eine Meßstellennummer zugeordnet. Entweder der Sensor speichert diese Nummer in seinem EEPROM oder der Master legt eine Tabelle aller Adressen an, welche Meßstelle ihnen zugeordnet ist.
:
Bearbeitet durch User
c-hater schrieb: > Ist es nicht wirklich. Wenn PoB implementiert ist/wird, ist die > Detektion, dass es keinen Busteilnehmer gibt, doch recht trivial und von > Hause aus sehr gut abgetrennt von der eigentlichen Kommunikation. Der Teil, der als Stromquelle bei PoB funktioniert kann ja nicht ohne weiteres feststellen, ob da ein Teilnehmer angeschlossen ist, es sei denn ich messe wie viel Energie der bus abnimmt. c-hater schrieb: > Das ist relativ trivial. Das Protokoll muss einfach nur nur die Lücken > vorsehen, in denen sich neue Busgeräte "melden" können. Und die > Adressierung überlässt man Meister Zufall. Das allerdings ist dann doch > ein Problem, zumindest für manche Busteilnehmer. Wenn die nicht auf > extern eingespeisten Zufall (z.B. aus unique IDs des Chipherstellers) > zurückgreifen können, dann wird es, je nach konkreter Hardware, schnell > recht schwierig, in akzeptabler Zeit hinreichend Entropie zu gewinnen, > um eine wirklich zufällige Adesse zu generieren. Das ist ein gelöstes Problem bei mir. Die knoten sind in einer Dasychain. Der Knoten testet via LoS ob da noch ein weiterer Knoten ist. Der Master bekommt immer die ID 0 und er startet einen scan. Der erste Knoten empfängt den Scan, erhöht ein Feld, das sich count nennt, gibt sich die ID 1 und hängt seine Typ-ID und ein Statusbyte an den Scan an. Jeder andere Knoten tut das gleiche und am ende bekommt der Master eine Liste von den Typen aller Knoten. c-hater schrieb: > Das ist schwierig bis unmöglich. Dazu müsste es nämlich einen > Mechanismus geben, der Art und Rolle des Knoten bestimmen kann. Art geht > noch, der Knoten kann ja bei der Anmeldung neben seiner Adresse > announcen, was er ist und was er kann. Dann ist es recht einfach, > gleichartige Nodes zu Gruppen zusammen zu fassen. Aber die Rolle? Woher > soll irgendwer (incl. der Node selber) die denn kennen? Es geht um den Ersatz von ausgefallenen Knoten. Wenn der Knoten ersetzt wird, drückt man am Master einen Knopf um einen neuen Scan zu starten. Bei dem neuen Knoten kann man dann aus dem Statusbyte lesen, dass dieser noch nicht parametriert ist und der Master kann die Parameter vom alten Knoten an dieser Addresse schreiben. Außerdem gibt es doch systeme, die das können. Es gibt da Busse, wo zwar jeder Knoten in hardware eine einzigartige ID hat, aber wo der Master erkennen kann, wenn ein Knoten ausgetauscht wurde und die Parameter des alten knotens auf den neuen Läd. Ich will jetzt nix falsches sagen, aber ich glaub das war entweder ASi, oder Hart. Peter D. schrieb: > Das ist ein häufiges Problem. > Wir haben z.B. ein Gerät mit 16 Steckplätzen, in die z.B. 3,5kV-Module > gesteckt werden können. Natürlich weiß kein Modul, welche Linse es > versorgt. Daher gibt es erstmal eine 4Bit-Slotadresse, mit der die > Haupt-CPU die Module zuordnen kann. > Weiterhin ist im EEPROM der Haupt-CPU der Hardwaretyp hinterlegt, wie > alle Ausgänge verdrahtet und angeschlossen sind, welche aufeinander > floaten usw. Erst dann kann die Steuersoftware alle Module richtig > zuordnen. Ist das bei dir dann nur Teil vom Setup Prozess? Peter D. schrieb: > Ein gleichartiges Problem hat man auch mit 1-Wire Sensoren DS18B20. > Jeder Sensor hat seine eigene Adresse. Damit ist aber noch lange nicht > bekannt, welcher Sensor an welcher Meßstelle montiert ist. Um dieses > Problem zu lösen, gibt es 2 Möglichkeiten. In einer Konfigurationsphase > wird jedem Sensor eine Meßstellennummer zugeordnet. Entweder der Sensor > speichert diese Nummer in seinem EEPROM oder der Master legt eine > Tabelle aller Adressen an, welche Meßstelle ihnen zugeordnet ist. Jap, das muss man bei mir im initialen Setup auch machen. Addition von Knoten mitten im Bus kann ich erkennen, wenn sich Count und die Reihenfoge der Knoten ändern. Dann muss man dem neuen Knoten ja noch immer Parameter geben, daber es sollte kein Problem sein im Master das Mapping der Knoten so zu halten, dass es unabhängig von der automatischen ID ist. Im Setup kann man ja jedem Knoten eine eindeutige ID zuweisen, mit der man dieses Mapping machen kann. Frank K. schrieb: > Ja, und warum nimmst Du das nicht? Der Master braucht nur einen normalen > Ethernet-Controller, und Ethercat Slave Controller gibts zu kaufen: Ich möchte meinen eigenen Bus entwickeln, wieso sollte ich da was fertiges nehmen?
Mein Design stützt sich heftig auf einen intelligenten Master, der im Idealfall ganz viel kann. Mein Master hat eine Liste von allen Kontentypen und deren Settings und kann vorausgesetzt genug Speicher eine Belibige Anzahl an Configs speichern. Der Master kann den Knoten eindeutige IDs zuweisen. Der Master Startet den Scan und weiß welcher Knoten welche Aufgabe erfüllt. Der Master baut ein Abbild der Daten von allen Knoten. Mein geplanter Master ist ein Raspberry PI mit einem Selbstentworfenen Hat, wo ein Raspberry Pi Pico oder ein kleiner FPGA drauf sitzt, der Teile der niederen Funktionen realisiert, denn der Pi hat zwar Rechenleistung satt für meine Anwendung, aber leider keine Möglichkeit die Gpios auf Hardware auszulagern, weswegen ich den pico oder den FPGA hab. Auf dem Pi soll ein Kerneltreiber laufen, um eine Verbindung zum Hat aufzubauen. Die eigentliche Funktion macht ein userspace daemon, der alles an Intelligenz hat. Der Teil ist kein Problem, denn das ist für mich als Informatiker ja mein Ding.
Eigentlich ist das gar kein Bus im eigentlichen Sinne. Dein Konzept funktioniert nur mit einer recht begrenzten Anzahl von Slaves. Wenn das so ist, kann man es so machen. Bei vielen Slaves wird die Frage Ausfall eines Slaves und Hotplug immer relevanter. Da gibt's doch das Konzept Java Bean oder so. Kannste dir mal ansehen. Wenn die Slaves nicht im gleichen Gehäuse/Gerät sitzen, auf jeden Fall galvanische Trennung.
Abdul K. schrieb: > Eigentlich ist das gar kein Bus im eigentlichen Sinne. Dein Konzept > funktioniert nur mit einer recht begrenzten Anzahl von Slaves. Wenn das > so ist, kann man es so machen. Bei vielen Slaves wird die Frage Ausfall > eines Slaves und Hotplug immer relevanter. Wieso sollte es nur mit einer begrenzten Anzahl funktionieren? Es ist auf jeden Fall kein klassicher wo alle Teilnehmeer an einem einzigen Satz Leitungen hängen, aber im Grunde ist es ja nur eine Art ethercat nur ohne Ethernet und mit rs485. Michn hat bei den Bussen Von den SPS systemen Gestürt, dass die zum beilspiel maximal 32 Knoten mit insgesamt 120 Kanälen oder so können, also wollte ich einen Bus bauen, der diese Begrenzung in der Theorie nicht hat und ich weiß, dass die Zykluszeit mit jedem Knoten ein bisschen langsamer wird, aber das kann ich in Kauf nehmen. Bei einem kleinen Test mit Lauter Arduinos und einer manuell verkabelten Vorstufe von meiner enumeration hab ich mit 24Byte Nutzdaten pro knoten und 32 Knoten eine Zykluszeit pro Nachricht von 100ms gemessen. Das klingt für mich doch ganz gut, vor allem wenn ich bedenke dass nur die wenigsten Knoten wirklich 24Byte Nutzdaten haben, die Zyklisch abgefragt werden sollen. In der Praxis, wenn Das von einem Raspi Pico, mit dma und pio, oder einem FPGA gehandhabt wird, denke ich geht das auch noch ein bisschen runter. Abdul K. schrieb: > Wenn die Slaves nicht im gleichen Gehäuse/Gerät sitzen, auf jeden Fall > galvanische Trennung. So war der Plan
Stefan S. schrieb: > Wieso sollte es nur mit einer begrenzten Anzahl funktionieren? Weil Slaves auch mal ausfallen.
Stefan S. schrieb: > Das klingt für mich doch ganz gut, vor allem wenn ich bedenke > dass nur die wenigsten Knoten wirklich 24Byte Nutzdaten haben, die > Zyklisch abgefragt werden sollen. Warum will man mit so einem "Bus" noch zyklisch abfragen? Man muss ja nicht so harte Worte wie "Multi-Master" verwenden, aber das Ding ist kollisions*frei*, das sollte man nutzen. Ausgefallene Knoten könnte man mit einem Relais automatisch überbrücken, zumindest bei manchen Fehlerursachen. In dem Zusammenhang sollte man auch nochmal einen Ring in Erwägung ziehen, der spart nämlich Relaiskontakte ;) Ja, ein Ring kostet ein langes Kabel mehr, aber man spart ein Aderpaar und in jedem Knoten einen Transceiver. Alle Knoten wären gleich, die Unterscheidung letzter-in-der-Kette entfällt. Die Stromversorgung könnte (sollte) von beiden Enden eingespeist werden. Vielleicht kann man sogar entscheiden, ob eine Unterbrechung einer Kette oder eines Rings schlimmere Folgen hat. Lokalisieren lässt sie sich in beiden Fällen ziemlich einfach.
Bauform B. schrieb: > Ausgefallene Knoten könnte man mit einem Relais automatisch überbrücken, > zumindest bei manchen Fehlerursachen. In dem Zusammenhang sollte man > auch nochmal einen Ring in Erwägung ziehen, der spart nämlich > Relaiskontakte ;) Sowas hatte ich vor, zumindest hab ich es mir überlegt, nachdem ich meinen Original Post geschrieben hatte. Mein erster Plan war, dass die Kommunikation immer von einem dedizierten Mikrocontroller, oder FPGA übernommen wird und dass dieser via PoB immer mit Strom versorgt wird das mit dem Umschalten tun kann. Dann müsste der halt nur noch von den eigentlichen Knoten galvanisch getrennt werden und alles wäre gut. Bauform B. schrieb: > Warum will man mit so einem "Bus" noch zyklisch abfragen? Man muss ja > nicht so harte Worte wie "Multi-Master" verwenden, aber das Ding ist > kollisions*frei*, das sollte man nutzen. Die Zyklische Abfrage ist auch ein Weg, damit der Master regelmäßig Daten an die Clients schickt und variiert in seiner Frequenz. Damit sich mein Master grundsätzlich ein bisschen vereinfacht, hab ich mir überlegt, dass es nur zwei arten von Nachrichten geben soll. Alerts - Requests, deren ID der Master nach dem Startup mal festgelegt hat Requests - Requests haben eine ID, die der Master Festlegt und wo der Master darauf wartet, dass eine Nachricht mit dieser ID rein kommt. Der Master soll entweder alle 60 Sekunden einen Status Request starten, indem ein Allgemeiner Status der Knoten angefragt wird, zum Beispiel um Sensoren Abzufragen die Momentan nicht mit Logik aktiv benutzt werden, zu schauen ob der Bus noch intakt ist, ob die Knoten noch alle antworten und um zum Beispiel neue Configs zu pushen. Alles wo Logik dran hängt, bekommt einen eigenen Alert, der bei einer Änderung den Slave sofort einen anfrage losschicken lässt. Bauform B. schrieb: > Ja, ein Ring kostet ein langes Kabel mehr, aber man spart ein Aderpaar > und in jedem Knoten einen Transceiver. Alle Knoten wären gleich, die > Unterscheidung letzter-in-der-Kette entfällt. Die Stromversorgung könnte > (sollte) von beiden Enden eingespeist werden. Ich hatte mir das überlegt, dass der Ring bei bedarf auch physisch auf einem Kabel liegen kann, damit ich mir - Sollte ich mir das überlegen - auch Knoten bauen kann, die auf einer Hutschiene sitzen und es wäre doof, wenn man dann ein Kabel parallel legen muss. Oder damit man bei bedarf einfach einen Stich legen kann, ohne zwei kabel ziehen zu müssen. Dann würde es ja im zweifel reichen, wenn irgenwo schon ein CAT-Kabel liegt... Bauform B. schrieb: > Vielleicht kann man sogar entscheiden, ob eine Unterbrechung einer Kette > oder eines Rings schlimmere Folgen hat. Lokalisieren lässt sie sich in > beiden Fällen ziemlich einfach. Ich bin mir grad nicht sicher, dass wir vom selben reden, aber jap, das wäre kein relativ einfach möglich.
Stefan S. schrieb: > Bei einem kleinen Test mit Lauter Arduinos und einer manuell verkabelten > Vorstufe von meiner enumeration hab ich mit 24Byte Nutzdaten pro knoten > und 32 Knoten eine Zykluszeit pro Nachricht von 100ms gemessen. Das > klingt für mich doch ganz gut Damit kannst du bestenfalls schnarchlangsame Lichttaster abfragen oder Temperaturen übertragen. Für richtige Steuerungstechnik ist so ein Bus nutzlos. Stefan S. schrieb: > Der Master soll entweder alle 60 Sekunden einen Status Request starten Wofür soll ein Bus mit derartig langsamen Reaktionszeiten brauchbar sein? Im normalen Leben ist nach 60 Sekunden die Welt untergegangen. Bei uns kommt nach 6ms eine Fehlermeldung und nach 10ms werden die Antriebe angehalten (also 10000mal schneller als dein Plan). Stefan S. schrieb: > hatte mich deshalb ein bisschen auf Ethercat gestützt. Ethercat macht > ja ein ähnliches Daisychaining mit einem Loop, um große Datenmengen in > echtzeit austauschen zu können. So wie ich das sehe, hast du EtherCAT nicht verstanden. Denn da sendet nicht 1 Master 1 Telegramm zu 1 Slave, der es dann empfängt, verarbeitet und weitersendet, sondern der Slave lässt das Telegramm "an sich vorbeirauschen" und pickt dann die Bits raus, die ihn angehen und setzt dort seine Daten ein, wo der Platz dafür ist. Je nach Bus- und Telegrammlänge kann es sein, dass der Master den Anfang des Telegramms, das er gerade eben sendet, schon wieder empfängt. Die Aufgabe des EtherCAT Slaves ist also eine sehr zeitkritische und deshalb verwendet der Slave ein eigens entwickeltes ASIC dafür. Und das Überraschendste: der EtherCAT hat zwar eine Ringarchitektur, aber davon sieht man von aussen nichts, weil über das selbe Kabel, durch das der "Hinweg" zu einem Slave realisiert wir, auch der "Rückweg" zum vorhergehenden Busknoten realisiert wird. Deshalb kann jeder Slave den Ring wieder schließen, wenn die Kette "hinter ihm" unterbrochen ist. Stefan S. schrieb: > Leider sind die ganzen Rückwandbusse von den SPS-Systemen alle > Proprietär und deshalb nicht zugänglich. Diese Busse können ganz viel > von dem was ich will. Beckhoff verwendet EtherCAT auch auf der Backplane. Nur eben nicht mit Übertragern, sondern mit LVDS-Pegeln. Stefan S. schrieb: > Frank K. schrieb: >> Ja, und warum nimmst Du das nicht? Der Master braucht nur einen normalen >> Ethernet-Controller, und Ethercat Slave Controller gibts zu kaufen: > Ich möchte meinen eigenen Bus entwickeln, wieso sollte ich da was > fertiges nehmen? "Ich will" und "ich möchte" sind aus Erfahrung ganz schlechte Vorgaben. Die Praxis hat gezeigt: wenn es etwas gibt, die nötige Funktion übernehmen kann und erprobt ist, dann nimm das. Es geht schneller, es ist billiger und es läuft. Du wirst nicht glauben, wie viele schon ihre eigenen Bussysteme entwickeln wollten. Ich hatte auch mal so eine Idee. Es war bei weitem nicht die Beste, die ich hatte. Mein Tipp: beschreibe dein Problem mal mit "ich brauche". Aber mit realistischen Vorgaben. Denn du "brauchst" keine Stromversorgung über den Bus, wenn das angeschlossene Gerät sowieso ein Netzteil bekommt. Und wenn dann noch 2 Teilnehmer zusätzlich zum Bus noch Strom brauchen, dann leg halt eine zweite Leitung dorthin. Meinen Hinweis auf die zigzehntausend Ingenieursstunden, die in einem funktionierenden Bussystem stecken, hast du gesehen, gelesen und vor allem: du hast ihn verstanden? Denn du machst dir hier Gedanken um alle Layer des ISO/OSI-Modells. Gleichzeitig. Das wird nix, es ist zu viel für 1 alleine. Andere Ingenieure arbeiten ganztags allein daran, die physikalische Busankopplung störfest, stabil und fehlertolerant hinzubekommen. Stefan S. schrieb: > Ansonsten freue ich mich sehr wenn ihr mir interessante oder exotische > Busse nennt, damit ich ein bisschen mehr stöbern kann. Exotisch? Kennst du SerCos? Da hat in einem Frame, der z.B. 2ms dauert, jeder der angeschlossenen Slaves seinen eigenen kurzen Zeitschlitz von z.B. 50µs, in den er seine Daten hineinpacken kann. Und das geht tatsächlich "bitgenau" vor sich. Die Verzögerung Im Ring vom Master-TX bis zum Master-RX sind bestenfalls ein paar µs (die Lichtgeschwindigkeit ist ja 300m/µs plus pro Slave ein paar 64MHz-Takte Verzögerung im ASIC). Früher (Sercos I und II) lief das optisch über Plastik-LWL ab, heute (Sercos III) wie die anderen derzeit üblichen Busse über Ethernet-Hardware.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Stefan S. schrieb: >> Bei einem kleinen Test mit Lauter Arduinos und einer manuell verkabelten >> Vorstufe von meiner enumeration hab ich mit 24Byte Nutzdaten pro knoten >> und 32 Knoten eine Zykluszeit pro Nachricht von 100ms gemessen. Das >> klingt für mich doch ganz gut > Damit kannst du bestenfalls schnarchlangsame Lichttaster abfragen oder > Temperaturen übertragen. Für richtige Steuerungstechnik ist so ein Bus > nutzlos. Das glaub ich nicht, da ich ja erstmal nur eine relativ naive Umsetung habe, bei der ich bestimmt noch viel mehr Geschwindigkeit rausholen kann. War ja nur ein kleiner Test um zu schauen ob mein Grundkonzept funktioniert. Lothar M. schrieb: > Stefan S. schrieb: >> hatte mich deshalb ein bisschen auf Ethercat gestützt. Ethercat macht >> ja ein ähnliches Daisychaining mit einem Loop, um große Datenmengen in >> echtzeit austauschen zu können. > So wie ich das sehe, hast du EtherCAT nicht verstanden. Denn da sendet > nicht 1 Master 1 Telegramm zu 1 Slave, der es dann empfängt, verarbeitet > und weitersendet, sondern der Slave lässt das Telegramm "an sich > vorbeirauschen" und pickt dann die Bits raus, die ihn angehen und setzt > dort seine Daten ein, wo der Platz dafür ist. Je nach Bus- und > Telegrammlänge kann es sein, dass der Master den Anfang des Telegramms, > das er gerade eben sendet, schon wieder empfängt. Die Aufgabe des > EtherCAT Slaves ist also eine sehr zeitkritische und deshalb verwendet > der Slave ein eigens entwickeltes ASIC dafür. Jap, das hab ich schon verstanden, aber ich hab es in meinem kleinen Test noch nicht so umgesetzt. Das finale System soll das so tun. Lothar M. schrieb: > Und das Überraschendste: der EtherCAT hat zwar eine Ringarchitektur, > aber davon sieht man von aussen nichts, weil über das selbe Kabel, durch > das der "Hinweg" zu einem Slave realisiert wir, auch der "Rückweg" zum > vorhergehenden Busknoten realisiert wird. Deshalb kann jeder Slave den > Ring wieder schließen, wenn die Kette "hinter ihm" unterbrochen ist. Auch das war so von mir vorgesehen! Deswegen will ich ja LoS erkennung haben, damit ich feststellen kann, ob der Ring unterbrochen ist. Lothar M. schrieb: > Stefan S. schrieb: >> Frank K. schrieb: >>> Ja, und warum nimmst Du das nicht? Der Master braucht nur einen normalen >>> Ethernet-Controller, und Ethercat Slave Controller gibts zu kaufen: >> Ich möchte meinen eigenen Bus entwickeln, wieso sollte ich da was >> fertiges nehmen? > "Ich will" und "ich möchte" sind aus Erfahrung ganz schlechte Vorgaben. > Die Praxis hat gezeigt: wenn es etwas gibt, die nötige Funktion > übernehmen kann und erprobt ist, dann nimm das. Es geht schneller, es > ist billiger und es läuft. Mir geht es wie schon mehrfach erwähnt hauptsächlich darum den Designprozess von einem Bussystem nachvollziehen zu können. Lothar M. schrieb: > Du wirst nicht glauben, wie viele schon ihre eigenen Bussysteme > entwickeln wollten. Ich hatte auch mal so eine Idee. Es war bei weitem > nicht die Beste, die ich hatte. Das glaub ich und ich vermute mal, dass ich in ein paar monaten auch angekrochen komme und zugebe dass das eine kack Idee war! Aber ich möchte das ja zum Lernen machen. Lothar M. schrieb: > Mein Tipp: beschreibe dein Problem mal mit "ich brauche". Aber mit > realistischen Vorgaben. Denn du "brauchst" keine Stromversorgung über > den Bus, wenn das angeschlossene Gerät sowieso ein Netzteil bekommt. Und > wenn dann noch 2 Teilnehmer zusätzlich zum Bus noch Strom brauchen, dann > leg halt eine zweite Leitung dorthin. Sehr guter Hinweis, aber ich bin ja momentan noch in der Phase wo ich meine "Ich brauche" Vorgaben formuliere. Lothar M. schrieb: > Meinen Hinweis auf die zigzehntausend Ingenieursstunden, die in einem > funktionierenden Bussystem stecken, hast du gesehen, gelesen und vor > allem: du hast ihn verstanden? Ja habe ich! Ich werde es aber trotzdem tun. Lothar M. schrieb: > Denn du machst dir hier Gedanken um alle Layer des ISO/OSI-Modells. > Gleichzeitig. Das wird nix, es ist zu viel für 1 alleine. Andere > Ingenieure arbeiten ganztags allein daran, die physikalische > Busankopplung störfest, stabil und fehlertolerant hinzubekommen. Ich hab angefangen mir über Layer 6 und 7 zuerst gedanken zu machen und schaue nach und nach die Layer runter, was ich brauche um meine oberen Layer 7 features möglicht einfach umsetzen zu können. Lothar M. schrieb: > Stefan S. schrieb: >> Ansonsten freue ich mich sehr wenn ihr mir interessante oder exotische >> Busse nennt, damit ich ein bisschen mehr stöbern kann. > Exotisch? Kennst du SerCos? Da hat in einem Frame, der z.B. 2ms dauert, > jeder der angeschlossenen Slaves seinen eigenen kurzen Zeitschlitz von > z.B. 50µs, in den er seine Daten hineinpacken kann. Und das geht > tatsächlich "bitgenau" vor sich. Die Verzögerung Im Ring vom Master-TX > bis zum Master-RX sind bestenfalls ein paar µs (die Lichtgeschwindigkeit > ist ja 300m/µs plus pro Slave ein paar 64MHz-Takte Verzögerung im ASIC). > Früher (Sercos I und II) lief das optisch über Plastik-LWL ab, heute > (Sercos III) wie die anderen derzeit üblichen Busse über > Ethernet-Hardware. Hab ich mir angeschaut, konnte aber keine ausreichende Doku finden. Wenn du da also was hast, schau ich mir das auch gern an.
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.