Hallo! Für die Konstruktion einer Steuerung, ähnlich einer SPS, stellt sich die Frage, welches Bussystem für die Kommunikation der Eingangs- und Ausgangsbaugruppen mit der CPU empfehlenswert ist. Es soll ein reines Hobby-Projekt zum Spaß und zur Übung sein, nichts kommerzielles, trotzdem habe ich den Anspruch an eine gewisse Zuverlässigkeit, insbesondere die Störfestigkeit betreffend. Auch eine Echtzeitfähigkeit sollte gegeben sein, zumindest soweit, dass das Verhalten vorhersehbar ist. Die CPU soll alleine den Datenverkehr steuern. Als Betriebssystem kommt für mich FreeRTOS in Betracht. Es sollen ausschließlich digitale und analoge I/O-Baugruppen Verwendung finden. Nichts mit außergewöhnlich hohen Datenraten. Ansatz 1: SPI im Ring. Soweit ich richtig informiert bin, wurde bei der Simatic S5 ein Ring verwendet, so dass alle Daten durch sämtliche Schieberegister der Busmodule geschoben wurden. Ob das SPI war oder etwas anderes, weiß ich aber in diesem Fall nicht. (Vielleicht weiß das ja hier jemand) Vorteile aus meiner Sichtweise ist, dass immer erkannt werden kann, ob sämtliche Busteilnehmer vorhanden sind oder eine Unterbrechung vorliegt, sowie die fehlende Notwendigkeit der Adressierung. Über den Bus der S7 bin ich leider nicht informiert. Ansatz 2: Die Datenübertragung über SPI jeweils separat mittels Chip-Select. Setzt natürlich voraus, dass die Anzahl der Busteilnehmer vorher bekannt ist, außerdem ist die Anzahl der Teilnehmer durch die Zahl der Chip-Select-Signale begrenzt. Einfach Adressierung, aber notwendig. Ansatz 3: Verwendung von I2C. Allerdings könnte die Adressierung problematisch werden. Ansatz 4: RS485, setzt ausgefeiltes Protokoll voraus, ebenfalls Anspruch an eindeutige Adressierung. Ansatz 5: CAN-Bus. Allerdings bin ich mir da noch nicht ganz sicher, ob das wirklich geeignet ist für eine SPS. Komplizierte Adressierung, würde das Steckplatz = E/A-Adresse-Prinzip verwerfen. Wahrscheinlich unter diesem Aspekt nicht zu empfehlen.
Zwei entscheidende Details fehlen, die zur Entscheidungsfindung wichtig sind: - Die benötigte Geschwindigkeit. In welchem Zyklus müssen Eingänge abgetastet und Werte an Ausgänge ausgegeben werden können? Wenn die SPS zur Steuerung einer Werkzeugmaschine eingesetzt werden soll, wird dieser Zyklus deutlich schneller ablaufen, als wenn damit z.B. eine Heizungsanlage gesteuert werden soll, weil deren Regelprozesse erheblich träger sind. - Die Datenmenge. Um wieviele Ein-/Ausgänge geht es, die die SPS ansteuern soll?
... zum Spaß und zur Übung Hmmm... einfacher wäre ja ein MC mit ausreichend Pins, Timern und ADCs. Die IO-Module kümmern sich nur um Leistung und EMV. Aber wenn es dir mir einem 8Pin MC, ewig langem Schieberegister und externen ADCs mehr Spass macht - ignoriere alle Ratschläge!
Stimmt. Ich denke momentan über 8 Baugruppen nach, die jeweils 8 Ein- oder Ausgänge abfragen bzw. steuern. Bei der Analogbaugruppe werden es dann 8 x 10 bit. Das wird die Zykluszeit natürlich erheblich verlängern, darüber bin ich mir im Klaren. Wenn ich von 8 Digitalen Baugruppen mit jeweils 8 I/O's ausgehe, sollte eine Zykluszeit von 5 ms ausreichend sein. Das wären dann (ohne Protokoll-Overhead und Prüfsummen) 200 x 64 bit = 12800 bit/sec. Also nicht sehr viel. Prüfsummen und Protokoll benötigen natürlich ebenfalls Buskapazität.
Ignoriere alle Ratschläge schrieb: > Hmmm... einfacher wäre ja ein MC mit ausreichend Pins, Timern und ADCs. Ich mag es gerne sportlich.
Üblich sind RS485 oder Ethernet z.B. https://revolution.kunbus.de/blog/pibridge/ Astra Lavista schrieb: > RS485, setzt ausgefeiltes Protokoll voraus, ebenfalls Anspruch > an eindeutige Adressierung Kannst ja erst mal MODBUS RTU nehmen.
Wenn I²C genügt, würde ich das nehmen. Für die Adressierung kannst du die Module ja mit Dip-Schaltern oder Steckbrücken ausstatten.
Astra Lavista schrieb: > Die CPU soll alleine den Datenverkehr steuern. Damit wäre ich bei RS485. Mit nur einem master immer gut. Einfach, billig und robust. Datenrate rel. hoch.
H.Joachim S. schrieb: > Damit wäre ich bei RS485. > Mit nur einem master immer gut. Einfach, billig und robust. Datenrate > rel. hoch. Gutes Argument, benötigt halt ein Protokoll und die Teilnehmer eine eindeutige Adresse, die idealerweise beim Einschalten festgelegt wird. Wie sieht denn die Störfestigkeit bei SPI aus? Welche Mechanismen nutzt man da üblicherweise zur Fehlererkennung bzw. Korrektur?
Astra Lavista schrieb: > Wie sieht denn die Störfestigkeit bei SPI aus? Welche Mechanismen nutzt > man da üblicherweise zur Fehlererkennung bzw. Korrektur? Ich glaube, man geht normalerweise davon aus, dass niemals Störungen auftreten. SPI ist nicht dafür gedacht, die Platine zu verlassen.
Astra Lavista schrieb: > Wie sieht denn die Störfestigkeit bei SPI aus? Welche Mechanismen nutzt > man da üblicherweise zur Fehlererkennung bzw. Korrektur? SPI kann man genauso über RS422 Signalisierug übertragen, je nach verwendeten Treiberchips kann man da mehrere hundert Meter überbrücken und eventuell auch hohe Baudraten verwenden. Wenn die Komponenten aber direkt zusammengesteckt werden und man nicht allzu schnell ist wird das nicht nötig sein. Beispiel: Die S7-200 die da rumliegt hat einen 8 Bit Bus und daran angeschlossen Bausteine aus der 74HC Familie. Ein paar Leitungen erledigen über einen PAL die Adressierung, ein Latch oder einen Treiber legt dann die Eingänge auf den Bus bzw. speichert die Ausgänge.
Robert S. schrieb: > SPI kann man genauso über RS422 Signalisierug übertragen Stefanus F. schrieb: > SPI ist nicht dafür gedacht, die Platine zu verlassen. Das klingt jetzt wie ein Widerspruch, aber Robert hat Recht. Ich meinte nämlich "nacktes" SPI, also die direkte Nutzung der IC Pins. Aber man kann das natürlich über entsprechende Treiberbausteine leiten und dann längere Leitungen nutzen, das meinte Robert.
Möchtest Du feste Steckplätze oder anreihbare Module? Möchtest Du im Maximum 100, 1000 oder 10.000 Bit (1 AD-wert über. 16 Bit) Status. Möchtest Du @100 Bit etwa 1, 10 oder 1000 Updates pro Sekunde. Möchtest Du manuelle oder automatische Adressierung Möchtest Du alle Module lokal oder auch per Feldbus (Entfernungen?)
Stefanus F. schrieb: > Wenn I²C genügt, würde ich das nehmen. Niemals! Astra Lavista schrieb: > eine > eindeutige Adresse, die idealerweise beim Einschalten festgelegt wird. Werden die Ein-/Ausgänge auch mit jedem Einschalten neu vergeben? Wohl kaum. Dann nimm eine feste Adresse für jedes Modul. Mit RS485 hast Du viele Freiheiten, den Bus aufzubauen. Im einfachsten Fall geht eine ser. Verbindung per UART und Multiprozessor-Protokoll zur Adressierung. Für kurze Entfernungen passen auch CAN-Bustreiber.
Mir ist nicht ganz klar, warum ihr für interne Verbindungen Sachen wie Ethernet, CAN, RS422 und RS485 empfohlen habt. Wenn ich intern höre, stelle ich mit einen handlichen Kasten vor, in dem alles drin ist. Keine vernetzten Geräte.
Noch nie ne SPS gesehen? Wenn man mal von den Minidingern wie Logo o.ä. absieht: da gibts ne CPU und I/O-Baugruppen.
Es geht aber nicht um eine SPS, sondern
> Für die Konstruktion einer Steuerung, ähnlich einer SPS
Wird Zeit dass der TO mehr Infos rüber wachsen lässt.
H.Joachim S. schrieb: > da gibts ne CPU > und I/O-Baugruppen. Genau, und die gibt es - auf parallelen Steckplätzen (schonmal keine Adressierung ;-) - Anreihbar (beliebig, quasi mit virtuellem Schieberegister) - per (Feldbus-)Kabel angebunden (sternförmig mit Adressierung, P2P ohne, für 10m oder 1000, mit GigaB oder im KBaud-Bereich...) Spätestens bei 100m sternförmig mit 400kBaud ist I2C nicht ohne ;-)
Hallo, ich habe genau sowas für mich schon gebaut. Ein Master und viele Slaves. Alles mittels RS485 verbunden. Läuft mit 250k Baudrate. ICs sind MAX487ECSA. Es gibt noch schnellere. Master ist ein Arduino Mega 2560. Slaves sind Eigenbauplatinen mit ATtiny841. Die Adressen sind in der Software "kodiert". Ich wollte dafür keine Pins verschwenden. Wenn du bei deinen Slave µC Pins frei hast, kannste Jumper für die Adressierung verwenden. Biste noch flexibler. Ob das notwendig ist muss du selbst wissen. Um ein ordentliches Protokoll kommste nicht drumherum. Das ist sowieso Pflicht. Das wirste schon merken. Ich empfehle dir dich erst mit dem Protokoll zu beschäftigen. Wenn das steht und ausreichend getestet ist, kannste alles nach Belieben ausbauen. Es macht keinen Sinn sich jetzt schon mit allen Karten alles aufzubauen und dann am Protokoll und Übertragungsfehler abfangen etc. zu scheitern. Nimm den Master und 2 Slaves und mache dir Gedanken. Für den Ansporn ein kleines Video von meinem Turm. https://www.youtube.com/watch?v=APsHZVKCyIo Wie gesagt das sind alles dumme Slaves. Auch der Oberste der nur Display und Encoder drauf hat. Der dient mir eigentlich als Datenmonitor was auf dem Bus los ist. Man sieht auch wie ich wahllos mittendrin irgendeinen Slave resete. Wenn er danach angesprochen wird, syncronisiert er sich automatisch in Null Komma Nichts und macht was er soll. Sieht man minimal am länger dauernden "Bus LED Feuer", die 3 Leds links. Auch der obige Slave mit Encoder wird vom Master ständig abgefragt und damit die Geschwindigkeit gesteuert. Falls du Multimaster machen möchtest, würde ich CAN empfehlen. Macht dann weniger Probleme mit Buskollisionen.
A. S. schrieb: > H.Joachim S. schrieb: >> da gibts ne CPU >> und I/O-Baugruppen. > > Genau, und die gibt es > - auf parallelen Steckplätzen (schonmal keine Adressierung ;-) Ohne irgendeine Art der Adressierung geht es nicht. Auch wenn man diese nicht sieht muss eine vorhanden sein. Die parallelen Karten müssen gezielt angesprochen werden können. Sonst klappt das nicht.
A. S. schrieb: > Möchtest Du feste Steckplätze oder anreihbare Module? Anreihbare Module, damit ich flexibel bin. A. S. schrieb: > Möchtest Du @100 Bit etwa 1, 10 oder 1000 Updates pro Sekunde. Ehrlich gesagt, ich habe dahingehend keine so genaue Spezifikation. 100 pro Sekunde wären schon ok. A. S. schrieb: > Möchtest Du manuelle oder automatische Adressierung Wenn ein Ausgangsmodul auf Steckplatz 4 gesteckt ist, soll es Adresse 4 bekommen. Ganz klassisch wie bei einer SPS. Wie immer muss man natürlich darauf achten, dass Ausgangsbaugruppe 4 auch tatsächlich vorhanden ist. Wenn ich zwei gleiche Baugruppen tausche, soll das keinen Einfluss haben. A. S. schrieb: > Möchtest Du alle Module lokal oder auch per Feldbus (Entfernungen?) Nur lokal im Gerät. Stefanus F. schrieb: > Wird Zeit dass der TO mehr Infos rüber wachsen lässt. Der Weg ist das Ziel. Einige Festlegungen sind natürlich notwendig, aber momentan bin ich noch mit der Ideenfindung beschäftigt. Wenn die wichtigsten Dinge geklärt sind, kann es losgehen. Veit D. schrieb: > ich habe genau sowas für mich schon gebaut. Sehr interessantes Projekt! Veit D. schrieb: > Master ist ein Arduino Mega 2560 Wird bei mir ein Cortex M4 Veit D. schrieb: > Um ein ordentliches Protokoll kommste nicht drumherum. Das ist sowieso > Pflicht. Das wirste schon merken. Klar. Von der Stange wird es da wohl nichts geben, aber das macht es ja auch spannend. Muss nicht unbedingt MODBUS sein. Veit D. schrieb: > Man sieht auch wie ich wahllos mittendrin irgendeinen > Slave resete. Wenn er danach angesprochen wird, syncronisiert er sich > automatisch in Null Komma Nichts und macht was er soll. Über diesen Vorgang wüsste ich gerne mehr. Wie gehst du softwaretechnisch vor, dass es nicht zu Systemabstürzen kommt? Veit D. schrieb: > Falls du Multimaster machen möchtest, würde ich CAN empfehlen. Macht > dann weniger Probleme mit Buskollisionen. Das schon, nur bin ich mir nicht sicher, was das mit dem Echtzeitverhalten anstellt. Zyklische Abfrage der Reihe nach wäre mir lieber. (Kann man natürlich auch per CAN machen). Ein Bedienteil mit CAN möchte ich allerdings sehr wohl später dort anschließen. Allerdings wird das dann über einen separaten CAN Transceiver geschehen.
Kann ich. :-) Die Slave ATtinys nutzen den internen 8MHz RC, spart 2 Pins. Die sind kalibriert und laufen Temperaturstabil. Allerdings sind die ab Werk für 3,3V kalibriert. Ich lasse alles mit 5V laufen. Die externe Versorgung sind 12V. Nach einschalten oder einem Reset, wenn sich der Slave nicht melden kann oder er Datenmüll empfängt, verfällt er in den Kalibriermodus. Der Master bekommt das mit wenn ein Slave sich nicht melden kann. Dann schickt der Master Kalibrierdatenpakete in Form von mehreren 'U' über die Serielle. Schau die das am Oszi an. :-) Damit korrigiert der Slave Schritt für Schritt sein RC Kalibrierregister bis sein Takt im festgelegten Toleranzfenster liegt. Damit haben die Slaves so wenig wie möglich Taktabweichungen zum Master, dann kann man sicher sein das hohe Baudraten kein Problem darstellen. Wenn alle mit Quarz arbeiten könnte man sich das schenken. Aber die Herausforderung und der Erfolg das es wirklich funktioniert sind unbezahlbar. Wie das alles abläuft dafür gibts von Atmel eine App Note. Paar Tipps gabs dann noch aus dem Forum hier. Das der Master und/oder Slave bemerkt das die Übertragung fehlerhaft ist, ja dass steht und fällt mit dem Protokoll und dessen Fehlerbehandlung. Wenn irgendwas fehlt, Startkennung, Adresskennung, Endekennung, CRC Check falsch, Anzahl der Bytes falsch, dann wird das Paket verwurfen und der Master muss neu senden. Das macht meiner mittels Timeout bei fehlender Antwort maximal 5x. Der Master lässt sich sein Paket als Antwort zurückkommen. Entweder 1:1 oder mit den angefragten Daten drin. Das Protokoll ist immer gleich groß. Wenn wie gesagt nichts oder Müll zurückkommt, dann geht er in den Kalibriermodus. Falls das seitens des Master eine Fehlinterpretation war, warum auch immer, spätestens dann geht auch der Slave in den Kalibriermodus, weil die 'U's aus seiner Sicht ja Datenmüll ist. Das fängt sich das sozusagen von alleine wieder. Daran muss man tüfteln und habe ich lange getüftelt. Mit der Syncronisierungsgeschichte habe ich begonnen. Erst als das lief wurde es ausgebaut. Ich könnte jetzt theoretisch bis zu 127 Slaves anklemmen. Die RS485 Leitung sind 2 verdrillte Drähte. Zum Netzwerkkabel wurde mir gesagt das wäre Overkill und sie hatten Recht, die Leute hier aus dem Forum. Wegen Multimaster. Ja das ist schwieriger zu implementieren, wobei eben die CAN Bausteine vieles davon in Hardware abfangen würden. Mir reicht ein Master völlig zu. Senden, quittieren lassen, zum Nächsten ... die Zeiten sind berechenbar. Es ist auch einfacher aufzubauen. Bis dahin lauern genügend Fallstricke. :-)
@Veit: Kannst Du über Deinen Bus auch ein Firmwareupdate auf den Slaves machen?
Astra Lavista schrieb: > Anreihbare Module, damit ich flexibel bin. Meinte ich eigentlich etwas anderes als Astra Lavista schrieb: > auf Steckplatz 4 gesteckt i Anreihbare: das erste steckt an der SPS, das zweite am ersten, das dritte am zweiten. Beliebig viele möglich, keine Busplatine (oder Steckerplatine) Wenn Du aber Steckplätze hast, dann ist alles easy: VCC,Gnd und R/TX reichen praktisch aus, gerne noch ein paar weitere Leitungen für Trigger in beide Richtungen. RX und TX einfach über einen multiplexer an jeden Steckplatz führen. Dann kann die SPS so lange exclusiv mit jedem quatschen, wie sie will. Mit mehr Erfahrung kann man das verbessern (mehrere uarts parallel, multiplexer mit Broadcast, Handshake, RX und TX getrennt multiplexen, ...) Das ist aber meist nicht notwendig, dann lieber Bausrate 1MBaud statt 115k2.
Im Bahnbereich hat sich der MVB bewährt. https://de.wikipedia.org/wiki/Multifunction_Vehicle_Bus Der AMIGA 2000 hatte einen selbstkonfigurierende Zorro-Bus wo Karten beliebig gesteckt werden konnten.
Bernd schrieb: > @Veit: > Kannst Du über Deinen Bus auch ein Firmwareupdate auf den Slaves machen? Das Feature ist leider nicht enthalten. Sollte man sich vielleicht einmal schlau machen. Ich weiß nur das es dafür eine Basis hier im Forum von Peter Dannegger dafür gibt. Allerdings gehört dann noch mehr dazu. Sinnvoll wäre das auf jeden Fall.
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.