The Industrial Raspberry Pi Forum

Kann Kunbus schon Aussagen darüber machen, ab welchem Zeitpunkt man mit einem RevPi bzw. RevPi-Verbund eine Größere Anlage realisieren kann?
Mit sagen wir mal

• 100 Digitale Eingängen
• 100 Digitale Ausgängen
• 30 Analoge Eingänge
• 30 Analoge Ausgänge
• 2-3 Feldbusse als Master

Ich glaub, ich hab mal wo gelesen, man kann nur max. 10 IO-Module per PiBridge anschließen. Woher kommt diese Begrenzung? Sind diese mit oder ohne Bus-Gateways? Gibt es schon die Möglichkeit, 2 RevPis miteinander zu verbinden? Dem Schaltplan kann man entnehmen, dass die PiBridge den Signalrichtungen entsprechend dies zulassen würde (zumindest die Ethernet-Verbindung).

Wie Du schon richtig erkannt hast, wurde von uns die PiBridge mit maximal 10 IO-Modulen spezifiziert. Der Grund liegt in EMV Grenzen, die bei mehr Modulen keinen störungsfreien Betrieb unter EN61131-2 Bedingungen mehr ermöglichen. Die von Dir angefragte Konfiguration wäre daher mit 7 DIOs (=98 Inputs und 98 outputs) und 3 AIOs (12 analoge Eingänge und 6 analoge Ausgänge) sowie zwei sw Masterstacks (Modbus RTU + ProfiNet) nicht perfekt aber doch wohl schon "groß" machbar. Aber ganz generell würden wir sicher zu so einem Ausbau nicht raten. Das ist eine Anlage für eine ausgewachsene Steuerung, keine "Kleinsteuerung". Das Laufzeitverhalten mit solchen Ausbauten würde die PiBridge so stark auslasten, dass die Zykluszeiten relativ uninteressant für viele Anwendungen werden. Ich sehe eigentlich auch nicht wirklich den typischen Anwendungsfall, wo bei einer solchen Konfiguration der RevPi Vorteile gegenüber z.B einer Beckhoff oder S7 haben sollte. Finanziell können die Gründe da ja eigentlich schon nicht mehr sein und die freie Programmierbbarkeit außerhalb der EN61131-3 Sprachen sollte bei solchen PLC Systemem ja auch eher weniger Sinn machen. Oder übersehe ich da etwas?

Nachtrag:
NEIN die PiBridge ist absolut ungeeignet für die Kopplung von zwei RevPi Core. Das Protokoll auf der PiBridge ist Master/Slave orientiert und ein RevPi Core ist immer master und kann nur mit slaves kommunizieren.
Wenn Du statt PiControll die Kommunikation über die PiBridge komplett selber programmieren willst, dann würde die HW eine Kopplung prinzipiell zulassen.

Lieber Volker,

ersteinmal möchte ich dir hier mal danken für deine vielzähligen Beiträge und kompetenten Antworten, so stellt man sich Support vor.

Aber ganz generell würden wir sicher zu so einem Ausbau nicht raten. Das ist eine Anlage für eine ausgewachsene Steuerung, keine "Kleinsteuerung".

Mir war bisher nicht bewusst, dass der RevPi als Kleinsteuerung angepriesen wird. Zur Not könnte man doch einen RevPi-Verbund über Ethernet realisieren - gibt es hierzu Messungen der Laufzeit bzw. Echtzeitfähigkeit?

sowie zwei sw Masterstacks (Modbus RTU + ProfiNet)

Heißt das, Modbus und ProfiNet werden die ersten Master-Module werden? Oder steht "sw" hier für Software, und als Hardware werden dann welche Ports verwendet? RS485 über USB und ProfiNet über den Ethernet-Port?

Das Laufzeitverhalten mit solchen Ausbauten würde die PiBridge so stark auslasten, dass die Zykluszeiten relativ uninteressant für viele Anwendungen werden.

Gibt es hierfür Abschätzungsmöglichkeiten? Bisher hatte ich nur mal von 5ms gelesen, wenn 512 Bytes von einer Bridge übertragen werden..

...wo bei einer solchen Konfiguration der RevPi Vorteile gegenüber...

