# SPS, mit Codesys V3 standard programmierbar.



## Not-Aus (6 März 2019)

Hallo alle, 

aus "Pflichtenheft":



Keine IPC mit Betriebssystem, also kein Linux, Windows Embedded etc
Muss mit Codesys Standard V3 programmierbar sein, also keine E-cockpit, TwinCat usw.

Ich habe bisher einige Beispiele gefunden:


Berghof
Kuhnke Kendrion
IDS Acos

Fragen: Hat jemand Erfahrungen mit den Herstellern? Gibt es andere, die das "Plichtenheft" erfüllt?

Danke!


----------



## Blockmove (6 März 2019)

Für die Wago-Controller PFC 100/200 gibt es von 3S eine Codesys-Runtime.
Also Wago ohne eCockpit.
Obwohl die PFC unter Linux laufen, würde ich die PFC nicht als IPC bezeichnen.
Unter der Haube werkelt ein Arm-Prozessor.

Gruß
Blockmove


----------



## wollvieh (6 März 2019)

Wie wär's mit Relais?  ;-)
http://devices.codesys.com/device-directory.html


----------



## oliver.tonn (7 März 2019)

Hallo,
je nachdem wie Ihr "kein Betriebssystem" und "Muss mit Codesys V3 standard programmierbar sein" definiert, sind Eure Wünsche nicht erfüllbar.
Soweit Ihr nur Windows und Linux als OS ausschließen wollt gäbe es reichlich Alternativen, wenn Ihr aber generell kein OS haben wollt wird es da nichts geben. Codesys braucht auf der SPS eine Basis auf die es aufsetzen kann und diese Basis ist ein OS. Nur weil die Hersteller nicht explizit ein OS erwähnen heißt es ja nicht, dass dort keins läuft, einige Hersteller setzen z.B. VxWorks ein, erwähnen dies aber nicht.
Dann zum Punkt "Muss mit Codesys V3 standard programmierbar sein". Wenn das heißen soll, dass Ihr Euch einfach die neueste Version von Codesys bei 3S (dem Hersteller von Codesys) herunterladen wollt und erwartet, dass Ihr damit Programme für eine Steuerung erstellen und einspielen könnt ist auch dies zum Scheitern verurteilt. Keine Steuerung ist mit einem unangepassten Codesys von 3S programmierbar, es wird immer mindestens ein sogenanntes Target (Support) Package benötigt, dass Infos zum Zielsystem, benötigte Plugins und angepasste Bibliotheken enthält.


----------



## seehma (7 März 2019)

Hallo,
Ich würde auch nochmal zum "Pflichtenheft-Schreiber" gehen und ihn Fragen was er genau für Steuerung haben möchte.
Abklopfen kannst du seine Infos ja folgendermaßen: Kein Betriebssystem vermutlich weil er sich nicht um Updates kümmern möchte. kein IPC weil er vermutlich zu wenig vertrauen in die "PC-Hardware" hat. 
Beinahe jeder Hersteller hat hier MTBF Berechnungen und liefert seine Gerätschaften auf 10 Jahre da sie bei den CPUs auf die Langzeit-Support Modelle setzen, also auch hier --> IPC kein Problem.
Bei den Updates muss man halt den Rechner dementsprechend gut vom restlichen Netz abschotten, dass keine Bakterien drauf kommen. Nur weil kein, unter Laien verständliches Standard Betriebssystem installiert ist, heißt das nicht dass die Steuerung abgesichert ist. VxWorks und andere Betriebssysteme haben etliche Lücken, die nicht gefixt wurden, weil zu wenig Verbreitung oder weil noch nicht gefunden (trägt auch zum ersten Punkt bei).
Sg
M.


----------



## Hoffy (7 März 2019)

Vielleicht meint er sowas 
*CODESYS Control Runtime Toolkit*


https://www.codesys.com/products/codesys-runtime/runtime-toolkit.html

das geht aber nur bei Tricore Prozessoren oder  Cortex M3, M4, R4

https://de.wikipedia.org/wiki/Infineon_TriCore


----------



## oliver.tonn (7 März 2019)

Hallo Hoffy,


Hoffy schrieb:


> Vielleicht meint er sowas
> *CODESYS Control Runtime Toolkit*
> 
> 
> ...


da hast Du jetzt aber was völlig missverstanden. Das Runtime Toolkit benötigt man, wenn man eine eigene SPS auf Basis von Codesys entwicklen will. Als ich für die ABB (2008-2011) in der SPS-Entwicklung tätig war hatte ich auch mal Interesse an dem Toolkit. Damals kostete es die "Kleinigkeit" von 10.000,-€.

@TE: Ich muss meine Aussage, dass Codesys immer ein OS als Basis benötigt dank dem Hinweis von Hoffy korrigieren. Wenn das Zielsystem als CPU einen TriCore TC1798 oder Cortex M3, M4 oder R4 hat arbeitet Codesys auch ohne OS. Wie es mit den unter "Other target device platforms" aufgeführten CPUs ausschaut, ob diese ein OS benötigen oder nicht kann ich nicht sagen, hier kann aber sicher 3S Auskunft geben.


