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.
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 übertragenStefanus 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.
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. :-)
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.
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.