Ich komme aus der Elektronik- und embedded Software-Entwicklung. PC-Programmierung in C, C++ und Java gehören auch dazu.
Mir ist ST z.B. komplett fremd, und in einer solchen Sprache fühle ich mich vermutlich recht eingeschränkt. Wobei eine Implementierung in einer genormten Sprache sicherlich auch Vorteile mit sich bringt. Schreibt man einen C++ Code jedoch sauber, mit einer entsprechenden Doku, kann sich auch hier jeder Programmierer schnell zurechtfinden - vor allem dann, wenn man sich auf das Niveau von ST begibt, dann reicht vermutlich auch C. Es kann aber auch sein, dass ich den scheinbar großen Vorteil von ST einfach noch nicht verstanden habe, abgesehen von der Verbreitung, die aber C und C++ auch haben.

Wenn ich meinen RevPi erhalten habe, dann werde ich mir LogiCAD mal anschauen, und gucken, ob ich mir vorstellen könnte, damit eine größere Steuerung zu machen.

Ich bin auch großer Freund freier Systeme, und Arbeite seit einigen Jahren auf Linux - mit großer Freude. Da würde der RevPi perfekt dazupassen.

KarlZeilhofer wrote:Mir ist ST z.B. komplett fremd, und in einer solchen Sprache fühle ich mich vermutlich recht eingeschränkt. Wobei eine Implementierung in einer genormten Sprache sicherlich auch Vorteile mit sich bringt. Schreibt man einen C++ Code jedoch sauber, mit einer entsprechenden Doku, kann sich auch hier jeder Programmierer schnell zurechtfinden - vor allem dann, wenn man sich auf das Niveau von ST begibt, dann reicht vermutlich auch C. Es kann aber auch sein, dass ich den scheinbar großen Vorteil von ST einfach noch nicht verstanden habe, abgesehen von der Verbreitung, die aber C und C++ auch haben.

Meine Einschätzung als ST Anfänger: Einschränkungen wie es sie z.B. bei ST gibt, können schon von Vorteil sein. So kann man z.B. die Sprache sehr schnell lernen und man muss sich um sehr wenig kümmern. (Kommt einem dann in etwa so vor, als würde man Basic lernen)
Ein weiterer Unterschied zu einer klassischen Programmiersprache ist, dass das EVA Prinzip strikt befolgt wird. Wenn man irgendwo in seinem ST Programm auf einen Eingang zugreift, kann man sich sicher sein, das dieser Eingang überall im Programm den selben Wert hat, der am Anfang eines Zyklus eingelesen wurde. Kann man zwar in einer Hochsprache auch alles nachbilden, aber wir alle wissen was man mit Regeln macht: man bricht sie irgendwann, wenn einen das System nicht daran hindert.
Es hindert dich jedoch auch niemand daran den Pi mit einer Programmiersprache deiner Wahl zu programmieren.

Das Einzige was ich bislang richtig vermisse (oder nur noch nicht gefunden habe), ist die Möglichkeit von automatisierten Programmtests, um die Zustände der Ein- und Ausgänge in Abhängigkeit voneinander gegen eine Vorlage/Vorgabe prüfen lassen zu können.

Wow, das sind jetzt richtig viele Fragen und Themen auf einmal.
ich versuche das mal Punkt für Punkt abzuarbeiten:

1) Ja, wir haben immer von einer insudtriellen "kleinsteuerung" gepsrochen, weil die Rechenleistung und die Einschränkungen, die durch das CM gegeben sind, kein Motion controlling zulassen und die Ausbaufähigkeiten zumindest aktuell nicht das Maß einer ausgewachsenen PLC erreichen.

2)

Zur Not könnte man doch einen RevPi-Verbund über Ethernet realisieren - gibt es hierzu Messungen der Laufzeit bzw. Echtzeitfähigkeit?

Ja man kann natürlich Systeme koppeln. Technisch ist das alles machbar. Aber hier ist dann die EN61131-3 nicht mehr hilfreich, weil dort verteile Systeme nicht berücksichtigt sind und eine zyklische Abarbeitung mit Pollen bei verteilen Systemen ja noch viel größere Probleme mit sich bringen würde. Das macht erst richtig Sinn, wenn man Event basiert verarbeitet. Aber das kommt schon noch alles

