Verwendung als SPS
Hallo, kann der Revolution Pi auch mit der Siemens S7 Software programmiert und somit als SPS betrieben werden?
Hallo chrisb,
nein, mit Siemens-Software kannst du auch nur Siemens SPSen programmieren. Aber für den RevPi gibt es zum Beispiel logi.cals als SPS-Lösung. Der Editor von logi.cals heißt logi.CAD3 und man programmiert mit diesem Editor nach EN 61131-3 in ST oder FUB. Daher JA, natürlich kann der revPi als SPS eingesetzt werden, solange Zykluszeiten von ca. 10 ms kein Hindernis für die Applikation sind.
nein, mit Siemens-Software kannst du auch nur Siemens SPSen programmieren. Aber für den RevPi gibt es zum Beispiel logi.cals als SPS-Lösung. Der Editor von logi.cals heißt logi.CAD3 und man programmiert mit diesem Editor nach EN 61131-3 in ST oder FUB. Daher JA, natürlich kann der revPi als SPS eingesetzt werden, solange Zykluszeiten von ca. 10 ms kein Hindernis für die Applikation sind.
Unser RevPi Motto: Don't just claim it - make it!
Wie ist das mit Codesys? Könnte auch Codesys genutzt werden oder ist das nicht vorgesehen?
HAAAAALT!
Bitte nicht RevPi Core mit Raspberry Pi gleichsetzen! Der RevPi Core verfügt nicht über frei zugängliche GPIOs oder SPI oder I2C (=>Pfostensteckverbinder vom Raspi).
Was also will man mit Codesys für Raspi auf dem RevPi Core anfangen? Es lassen sich keine Ein- oder Ausgänge zum Steuern anschließen!
Wie schon mehrfach geschildert, haben wir Gespräche mit dem Hersteller von Codesys geführt und dort ist man im Entscheidungsprozess, ob Codesys für RevPi angepasst wird. Der aktuelle Stand ist aber:
Es ist weder klar ob noch wie und in welchem Zeitrahmen dies geschehen wird.
Wenn Ihr Interesse an einer solchen Lösung habt, dann müsst Ihr als Kunden beim Hersteller von Codesys Euren Wunsch mit Nachdruck vortragen. Wir von KUNBUS würden übrdigens eine Variante bevorzugen, bei der das Prozessabbild von PiControl genutzt wird. Nur so ist sichergestellt, dass die vielen Firmen, die aktuell dabei sind, ihre Software auf den RevPi zu portieren (darunter sind Cloudlösungen und Treiber für Funktexhnik etc.) dann auch Ergebnisse abliefern, die unter Codesys verwertbar wären. Würde Codesys allerdings eigene Treiber für unsere PiBridge schreiben, so würde lediglich der aktuelle Stand eingefrohren und alle zukünftigen Weiterentwicklungen in SW und HW müssten auch bei Codesys eine Anpassung nach sich ziehen - aus Sicht der RevPi Community eigentlich gar kein schöner Weg...
Bitte nicht RevPi Core mit Raspberry Pi gleichsetzen! Der RevPi Core verfügt nicht über frei zugängliche GPIOs oder SPI oder I2C (=>Pfostensteckverbinder vom Raspi).
Was also will man mit Codesys für Raspi auf dem RevPi Core anfangen? Es lassen sich keine Ein- oder Ausgänge zum Steuern anschließen!
Wie schon mehrfach geschildert, haben wir Gespräche mit dem Hersteller von Codesys geführt und dort ist man im Entscheidungsprozess, ob Codesys für RevPi angepasst wird. Der aktuelle Stand ist aber:
Es ist weder klar ob noch wie und in welchem Zeitrahmen dies geschehen wird.
Wenn Ihr Interesse an einer solchen Lösung habt, dann müsst Ihr als Kunden beim Hersteller von Codesys Euren Wunsch mit Nachdruck vortragen. Wir von KUNBUS würden übrdigens eine Variante bevorzugen, bei der das Prozessabbild von PiControl genutzt wird. Nur so ist sichergestellt, dass die vielen Firmen, die aktuell dabei sind, ihre Software auf den RevPi zu portieren (darunter sind Cloudlösungen und Treiber für Funktexhnik etc.) dann auch Ergebnisse abliefern, die unter Codesys verwertbar wären. Würde Codesys allerdings eigene Treiber für unsere PiBridge schreiben, so würde lediglich der aktuelle Stand eingefrohren und alle zukünftigen Weiterentwicklungen in SW und HW müssten auch bei Codesys eine Anpassung nach sich ziehen - aus Sicht der RevPi Community eigentlich gar kein schöner Weg...
Unser RevPi Motto: Don't just claim it - make it!
-
LMDaniel999
- Posts: 4
- Joined: 26 Apr 2017, 17:01
Hallo,
gibt es zu Codesys schon was Neues?
Ich nutze Codesys auf vielen Raspberry Pis und auch in vielen SPSen.
Zum Testen habe mir auch einen RevPi und ein I/O Modul gekauft.
Leider fand Codesys den RevPi nicht, weswegen ich hier ein neues Image auf den RevPi gespielt habe.
Codesys läuft zwar, aber die I/Os kann ich ja so nicht nutzen.
Daher wäre mein nächster Schritt noch, dass ich beides zusammen zum Laufen bekomme.
Ich denke, dass es kein großes Problem sein dürfte, das Prozessabbild der PiBridge in Codesys zu bekommen, oder?
Kann man die Pi Bridge Software auf einem Raspbian Image nachinstallieren, oder muss ich eher die Codesys Lizenz auf dem ursprünglichen Image nachinstallieren?
Danke!
gibt es zu Codesys schon was Neues?
Ich nutze Codesys auf vielen Raspberry Pis und auch in vielen SPSen.
Zum Testen habe mir auch einen RevPi und ein I/O Modul gekauft.
Leider fand Codesys den RevPi nicht, weswegen ich hier ein neues Image auf den RevPi gespielt habe.
Codesys läuft zwar, aber die I/Os kann ich ja so nicht nutzen.
Daher wäre mein nächster Schritt noch, dass ich beides zusammen zum Laufen bekomme.
Ich denke, dass es kein großes Problem sein dürfte, das Prozessabbild der PiBridge in Codesys zu bekommen, oder?
Kann man die Pi Bridge Software auf einem Raspbian Image nachinstallieren, oder muss ich eher die Codesys Lizenz auf dem ursprünglichen Image nachinstallieren?
Danke!
Hallo LMDaniel999,
ich hatte mich vor einer weile schon mal selber an Codesys gewendet und wollte von denen wissen ob sie was im petto für den RevPi haben, leider haben sie nur als auskunft gegeben das nichts in der Art geplant ist in nächster Zeit.
Daher bin ich persönlich auf LC3 umgestiegen was ich bis heute nicht bereut habe. Top Support dort wenn es Probleme gibt. So wie es für mich den Anschein hatte in dem Gespräch mit Codesys habe sie garkein richtiges Interesse gezeigt da etwas zu machen. "Wer nicht will der hat schon" habe ich da nur so gedacht und das gesräch beendet. seither ist auch nichts weiter zurück gekommen.
Aber wer weiß vieleicht haben sie ja die Scheuklappen schon abgenommen und planen doch was. Melde dich doch mal selber per mail bei denen um so mehr anfragen um so mehr zugzwang bekommen sie um was zu unternehmen. Oder sie wollen PerDU nicht.
gruß
ich hatte mich vor einer weile schon mal selber an Codesys gewendet und wollte von denen wissen ob sie was im petto für den RevPi haben, leider haben sie nur als auskunft gegeben das nichts in der Art geplant ist in nächster Zeit.
Daher bin ich persönlich auf LC3 umgestiegen was ich bis heute nicht bereut habe. Top Support dort wenn es Probleme gibt. So wie es für mich den Anschein hatte in dem Gespräch mit Codesys habe sie garkein richtiges Interesse gezeigt da etwas zu machen. "Wer nicht will der hat schon" habe ich da nur so gedacht und das gesräch beendet. seither ist auch nichts weiter zurück gekommen.
Aber wer weiß vieleicht haben sie ja die Scheuklappen schon abgenommen und planen doch was. Melde dich doch mal selber per mail bei denen um so mehr anfragen um so mehr zugzwang bekommen sie um was zu unternehmen. Oder sie wollen PerDU nicht.
gruß
Sorry Leute, aber wenn Ihr uns von KUNBUS nicht glaubt, wenn wir sagen, dass das nicht funktioniert, dann weiß ich echt nicht mehr weiter...
Ich hatte doch sehr ausführlich beschrieben, warum man nicht Raspi mit RevPi in dieser Hinsicht vergleichen darf. Nein es ist eben doch eine sehr große Sache, die Daten vom Prozessabbild nach Codesys zu bringen und außerdem würde die komplette Konfiguration der IOs über Codesys niemals so funktionieren.
3S selber (ein Mitarbeiter aus dem Top-Management) sagte mir, dass sie 1 Mannjahr Entwicklung bräuchten, wenn sie das realisieren würden.
Für die Umsetzung der Datenübernahem benötigt man das Entwicklungspaket von Codesys für viele viele tausend Euronen. Und selbst dann wird man nicht einfach PiControl verwenden können, sondern mit Hilfe des Entwicklungspaketes würde statt dessen der Datenaustausch über dei PiBridge selber programmiert werden.
Zu dem Einspielen eines anderen Images: ISt auf dem alernativen Image denn überhaupt ein RT-Patch? Wenn nein, wie stellst Du Dir denn vor, dass der Jitter auch nur näherungsweise vorhergesagt werden soll? Sobald Du über USB oder Ethernet Zugriffe hast, werden die anderen Tasks volle Kanne ausgebremst und dann fehlen eben mal für ein paar Sekunden die IO-Zugriffe. Unsere DIOs würden da zum Beispiel schon auf Störung gehen und die Ausgänge eben mal grade in den sicheren Zustand.
Codesys für Raspi wird ausdrücklich nur für den privaten Gebrauch angegeben und ist nicht für den industriellen Einsatz geeignet. Eben z.B. wegen dieser Einschränkungen. Solange 3S hier sich keine Mühe gibt und für den revolution Pi eine Lösung programmiert, wird unsere Revolution leider ohne Codesys stattfinden müssen. Aber es gibt ja Alternativen, die sicher kein Quant schlechter sind, wie Ingos Erfahrungen zeigen.
Ich hatte doch sehr ausführlich beschrieben, warum man nicht Raspi mit RevPi in dieser Hinsicht vergleichen darf. Nein es ist eben doch eine sehr große Sache, die Daten vom Prozessabbild nach Codesys zu bringen und außerdem würde die komplette Konfiguration der IOs über Codesys niemals so funktionieren.
3S selber (ein Mitarbeiter aus dem Top-Management) sagte mir, dass sie 1 Mannjahr Entwicklung bräuchten, wenn sie das realisieren würden.
Für die Umsetzung der Datenübernahem benötigt man das Entwicklungspaket von Codesys für viele viele tausend Euronen. Und selbst dann wird man nicht einfach PiControl verwenden können, sondern mit Hilfe des Entwicklungspaketes würde statt dessen der Datenaustausch über dei PiBridge selber programmiert werden.
Zu dem Einspielen eines anderen Images: ISt auf dem alernativen Image denn überhaupt ein RT-Patch? Wenn nein, wie stellst Du Dir denn vor, dass der Jitter auch nur näherungsweise vorhergesagt werden soll? Sobald Du über USB oder Ethernet Zugriffe hast, werden die anderen Tasks volle Kanne ausgebremst und dann fehlen eben mal für ein paar Sekunden die IO-Zugriffe. Unsere DIOs würden da zum Beispiel schon auf Störung gehen und die Ausgänge eben mal grade in den sicheren Zustand.
Codesys für Raspi wird ausdrücklich nur für den privaten Gebrauch angegeben und ist nicht für den industriellen Einsatz geeignet. Eben z.B. wegen dieser Einschränkungen. Solange 3S hier sich keine Mühe gibt und für den revolution Pi eine Lösung programmiert, wird unsere Revolution leider ohne Codesys stattfinden müssen. Aber es gibt ja Alternativen, die sicher kein Quant schlechter sind, wie Ingos Erfahrungen zeigen.
Unser RevPi Motto: Don't just claim it - make it!
-
LMDaniel999
- Posts: 4
- Joined: 26 Apr 2017, 17:01
Hi.
Ich hab schon längere Zeit nicht mehr hier rein geschaut. Aber bin etwas verdutzt nach der letzten Antwort:
Zitat von Volker: "Sorry Leute, aber wenn Ihr uns von KUNBUS nicht glaubt, wenn wir sagen, dass das nicht funktioniert, dann weiß ich echt nicht mehr weiter..."
Vorheriges Zitat von Volker: "Wenn Ihr Interesse an einer solchen Lösung habt, dann müsst Ihr als Kunden beim Hersteller von Codesys Euren Wunsch mit Nachdruck vortragen."
Ich finde schon, dass Codesys für den RevPi interessant ist.
Man muss ja nicht die I/Os vom Raspberry oder vom RevPi nehmen. Man kann ja auch über USB oder Ethernet kommunizieren.
Ich habe selbst ein Auswertegerät mit dem Raspberry Pi 3 und Codesys entworfen, welches über USB eine Messuhr ausliest und die Daten in Codesys auswertet und anzeigt.
Zusätzlich werden diese Daten protokolliert und sind über Netzwerk abrufbar.
Dazu brauche ich keine I/O Module.
Dass er nicht echtzeitfähig ist, ist klar. Die Anforderung muss man klären und die Verantwortung muss man tragen.
Die Industrietauglichkeit ist beim Raspberry nicht gegeben und muss erzeugt werden. Aber auch das haben wir hinbekommen.
Das wäre bei dem Revolution Pi halt kein Problem mehr.
Schade, dass die I/Os vom RevPi nicht in Codesys laufen werden. Aber damit kann man leben.
Findet Codesys das neue Image für den RevPi? (Werde das demnächst auch mal testen)
Alternativ werde ich mir das LC3 auch mal ansehen.
Den RevPi mit I/Os habe ich ja eh schon.
Ich möchte aber nicht etliche verschiedene Systeme.
Und Codesys ist TwinCat halt ähnlich. Daher die Präferenz.
Ich hab schon längere Zeit nicht mehr hier rein geschaut. Aber bin etwas verdutzt nach der letzten Antwort:
Zitat von Volker: "Sorry Leute, aber wenn Ihr uns von KUNBUS nicht glaubt, wenn wir sagen, dass das nicht funktioniert, dann weiß ich echt nicht mehr weiter..."
Vorheriges Zitat von Volker: "Wenn Ihr Interesse an einer solchen Lösung habt, dann müsst Ihr als Kunden beim Hersteller von Codesys Euren Wunsch mit Nachdruck vortragen."
Ich finde schon, dass Codesys für den RevPi interessant ist.
Man muss ja nicht die I/Os vom Raspberry oder vom RevPi nehmen. Man kann ja auch über USB oder Ethernet kommunizieren.
Ich habe selbst ein Auswertegerät mit dem Raspberry Pi 3 und Codesys entworfen, welches über USB eine Messuhr ausliest und die Daten in Codesys auswertet und anzeigt.
Zusätzlich werden diese Daten protokolliert und sind über Netzwerk abrufbar.
Dazu brauche ich keine I/O Module.
Dass er nicht echtzeitfähig ist, ist klar. Die Anforderung muss man klären und die Verantwortung muss man tragen.
Die Industrietauglichkeit ist beim Raspberry nicht gegeben und muss erzeugt werden. Aber auch das haben wir hinbekommen.
Das wäre bei dem Revolution Pi halt kein Problem mehr.
Schade, dass die I/Os vom RevPi nicht in Codesys laufen werden. Aber damit kann man leben.
Findet Codesys das neue Image für den RevPi? (Werde das demnächst auch mal testen)
Alternativ werde ich mir das LC3 auch mal ansehen.
Den RevPi mit I/Os habe ich ja eh schon.
Ich möchte aber nicht etliche verschiedene Systeme.
Und Codesys ist TwinCat halt ähnlich. Daher die Präferenz.
Hallo Daniel,
meine Aussage bezog sich definitv auf RevPi als modulares System mit Verwendung der IOs, so wie in Deinem Posting ursprünglich erwartet. Wenn man denn das System "kastriert" und als IPC verwendet und auch noch auf Dinge wie die Feldbusfähigkeit oder die RTC weitgehend verzichtet, dann mag es sein, dass man eine Software installieren kann. Aber würde es da nicht wesentlich mehr Sinn machen, wenn 3S sein System vernünftig auf die RevPi Plattform protieren würde??? Wir von KUNBUS haben nie gesagt, dass dies nicht interessant wäre, sondern ich habe mich persönlich beim hersteller darum bemüht, dass dies geschieht. Aber wir können das nicht erzwingen, das ist und bleibt deren Entscheidung es zu tun oder es zu lassen. Daher stehe ich zu meiner Aussage, dass Ihr, die Ihr diese PLC Software bevorzugt am ehesten Druck auf 3S aufbauen könnt, indem Ihr diese Lösung als Kunden und Anwender einfordert.
Bitte bedenke auch, dass die Universalität und Ausbaufähigkeit beim RevPi auf dem Prozessabbild und dem PiControl Treiber aufbaut. Nur durch diese zentrale Gemeinsamkeit können alle so viele Firmen ihre Software protieren, wie das aktuell geschieht und alle Bausteine passen dann perfekt zusammen, weil jede Applikation auf den zentralen Datenpool zugreifen kann und durch das open source Konzept auch jeder seine eigene Software erstellen kann, mit der er die Prozessdaten verwendet. Wir hüätten nichts gewonnen, wenn mit dem Codesys für Raspberry dann zwar diese eine Software auf dem Gerät läuft aber wegen jeder neuen Hard- oder Sooftwarekomponente ein teures Entwicklungskit von Codesys gekauft werden müsste, um solche Komponenten ins System einzubinden. Das ist nicht das Konzept von Revolutioj Pi. Wir stehen für eine offene Lösung, bei der jede Applikation ohne großen Aufwand die Daten nutzen kann. Warum 3S sich nicht auf dieses Konzept einlassen will und lieber ein proprietäre Lösung favorisiert, die über 1 Jahr Entwicklungsarbeit erfordert (und dann offenbar ob der Kosten einen Rückzieher macht) ist uns nicht wirklich klar. Andere Hersteller konnten Ihre Systeme in wenigen Wochen so umbauen, dass sie auf unser zentrales PA zugreifen und sich die Symantik der Daten aus den PiCtory Exportdateien holen.
meine Aussage bezog sich definitv auf RevPi als modulares System mit Verwendung der IOs, so wie in Deinem Posting ursprünglich erwartet. Wenn man denn das System "kastriert" und als IPC verwendet und auch noch auf Dinge wie die Feldbusfähigkeit oder die RTC weitgehend verzichtet, dann mag es sein, dass man eine Software installieren kann. Aber würde es da nicht wesentlich mehr Sinn machen, wenn 3S sein System vernünftig auf die RevPi Plattform protieren würde??? Wir von KUNBUS haben nie gesagt, dass dies nicht interessant wäre, sondern ich habe mich persönlich beim hersteller darum bemüht, dass dies geschieht. Aber wir können das nicht erzwingen, das ist und bleibt deren Entscheidung es zu tun oder es zu lassen. Daher stehe ich zu meiner Aussage, dass Ihr, die Ihr diese PLC Software bevorzugt am ehesten Druck auf 3S aufbauen könnt, indem Ihr diese Lösung als Kunden und Anwender einfordert.
Bitte bedenke auch, dass die Universalität und Ausbaufähigkeit beim RevPi auf dem Prozessabbild und dem PiControl Treiber aufbaut. Nur durch diese zentrale Gemeinsamkeit können alle so viele Firmen ihre Software protieren, wie das aktuell geschieht und alle Bausteine passen dann perfekt zusammen, weil jede Applikation auf den zentralen Datenpool zugreifen kann und durch das open source Konzept auch jeder seine eigene Software erstellen kann, mit der er die Prozessdaten verwendet. Wir hüätten nichts gewonnen, wenn mit dem Codesys für Raspberry dann zwar diese eine Software auf dem Gerät läuft aber wegen jeder neuen Hard- oder Sooftwarekomponente ein teures Entwicklungskit von Codesys gekauft werden müsste, um solche Komponenten ins System einzubinden. Das ist nicht das Konzept von Revolutioj Pi. Wir stehen für eine offene Lösung, bei der jede Applikation ohne großen Aufwand die Daten nutzen kann. Warum 3S sich nicht auf dieses Konzept einlassen will und lieber ein proprietäre Lösung favorisiert, die über 1 Jahr Entwicklungsarbeit erfordert (und dann offenbar ob der Kosten einen Rückzieher macht) ist uns nicht wirklich klar. Andere Hersteller konnten Ihre Systeme in wenigen Wochen so umbauen, dass sie auf unser zentrales PA zugreifen und sich die Symantik der Daten aus den PiCtory Exportdateien holen.
Unser RevPi Motto: Don't just claim it - make it!