----------



## Kieler (8 März 2019)

Moin,

ich hatte für mich selbst ähnliche Anforderungen. Weiterhin durfte die Steuerung auch gerne wie eine klassische SPS aussehen. Für Codesys gibt es ansonsten auch die wildesten Konstruktionen. Ich habe für mich jetzt gewählt:

Hitachi EHV+

Diese verwenden ein reines Codesys zuzüglich ihrer Targets. Sie sind auch schon ewig mit diesem Produkt auf dem deutschen Markt.

Ansonsten beginnt mein Projekt auch gerade erst. Daher gibt es keine wirklichen Erfahrungen.

Bei Eaton (vormals Möller) gibt es auch die XN300 Serie. Mir hat aber Hitachi besser gefallen.

Schreibe bitte, wofür ihr euch entschieden habt.


----------



## testor (8 März 2019)

oliver.tonn schrieb:


> Hallo Hoffy,
> 
> da hast Du jetzt aber was völlig missverstanden. Das Runtime Toolkit benötigt man, wenn man eine eigene SPS auf Basis von Codesys entwicklen will. Als ich für die ABB (2008-2011) in der SPS-Entwicklung tätig war hatte ich auch mal Interesse an dem Toolkit. Damals kostete es die "Kleinigkeit" von 10.000,-€.
> 
> @TE: Ich muss meine Aussage, dass Codesys immer ein OS als Basis benötigt dank dem Hinweis von Hoffy korrigieren. Wenn das Zielsystem als CPU einen TriCore TC1798 oder Cortex M3, M4 oder R4 hat arbeitet Codesys auch ohne OS. Wie es mit den unter "Other target device platforms" aufgeführten CPUs ausschaut, ob diese ein OS benötigen oder nicht kann ich nicht sagen, hier kann aber sicher 3S Auskunft geben.



Ich gehe dann aber davon aus, dass Codesys  auch keine Echtzeitfähigkeit anbietet und lediglich mit einer freilaufenden Task funktioniert. Würde sich dann meiner Einschätzung nach um „intelligente“ buskoppler handeln.


----------



## oliver.tonn (8 März 2019)

Kieler schrieb:


> Hitachi EHV+
> Diese verwenden ein reines Codesys zuzüglich ihrer Targets. Sie sind auch schon ewig mit diesem Produkt auf dem deutschen Markt.


Woran machst Du die Aussage "verwenden reines Codesys" fest, dass die Entwicklungsumgebung sich optisch nicht vom nativen Codesys unterscheidet? Oder hast Du Infos vom Hersteller? Nur weil die Entwicklungsumgebung sich optisch nicht vom nativen Codesys unterscheidet heißt das nicht, dass der Hersteller keine Anpassungen vorgenommen hat. Bei Codesys V3 läuft vieles, wenn nicht sogar fast alles, über sogenannte Plugins und nur weil diese sich optisch nicht unterscheiden bedeutet das nicht, dass diese nicht angepasst sind. Und ich weiß nicht, ob sich bei Codesys 3 diese Plugins einfach über das Target Package hinzufügen lassen und dafür nicht eine angepasste Installation notwendig ist.
Fakt ist, dass man ohne ein angepasstes Codesys keine Steuerung programmieren kann. Selbst das Codesys das wir uns bei 3S herunterladen können ist nicht nativ, sondern ebenfalls angepasst, denn es enthält Targets für die 3S Soft-SPS und dazugehörige Bibliotheken. Ein natives Codesys bekommt man nur, wenn man das CODESYS Control Runtime Toolkit erworben hat.
Ich habe mir gerade mal das Handbuch der Hitachi angesehen, ein interessantes System, allerdings bezweifele ich, dass es die erste Forderung des TE erfüllt und ohne OS auskommt. Wobei ich mich auch frage, ob dem TE eine PLC ohne OS reicht, da mit ziemlicher Sicherheit gewisse Funktionalitäten einfach ein OS erfordern.


----------



## Kieler (8 März 2019)

Ich habe die Anforderung des Endkunden so verstanden, dass er kein e!Cockpit oder wie auch immer ähnliche Produkte heißen haben. Was ich auch voll verstehen kann. Vermutlich möchte er kein WIN CE auf der CPU.

Ich habe mit Hitachi gesprochen. Es handelt sich um normales Codesys 3.5 zuzüglich ihrer Targets.
Eigene Bibliotheken werden natürlich auch installiert. Für Fehlerauswertung, Uhrzeit und solch Zeug.

Ich gehe davon aus, dass der Kunde eine industrielle Lösung haben möchte.


----------



## oliver.tonn (8 März 2019)

testor schrieb:


> Ich gehe dann aber davon aus, dass Codesys dann auch keine Echtzeitfähigkeit anbietet und lediglich mit einer freilaufenden Task funktioniert. Würde sich dann meiner Einschätzung nach um „intelligente“ buskoppler handeln. Wobei man für echtzeitfähige Kommunikation vermutlich auch ein RTOS benötigt?


Das wäre mal interessant zu erfahren, ob bei SPSen ohne OS auch zyklische Tasks möglich sind. Die Frage wird aber nur 3S (Hallo HausSPSler/Herr Schwellinger, können Sie hier Licht ins Dunkel bringen?), ein Hersteller solcher SPSen oder ein Anwender solcher SPSen, der sicher weiß, dass kein OS vorhanden ist beantworten können.


----------



## oliver.tonn (8 März 2019)

Kieler schrieb:


> Ich habe die Anforderung des Endkunden so verstanden, dass er kein e!Cockpit oder wie auch immer ähnliche Produkte heißen haben. Was ich auch voll verstehen kann. Vermutlich möchte er kein WIN CE auf der CPU.


Da er auch von Linux schreibt nicht nur und da stellt sich dann immer noch die Frage, ob Hitachi ein OS nutzt und wenn ja welches und ob der TE grundsätzlich kein OS möchte?
Wie ich aber schon schrieb könnte eine SPS ohne OS für den TE nicht ausreichend sein, weil der Funktionsumfang nicht passt, z.B., wie testor anmerkte, keine zyklische Taskbearbeitung möglich ist.


----------



## Kieler (8 März 2019)

Die Vorgaben von Kunden muss man vielleicht auch nicht wörtlich nehmen. Man kann sicherlich nachfragen, wenn man eine Idee hat.


----------



## oliver.tonn (8 März 2019)

Kieler schrieb:


> Ich gehe davon aus, dass der Kunde eine industrielle Lösung haben möchte.


Was genau meinst Du damit? Alle mir bekannten auf Codesys basierten Steuerungen, von Arduino, Raspberry und Co. mal abgesehen, sind industrielle Lösungen.


----------



## Hoffy (8 März 2019)

Ohne Betriebsystem , braucht man eine Schnittstelle und es kommt nur ein Controller in frage. Wie ich  oben geschrieben habe.
 Controller mit einem  Monitor (Touchscrenn wie HMI) verbinden ,USB-Stick mit 

Codsys-runtime in Kontroller reinstecken , SPS-Gerät mit Kontroller verbinden  und es kann los gehen ,Cortex M3, M4, 

R4 unterstützen auch GUI (Graphic ) so das man   die Controller auch mit Knöpfe und Graphic prorogrammieren kann wie  ein HMI .


----------



## Kieler (8 März 2019)

oliver.tonn schrieb:


> Was genau meinst Du damit? Alle mir bekannten auf Codesys basierten Steuerungen, von Arduino, Raspberry und Co. mal abgesehen, sind industrielle Lösungen.


 Genau das meinte ich. Also kein Raspberry und Co.


----------



## Hoffy (8 März 2019)

https://www.infineon.com/cms/de/product/microcontroller/32-bit-tricore-microcontroller/#!tools


                           Tools & Software
                                                     [h=2]TriCore™ Development Tools[/h]


----------



## Not-Aus (8 März 2019)

Hallo alle, und danke für ihre Antworten 

Wie oliver.tonn und Kieler bereits vermuten, ich glaube nicht, dass alle arte Betriebssysteme im Plichtenheft "verboten" sind. Simatic hat auch ein Betriebssystem, man muss aber nicht alle 3 Wochen Security Patches installieren. Und SPS klingt besser als IPC.

Edit:typo


----------



## Not-Aus (8 März 2019)

Hoffy schrieb:


> Ohne Betriebsystem , braucht man eine Schnittstelle und es kommt nur ein Controller in frage. Wie ich  oben geschrieben habe.
> Controller mit einem  Monitor (Touchscrenn wie HMI) verbinden ,USB-Stick mit
> 
> Codsys-runtime in Kontroller reinstecken , SPS-Gerät mit Kontroller verbinden  und es kann los gehen ,Cortex M3, M4,
> ...



Gibt es "Ready for Codesys" , industrietaugliche Controllern auf dem Markt? Also Kaufen -> Runtime reinsteicken -> Verbinden - > Losgehts 

oder sowas, ohne basteln?


----------



## roman@uniha.at (1 Dezember 2019)

Turck verwendet auch Codesys Standard.

Zum Thema "IPC ohne OS": Das OS einer SPS ist zwar dem eines IPC ähnlich, wird aber gewöhnlich als Firmware bezeichnet, auch wenn es auf Linux oder Windows oder sonst was basiert. Insofern ist die Spezifikation sehr klar.


----------



## Kieler (1 Dezember 2019)

roman@uniha.at schrieb:


> Turck verwendet auch Codesys Standard.



Turck, habe ich mich auch schon oft im Netz angesehen. Die Panel SPS'en gefallen mir richtig gut. Mir fehlt nur ein passendes Projekt.


----------