3)

Heißt das, Modbus und ProfiNet werden die ersten Master-Module werden? Oder steht "sw" hier für Software, und als Hardware werden dann welche Ports verwendet? RS485 über USB und ProfiNet über den Ethernet-Port?

"sw" und "stack" stehen hier in der Tat für reine Software Lösungen. Wenn wir von "Modul" sprechen, meinen wir in der Regel Hardware: Hutschienengehäuse zum Anreihen an den Core. Softwarestacks hingegen laufen auf dem Core als Treiber bzw "Softwaremodule". Beim PiCtory sprechen wir daher neutral von "Adaptern", wenn es Soft- oder Hardware Module sein können. ProfiNet wird die RJ45 vom Core nutzen, Modbus TCP ebenso. Modbus RTU dann einen USB auf RJ485 Umsetzer.

4)

Gibt es hierfür Abschätzungsmöglichkeiten?

Das ist hoch komplex. Letztlich tauschen die DIO, Di und DO Ihre Daten zyklisch über RS485 aus, wobei die Raspi UART leider nur 115kbit erlaubt. Wir fahren ein extrem schlankes Protokoll mit fast nur Payload. Trotzdem ist hier der Bottelneck: Wenn man zu viele Zähler oder PWM konfiguriert, werden extrem viele zyklische Daten übertragen und dann wächst dadurch die Zykluszeit auf der Backplane.Bei den Gateways dürfte das kein Problem sein, denn die nutzen die Ethernetkanäle. Diese sind aber bei einem Raspi auch nur über SPI in die CPU zu transportieren, deren Takt leider auch begrenzt ist (daher die 5 ms Angabe).
Die Übertrgaungszeitne sind extrem von der Konfiguration abhängig und daher kaum exakt zu bechreiben. Am leichtesten ist hier wirklich der Versuch.

5) ST / freie Systeme
ich kann Deine Sicht und Deine Visionen sehr gut nachvollziehen. Wir beobachten aktuell einen trend der jungen Ingenuere weg von den EN61131 Spachen und hin zur nativen Programmierung in den modernen Hochsprachen. Und JA, WENN man sauber programmiert, dann läuft einen Anlage genauso sicher, wie unter ST, FUB oder Ladder. Aber die EN61131-3 ist so ausgelegt worden, dass der Determinismus in einem Programm relativ einfach nachgewiesen werden kann. Bei C und auch den objektorientierten Sprachen ist dies nur dann der Fall, wenn man sich bestimmten Einschränkungen unterwirft (z.B. MISRA) und selbst dann sind nicht unter allen Bedingungen initialisierte Objekte zum Beispiel eine sehr schwer zu erkennende Fehlerursache. IM Anlagenbau haben sich daher die EN61131-3 Sprachen durchgesetzt, vor allem weil ein suaberer zyklischer Ablauf immer erzwungen wird (und von PLCs auch überwacht wird).

6) Ich freue mich, mit Dir einen Freund freier Systeme hier im Forum zu haben. Das ist letztlich eine wesentliche Säule unserer "Revolution" und grade auf der embedded world in Nürnberg hatte ich am Conrad-Stand zwei Vorträge gehalten, bei denen es im keern um genau diese Freiheit geht, die uns aus den Fesseln der prorietären Systeme herauslösen soll.

7) Timo:

Das Einzige was ich bislang richtig vermisse (oder nur noch nicht gefunden habe), ist die Möglichkeit von automatisierten Programmtests, um die Zustände der Ein- und Ausgänge in Abhängigkeit voneinander gegen eine Vorlage/Vorgabe prüfen lassen zu können.

Hab noch ein klein wenig Geduld: Zur HMI iM April werden wir den PiCtory mit dem neuen PiControl vorstellen, der einen integrierten Databroker besitzt, mit dem so was dann sehr einfach zu realisieren sein wird! Dein Wunsch nach einer solchen Prüfbarkeit war einer der Anlässe für uns, dieses Thema zügig zu realisieren.

Danke für die Ausführungen!