# CoDeSys V3



## junkie (9 April 2011)

Hallo zusammen, 

bin neu hier und würde gerne etwas fragen:

Ich habe bis jetzt immer mit CoDeSys Version 2.x gearbeitet. Jetzt gibt es eine neue objektorientierte Version, V3. 
Ich wollte fragen, ob jemand bereits mit der neuen dritten Version gearbeitet hat und ob es große Unterschiede gibt? 

Ich weiß nicht, aber wenn es solange gedauert hat, bis eine neue Version rauskam, gibt es doch bestimmt irgendwelche sehr starke Vorteile für die älteren Versionen. (?)


----------



## rostiger Nagel (9 April 2011)

Wenn du sagen wir mal normale Programme schreibst reicht die V2.x aus. 
Möchtest du anspruchsvolle Anwendung in Hochsprache erstellen musst du
dich noch ein wenig gedulden, da die neue Version noch nicht erhältlich ist
und außer ein paar Beta tester und Beckhoff keiner wirkliche Auskunft geben
kann.


----------



## zotos (9 April 2011)

@Helmut_von_der_Reparatur. CoDeSys3 ist was anderes als TwinCAT3

Ich habe mit CoDeSys 3 bisher auch noch nicht gearbeitet. Aber hin und wieder liest man in den Foren das es tatsächlich eingesetzt wird.


----------



## rostiger Nagel (9 April 2011)

Oh Entschuldigung, mein Fehler 
@Junkie, stell doch die Frage neu und Frage nach Twincat 3


----------



## MSB (9 April 2011)

Der Vorteil von Codesys V2 ist der das momentan noch der bei weitem überwiegende Teil,
der Codesys-Steuerungen mit V2 programmiert werden muss, und auch für immer mit V2 Programmiert werden muss.

Für Codesys V3 gibt es momentan noch eine eher dürftige Basis
an unterstützer Hardware, weil die V3 von der ganzen Systemstrucktur und den Anforderungen an die Hardware,
ein ziemlich radikaler Schritt war, man könnte es auch Neubeginn nennen.

Am Beispiel Wago:
Die haben zig-Steuerungen für Codesys V2, aber nur eine einzige für V3 (Speedway 767).

Da ich fast nur Codesys-Steuerungen von Wago einsetze, kann ich momentan aber noch nicht mit irgendwelchen Erfahrungen diesbezüglich glänzen,
aber solange es mehr oder weniger keine Steuerungen dafür gibt, ist mir das auch eher egal ...

Mfg
Manuel


----------



## IBFS (9 April 2011)

Helmut_von_der_Reparatur schrieb:


> Oh Entschuldigung, mein Fehler
> @Junkie, stell doch die Frage neu und Frage nach Twincat 3



Das macht nix, etwas Infos gibt es hier:

http://www.ipsta.de/download/aktuell/Projektarbeit_CoDeSys_V2_vs_V3.pdf

Frank


----------



## StructuredTrash (9 April 2011)

junkie schrieb:


> Ich weiß nicht, aber wenn es solange gedauert hat, bis eine neue Version rauskam, gibt es doch bestimmt irgendwelche sehr starke Vorteile für die älteren Versionen. (?)



Ein grosser Vorteil von V2.x ist, dass sie funktioniert, was man von der V3 wohl noch nicht so 100%-ig behaupten kann. Ich habe gerade auf der HMI eine neue Steuerung gesehen, deren Hersteller aus diesem Grund die V3 noch nicht einsetzt.


----------



## junkie (10 April 2011)

Erstmal RIESENDANK an alle für die unglaublichen schnellen Antworten!!

@StructuredTrash

Aber unabhängig von den Steuerungen muss es doch irgendwelche Software-technische Gründe geben, warum V2 bis jetzt durchgehalten hat. Sonst wäre wieder irgendeine andere (vielleicht nicht die jetztige V3) Version rausgekommen. Und je früher eine neue Version rauskam, desto schneller wäre auch die entsprechende Software verfügbar. 

Andererseits muss es anscheinend bestimmte Nachteile bei V3 geben, da eben immer noch keine Steuerungen existieren (außer WAGO Speedway). 
Liegt es daran, dass in V2 das Programmieren leichter ist, als in V3? 
Ich meine, wenn V3 objektorientiert ist, erschrecken sich vielleicht viele Programmierer, weil sie sich von der Abstraktion her wenig vorstellen können?


----------



## junkie (10 April 2011)

@ IBFS 

Danke für den Link! 
Aber darunter sind nur die Unterschiede der Oberfläche zu sehen. Also nicht rein inhaltlich, sondern in den Funktionen bzw. den Einstellungen. 
Oder übersehe ich etwas?


----------



## IBFS (10 April 2011)

EDIT:Hat sich überschnitten

@junkie

Hast du dir meinen LINK aus POST #6 angeschaut?
So groß sind die Unterschiede nicht und daher ist (noch)
vielen Hersteller der Leidensdruck bzw. die Vorteile zu gering.

Das war z.B. beim Umstieg von STEP5 nach STEP7 oder
RS500 nach RS5000 (Rockwell) ganz anders.

Frank


----------



## bike (10 April 2011)

junkie schrieb:


> Ich meine, wenn V3 objektorientiert ist, erschrecken sich vielleicht viele Programmierer, weil sie sich von der Abstraktion her wenig vorstellen können?



Verwende doch einfach die SuFu zu OOP in PLC, dann wirst du hier inzwischen einiges finden.


bike


----------



## IBFS (10 April 2011)

junkie schrieb:


> @ IBFS
> 
> Danke für den Link!
> Aber darunter sind nur die Unterschiede der Oberfläche zu sehen. Also nicht rein inhaltlich, sondern in den Funktionen bzw. den Einstellungen.
> Oder übersehe ich etwas?


 
Wenn auch kurz, aber was ist mit Kapitel 3 und 4???
Die Unterschiede sind halt nicht so riesig im Code.
Der Rest ist wirklich mehr das Handling der Software.
Allerdings ist das kein kompletter Vergleich und schon
ne Weile alt.

Frank


----------



## MSB (10 April 2011)

Der Vorteil für die Alte:
Die Software ist weitgehen ausgereift, ohne nennenswerte Probleme.

Die V3 ist neu, weniger ausgereift, zudem für die HW-Hersteller scheinbar relativ schwierig zu handeln.
Kurzum, an der Misere sind wir als Benutzer/Programmierer weitgehend unschuldig (im Moment jedenfalls),
die Objektorientierung mag mitunter ja ein nettes Feature sein, aber da ich ja nicht gezwungen werde selbiges
zu benutzen, eigentlich ausschließlich ein Vorteil für V3, weil ich könnte wenn ich wollte.

Primär kann ich auch hier nur von Wago sprechen, die wissen bis heute noch nicht,
ob die mit der 750er-Serie eine Chance haben selbige V3-tauglich zu machen,
oder ob die eine nagelneue, nicht abwärts-kompatible Serie auflegen werden müssen.
Auf jedenfall ist das von der Entwicklung her nicht mal eben so gemacht.

Mfg
Manuel


----------



## cybertracepda (11 April 2011)

Hallo an alle !

Ich arbeite seit August 2008 mit der Version 3.xx und habe angefangen mit 3.1, jetzt gibt es 3.4 SP3 und bei jeder Version hat es seine Problemchen nach dem Upgrade gegeben.  Ich verwende einen Büro-PC mit XP SP3 und darunter läuft die RTE 3.xx von COdesys. Diese hatte und hat auch seine Macken, werden aber immer weniger.
Als Nachteil ist die lange Ladezeit beim Programmstart der ENtwicklungsumgebung zu sagen, wurde aber succesive immer besser.
Ich habe diese Steuerung nur für einen Testprüfstand verwendet, der im Haus ist und ich kann sagen, wenn einmal alles funktioniert, läuft es sehr zuverlässig.
Ich verwende Profibus mit 6 Antrieben von Lenze (9400) und die IOs von Beckhoff, BK3150 und KL.., und eine CIF50_PB von Hilscher (PCI_Steckkarte im IPC) da gabs ganz am Anafang Probleme, um den Bus überhaupt zum Laufen zu bringen. Als es dann gelaufen ist, gabs nach dem Upgrade auf die 3.3 SP1 auf einmal das Problem, dass ich alle Words, die von und zum Bus gingen, swappen musste, damit wieder alles läuft. Auf Nachfrage an Codesys Support kam nur ???, das ist nun so.
Sonst ist der Support von COdesys ok.
Die 3.xx bietet schon mehrere Vorteile, z.B. bedingte Compilierung von Codestellen, aber auch hier gibts noch Nachholbedarf beim bedingten COmpilieren von Strukturen.
Wenn man nun entscheidet, die Oop zu verwenden, dann muss man sich hinsetzen und mal ganz genau abchecken, was will ich denn damit machen und wie soll meine Struktur sein, damit es mit später etwas bringt, z.B. meine Grundmaschine, welche Eigenschaften und Methoden hat die, und dann die Weitervererbung oder überschreiben von Methoden. Ich habe das gemacht und es bringt schon was, wenn man in Modulen denkt.
Das debugging ist super und auch der Trace ist viel besser, man muss mit allen mal arbeiten.
Beckhoff kommt ja jetzt dann mal raus mit seiner neuen Version 3.x, da bin ich mal gespannt, wie das alles läuft, denn der Editor kommt ja von Codesys als Plugin. 
In der Hardware ist sowieso Beckhoff viel besser mit seinem Systemmanager, ich hoffe, das setzt sich auch in der Vesion 3.x  weiter so fort.


----------



## IBFS (11 April 2011)

@cybertracepda

Wenn ich das so lese, dann gibt es also gute Gründe, warum Beckhoff
das TWINCAD V3 so lange hinauszögert. Mit der 64bit-Geschichte gibt
es ja nun noch einen Grund dazu (bzw. dagegen  ;-)  )

Frank


----------



## bike (11 April 2011)

IBFS schrieb:


> @cybertracepda
> 
> Wenn ich das so lese, dann gibt es also gute Gründe, warum Beckhoff
> das TWINCAD V3 so lange hinauszögert. Mit der 64bit-Geschichte gibt
> ...



Kann ich nach meinem Besuch auf der Hannover Messe nur bestätigen.
Der nette Herr auf dem Beckhoff Stand hat mir vorgeschwärmt was das "neue" System alles kann. 
Doch live konnte bzw wollte er mir dies nicht zeigen, es lief nur das Video an der Wand.
Ein Frage nach 64 Bit und mehreren Kerne wurde sehr genau mit einem " es wird daran gearbeitet" beantwortet.


bike


----------



## cybertracepda (12 April 2011)

Hallo an alle !

Habe gerade im Internet gelesen.

Twincat V3

vorraussichtliche Markteinführung 4.Quartal 2011

Also haben die noch einiges zu tun.

Ist eh gut, wenn es nicht zu früh kommt, da halten sich die Bugs vielleicht in Grenzen und alles, was COdesys bis dahin an Bugs entfernt, ist gut für Beckhoff. Die haben dann aber auch die ANbindung ihrer Hardware, die ganzen Systembibliotheken und Addons ect.  und Klemmen ins System zu bearbeiten und das ist sicher viel Testarbeit.
Gespannt bin ich auf die SIcherheitssteuerung in Verbindung mit der SOft-PLC, die dann auf einem Rechner läuft, das würde Beckhoff ein schönes Stück weiterbringen gegenüber Siemens. Power habe ja die Rechner genug, um das zu handlen.
Ich bin gespannt, auf welcher Plattformen sie das V3 Zielsystem dann anbieten, wahrscheinlcih vorerst nur auf WIn7 embedded auf den CX...
vielleicht dann später auch auf CE Basis, wäre wünschenswert.

Warten wirs ab, was noch Gutes kommt, die Zeit wirds zeigen


----------



## IBFS (12 April 2011)

cybertracepda schrieb:


> vorraussichtliche Markteinführung 4.Quartal 2011



Der "running gag" bleibt uns erhalten. Also wird es nix mit der nächsten SPS&DRIVES.

Denke eher 2.Q 2012!

Frank


----------



## thomas.nienstaedt (16 April 2011)

*Bestes Codesys aller Zeiten*

Ich habe etliche Projekte mit V3 umgesetzt und kann eigentlich  bestätigen das die Jungs in Kempten mit jeder neuen Version einen Schritt nach vorne machen.
.... allerdings sollte man nach einem Svp erstmal den HF oder Patch abwarten!

Das System an sich läuft ziemlich stabil ist aber sehr träge und behäbig. Download Zeiten bei großen Projekten von bis zu 3 Minuten sind normal. Bei Projekte mit integrierter Visu kann eigentlich kein OnlineChange mit ruhigem Gewissen durchgeführt werden. Auch kleine Projekte erreichen schnell eine Downloadgröße von >1MB. Und dies wird sicherlich ein Hauptproblem für die HW-Hersteller sein.
Ich selber setze die RTE mit Ethercat und Beckhoff PC ein.

Ich denke richtig Freude wird das "Beste CodeSys aller Zeiten" wohl erst in ein paar Jahren machen!

Thomas


----------



## IBFS (17 April 2011)

thomas.nienstaedt schrieb:


> Ich habe etliche Projekte mit V3 umgesetzt .
> ...
> .Download Zeiten bei großen Projekten von* bis zu 3 Minuten* sind normal.
> ...
> ...



Wenn ich DAS lese 

Was würde die Crowd sagen, wenn das bei BIG S so wäre - komisch - bei 3S wird sowass augenscheinlich eher akzepiert.

Frank


----------



## Ralle (17 April 2011)

So was kann man dann wohl höchstens in Serienmaschinen einsetzen, die lange Zeit programmiert und getestet werden, im Sondermaschinenbau völlig inakzeptabel.


----------



## bike (18 April 2011)

IBFS schrieb:


> Wenn ich DAS lese
> 
> Was würde die Crowd sagen, wenn das bei BIG S so wäre - komisch - bei 3S wird sowass augenscheinlich eher akzepiert.
> 
> Frank



Daher heißt es ja 3S.
Bedeutet mindestens dritte Potenz höhere Übertragungsgeschwindigkeit. 


Du bist von BigS einfach versaut (oder soll ich schreiben "verwöhnt?)


bike


----------



## Werner29 (18 April 2011)

thomas.nienstaedt schrieb:


> Download Zeiten bei großen Projekten von bis zu 3 Minuten sind normal.


Welche Version setzt du aktuell ein? Was zählst du zur Downloadzeit dazu, und was ist dann ein grosses Projekt? 
Wir testen zu jeder Release die Performance mit ausgesuchten, besonders grossen Projekten. Der Test-PC ist dabei ein verhältnismässig veraltetes Teil, also kein Dual-Core oder sowas.
Für unser grösstes Projekt (ziemlich Visu-lastig) kommen dabei Übersetzungszeiten von etwa 5 Minuten raus und Downloadzeiten von 25 Sekunden bei 10 MB generiertem Code (Zielhardware ist hier auch die RTE). Ein Projekt aus dem Maschinenbau zum Vergleich: 1,6 MB Code ohne Visu, 1 Min Übersetzungszeit, 15 Sekunden Download.
Es stimmt nach wie vor, dass die V23 schneller war, aber im Vergleich zum Wettbewerb sind das keine schlechten Werte. Und wir arbeiten natürlich weiter an Verbesserungen.


----------



## Humbe (18 April 2011)

Hi, 

werd demnächst nach langer pause wieder mit Codesys arbeiten...
Kann mir wer sagen ob die V3 mittlerweile gängiger ist?

gruß


----------



## IBFS (19 April 2011)

Humbe schrieb:


> Kann mir wer sagen ob die V3 mittlerweile gängiger ist?


 
Du hast da nicht wirklich eine Wahlmöglichkeit. 
Es hängt einzig und allein von der Hardware (Target) ab,
welche Codesys-Version du verwenden mußt.

Diese Trennung gibt es sogar zwischen V2.2 und V2.3.
Es gibt Steuerungköpfe in Altprojekten, die kann man
nur mit V2.2 ansprechen. 

Bei WAGO z.B. ist außer der 6xx - Steuerung noch alles V2.3 

Also schaue dir die Hardware vorher genau an.

Frank


----------



## Humbe (19 April 2011)

Danke für die Info...
tja, dann bleibt mein problem bestehen bis ich die baugruppen kenn.
ich werd mich dann vielleicht nochmal melden ^^


----------



## bike (19 April 2011)

Werner29 schrieb:


> Für unser grösstes Projekt (ziemlich Visu-lastig) kommen dabei Übersetzungszeiten von etwa 5 Minuten raus und Downloadzeiten von 25 Sekunden bei 10 MB generiertem Code (Zielhardware ist hier auch die RTE). Ein Projekt aus dem Maschinenbau zum Vergleich: 1,6 MB Code ohne Visu, 1 Min Übersetzungszeit, 15 Sekunden Download.



In einer Testumgebung interessieren mich die Zeiten nicht, aber im Feld. 
Und da ist BigS leider? noch ziemlich am schnellsten und, was wichtig ist, haben die Features, die das Leben als Entwickler leichter machen.



Werner29 schrieb:


> Es stimmt nach wie vor, dass die V23 schneller war, aber im Vergleich zum Wettbewerb sind das keine schlechten Werte. Und wir arbeiten natürlich weiter an Verbesserungen.



Man kann immer schlechtere finden, doch für uns ist die Messlatte die Besten.


bike


----------



## Werner29 (19 April 2011)

bike schrieb:


> In einer Testumgebung interessieren mich die Zeiten nicht, aber im Feld.



Was soll denn im "Feld" anders sein? Wenn du einen Download über  Ethernet machst, dann ist das ein Download über Ethernet und ob das im  Büro oder in der Halle stattfindet, sollte vergleichsweise wurscht sein.
Wenn du einen Download über CanOpen machst, wirds langsamer werden, den kann ich aber auch im Büro durchführen.



bike schrieb:


> Und da ist BigS leider? noch ziemlich am schnellsten und, was wichtig ist, haben die Features, die das Leben als Entwickler leichter machen.
> Man kann immer schlechtere finden, doch für uns ist die Messlatte die Besten.
> bike



Wie lange brauchst du denn bei einem Siemens Projekt um 10 MB Code zu generieren? Was ist denn die Messlatte? Ich versuch ja gerade ein bisschen
Objektivität in die Debatte zu bringen.
Ich denke nicht, dass wir irgendeinen Vergleich zu scheuen brauchen.
Auch was die Funktionalität angeht.

Bernhard


----------



## IBFS (19 April 2011)

Werner29 schrieb:


> Wie lange brauchst du denn bei einem Siemens Projekt um 10 MB Code zu generieren?



Die Frage stellt sich garnicht!  Man macht eine Änderung ... Läde NUR den geänderten Baustein (ggf. plus IDB) in die Steuerung ...  10 Sekunden - fertig.

Diese ewige Komplettgenerierungsläufe ist genau das, was ich an solchen System nicht leiden kann.

Außerdem weiß man vor einer Änderung praktisch nie, ob das Programm nachher noch DELTA-Ladefähig ist.  

Frank


----------



## Werner29 (19 April 2011)

OK, das ist eine andere Diskussion. Wenn nur ein einzelner Baustein geändert wird, gehts auch bei CoDeSys schneller, aber nicht so schnell wie bei Siemens, das ist so.

Die Delta-Ladefähigkeit verlierst du bei CoDeSys genau in zwei Fällen: 
1. Änderungen in der Steuerungskonfiguration
2. Änderungen in der Taskkonfiguration.
Ausserdem wird der Code ohne dein Zutun immer inkrementell generiert. Beim normalen Arbeiten wird es daher eher schneller gehen.
Für vergleichbare Zahlen muss ich aber ein komplettes Übersetzen und einen kompletten Download messen.


----------



## bike (19 April 2011)

Werner29 schrieb:


> Was soll denn im "Feld" anders sein? Wenn du einen Download über  Ethernet machst, dann ist das ein Download über Ethernet und ob das im  Büro oder in der Halle stattfindet, sollte vergleichsweise wurscht sein.
> Wenn du einen Download über CanOpen machst, wirds langsamer werden, den kann ich aber auch im Büro durchführen.



Der Unterschied ist schlicht und einfach, dass ich im Büro mir einen Kaffee hole und in der Halle steht der Kunde hinter mir.




Werner29 schrieb:


> Wie lange brauchst du denn bei einem Siemens Projekt um 10 MB Code zu generieren? Was ist denn die Messlatte? Ich versuch ja gerade ein bisschen
> Objektivität in die Debatte zu bringen.
> Ich denke nicht, dass wir irgendeinen Vergleich zu scheuen brauchen.
> Auch was die Funktionalität angeht.
> ...



Ich brauche keine 10MB Code bei Siemens und auch nicht generieren, da mit dem Speichern übersetzt wird.
Ich finde diese Vergleiche der oder der ist schneller und besser ansich doof.
Doch ist die Funktionalität von Codesys oder Twincat noch? nicht so weit bei BigS. Wobei ich Siemens an vielen Stellen echt Scheiße finde. 
Doch bei Siemens wird konventionell die Schwachstellen bearbeitet und nicht ein völlig anderes Produkt, das vielleicht viel kann, auf den Weg gebracht, sondern es wird auf das vorherige aufgebaut.

Es stellt sich nach meiner Meinung die Frage, ob es nicht sinnvoller ist, das bestehende zu verbessern und nicht etwas völlig neues anderes nachzuschieben. 


bike


----------



## Thomas_v2.1 (19 April 2011)

bike schrieb:


> Ich brauche keine 10MB Code bei Siemens und auch nicht generieren, da mit dem Speichern übersetzt wird.


Beim Speichern wird übersetzt? Redest du hier von AWL? Du möchtest doch jetzt nicht ernsthaft AWL mit einer objektorientierten Hochsprache vergleichen oder?
Bezüglich Übersetzungsdauer kannst du dir ja mal die aktuelle Oscat-Bibliothek herunterladen und komplett übersetzen. Da ist Däumchendrehen angesagt. Und das sind ca. 300 kB Code inklusive Siemens-Bibliotheksbausteinen.


----------



## bike (19 April 2011)

Thomas_v2.1 schrieb:


> Beim Speichern wird übersetzt? Redest du hier von AWL? Du möchtest doch jetzt nicht ernsthaft AWL mit einer objektorientierten Hochsprache vergleichen oder?
> Bezüglich Übersetzungsdauer kannst du dir ja mal die aktuelle Oscat-Bibliothek herunterladen und komplett übersetzen. Da ist Däumchendrehen angesagt. Und das sind ca. 300 kB Code inklusive Siemens-Bibliotheksbausteinen.



Ich vergleiche PLC Programmierung mit PLC Programmierung.
Und wie es in der Praxis an der Maschine ist.
Wenn du mir sagst, codesys ist Hochsprache und keine Entwicklungsumgebung für PLC Programme, dann okay.
Mir ist doch völlig egal wie das genannt wird, es muss funktionieren.


bike


----------



## Thomas_v2.1 (19 April 2011)

bike schrieb:


> Ich vergleiche PLC Programmierung mit PLC Programmierung.
> Und wie es in der Praxis an der Maschine ist.
> Wenn du mir sagst, codesys ist Hochsprache und keine Entwicklungsumgebung für PLC Programme, dann okay.
> Mir ist doch völlig egal wie das genannt wird, es muss funktionieren.


Aber das Hauptfeature in V3 ist eben die Möglichkeit objektorientiert zu programmieren. Die vorherigen Versionen funktionieren doch.

Und Codesys V3 beinhaltet schon so viele neue Sprachelemente, dass man schon von einer eigenen Sprache sprechen kann wie ich meine. Leider konnte ich die V3 selber noch nicht benutzen. Ich finde den Weg den Codesys einschlägt aber grundsätzlich richtig, in die SPS-Programmierung auch die Erkenntnisse aus der anderen Programmierwelt einfließen zu lassen.

Sicher gibt es außer der Sprache selber noch viele andere Funktionen die ein SPS-Programmierer braucht um eine Anlage zu betreiben. Hier hat durchaus Siemens noch die Nase vorne.
Wenn man aber die Neuerungen von Codesys V3 und Siemens TIA vergleicht, sieht man worauf die Hersteller setzen: Siemens setzt mit TIA eher auf den programmierenden Elektriker (Drag&Drop, schöne Bildchen, möglichst viel zusammenklicken), für Codesys V3 wird man eher Begeisterung bei reinen Programmierern finden.

Wenn sich irgendwann herausstellen sollte dass objektiorientierung für die SPS-Welt nichts ist - dann soll es meinetwegen so sein. AWL ist aber garantiert nicht der Weisheit letzter Schluss.


----------



## bike (19 April 2011)

Thomas_v2.1 schrieb:


> Wenn sich irgendwann herausstellen sollte dass objektiorientierung für die SPS-Welt nichts ist - dann soll es meinetwegen so sein. AWL ist aber garantiert nicht der Weisheit letzter Schluss.



Da geh ich mit dir völlig konform.
Jedoch ist es immer noch so, dass wir für unsere Kunden entwickeln.
Und es sind eben Elektriker, die die Anlagen betreuen dürfen/müssen.
Und zu TIA verkneif ich mir einen Kommentar. *ROFL*

Doch eines ist auch klar, je mehr Zeilen ein Programm hat, um so größer ist die Wahrscheinlichkeit, dass Fehler vorhanden sind.
Und wenn der PC zu hause abschmiert ist das die eine Seite, doch wenn beim Werkzeugwechsel ein Neustart erfolgen muss, dann wird es teuer,
In einem Programm in FUP/KOP kann die Logik besser darstellen und  man Fehler besser finden.
Und wer schon Fanuc Ladder programmiert hat, der genießt AWL 


bike


----------



## Dummy (19 April 2011)

Thomas_v2.1 schrieb:


> Aber das Hauptfeature in V3 ist eben die Möglichkeit objektorientiert zu programmieren. Die vorherigen Versionen funktionieren doch.
> 
> Und Codesys V3 beinhaltet schon so viele neue Sprachelemente, dass man schon von einer eigenen Sprache sprechen kann wie ich meine. Leider konnte ich die V3 selber noch nicht benutzen. Ich finde den Weg den Codesys einschlägt aber grundsätzlich richtig, in die SPS-Programmierung auch die Erkenntnisse aus der anderen Programmierwelt einfließen zu lassen.
> 
> ...



Halllo Thomas,

ich habe auf der Hannover Messe den  gleichen Eindruck wie Du bekommen.
Das TIA-Portal ist aus meiner Sicht für Instandhalter gemacht und soll mit seinem tollen Äußeren dem Endscheider in der Fabrik vermitteln, dass damit jeder von der Straße  Maschinen/Anlagen Programmieren kann.

Ist wahrscheinlich auch der letzte Trumpf von Siemens, dass viele Maschinen und Anlagen Betreiber voll auf Siemens setzen. 

Was den Stand der Technik angeht, wo hat Siemens denn noch die Nase vorn?

Gruß

dummy


----------



## MSB (19 April 2011)

Dummy schrieb:


> Was den Stand der Technik angeht, wo hat Siemens denn noch die Nase vorn?


Ich sach mal so, im realen Handling, insbesondere wenn die Maschine mal ein paar Jährchen alt ist,
sind klassische Programmiersprachen als Siemens-AWL/KOP/FUP oder auch Sachen wie Mitsubishi AWL/KOP etc.
mit einigem Abstand am besten wartbar ... weit vor jedem beliebigen IEC System welches mir bisher begegnet wäre.

Ich persönlich sehe beide Seiten, weil ich mich auch auf beiden Seiten rumtreibe ...

Als Programmierer liebe ich die Features die mir Codesys bietet (meistens jedenfalls),
als Dienstleister der auch Software-Instandhaltung für div. Industriebetriebe macht,
liebe ich die vergleichsweise durchschaubare Programmierweise, die ich in Siemens-Steuerungen vorfinde,
insbesondere die Tatsache auch notfalls mal etwas in einem AG-Abzug nachzuvollziehen ist absolut großartig.

Aus der Sicht als Instandhalter ist es auch absolut tötlich, wenn man nicht vorhersagen kann,
ob das Projekt welches man gerade vor sich hat, auch tatsächlich dem in der Maschine entspricht,
auch hier haben die etwas betagten Systeme die Nase meilenweit vorne.

Mfg
Manuel


----------



## bike (19 April 2011)

Dummy schrieb:


> Ist wahrscheinlich auch der letzte Trumpf von  Siemens, dass viele Maschinen und Anlagen Betreiber voll auf Siemens  setzen.
> 
> Was den Stand der Technik angeht, wo hat Siemens denn noch die Nase vorn?



Siemens hat zum Beispiel bei CNC und PLS die Nase weit vorn.
Anlagen in Fernost und Stillstand, was nun? Siemens habe ich in 24Stunden vor Ort und der Kunde kann produzieren. Das ist ein entscheidender Vorteil.




MSB schrieb:


> Ich sach mal so, im realen Handling, insbesondere wenn die Maschine mal ein paar Jährchen alt ist,
> sind klassische Programmiersprachen als Siemens-AWL/KOP/FUP oder auch Sachen wie Mitsubishi AWL/KOP etc.
> mit einigem Abstand am besten wartbar ... weit vor jedem beliebigen IEC System welches mir bisher begegnet wäre.
> 
> ...



Dieser Aussage kann ich zu 100% zustimmen.
Wenn ich heute irgend eine IEC Programmentwicklungsumgebung  habe, wer sagt, dass ich das in 10 Jahren die Programme noch warten kann?
S5 Programme aus den achtziger Jahren letztes Jahrhundert kann ich heute noch ändern und dem Kunden helfen, weiter zu produzieren. 

Bei dieser ganzen Diskussion fällt mir auf, dass nicht der Kunde und dessen Bedürfnisse im Vordergrund stehen.

bike


----------



## Dummy (19 April 2011)

bike schrieb:


> Siemens hat zum Beispiel bei CNC und PLS die Nase weit vorn.
> Anlagen in Fernost und Stillstand, was nun? Siemens habe ich in 24Stunden vor Ort und der Kunde kann produzieren. Das ist ein entscheidender Vorteil.
> 
> 
> ...



Hallo Bike,

ja z.B. die 840D ist ne schöne Steuerung, da sind wir mal einer Meinung.
Ansonsten kann ich Dir nicht folgen.
Die Bedürfnisse des Kunden sind doch Produzieren und damit Geld verdienen.

Ich hab noch keinen Kunden gesehen, der mit Programmierung sein Geld verdient und wenn er zur Instandhaltung in das Programm schauen muss ist vorher schon was schief gelaufen.

Bei irgendwelchen exotischen Sondermaschinen mag es vielleicht Sinn ergeben. Ansonsten sollte der Maschinen- und Anlagenbauer mal seine Hausaufgaben machen.

Gruß

dummy


----------



## MSB (19 April 2011)

Dummy schrieb:


> Die Bedürfnisse des Kunden sind doch Produzieren und damit Geld verdienen.


Richtig, das ganze aber 15-20 Jahre lang, wenn man sich mal vor Augen führt welch beträchtliche Zahl an
Ur-Ur-Ur-Alt S5en 150W, S3 und Co noch draußen rumschwirrt, sogar noch länger.

Mit jedem Teil welches in der Zeit verreckt steigt die Wahrscheinlichkeit das man an der Software was ändern muss,
oder selbige auf irgendwas portieren muss.

Mfg
Manuel


----------



## bike (19 April 2011)

Dummy schrieb:


> Hallo Bike,
> 
> ja z.B. die 840D ist ne schöne Steuerung, da sind wir mal einer Meinung.
> Ansonsten kann ich Dir nicht folgen.
> ...




Wenn du Programme schreibst in die man nie wegen Störungen schauen muss, dann bist du der Superprogrammierer auf den der Maschinenbau gewartet hat. 

Wie war das? Ein Programmcode mit mehr als 10 Zeilen ist nicht mehr garantiert zu 100% fehlerfrei. 

Wir bauen auch Serienmaschinen, doch wenn die einmal stehen bleiben, dann müssen der Kunde oder der Servicetechniker oder wir im Programm den Fehler suchen und dann beheben. Alle Eventualitäten kann man eben nicht testen. 

Und die Illusion, dass eine Maschine einmal gebaut und dann bis zum Schrottplatz nichts mehr geändert wird ist auch Vergangenheit.


bike


----------



## rostiger Nagel (19 April 2011)

MSB schrieb:


> Richtig, das ganze aber 15-20 Jahre lang, wenn man sich mal vor Augen führt welch beträchtliche Zahl an
> Ur-Ur-Ur-Alt S5en 150W, S3 und Co noch draußen rumschwirrt, sogar noch länger.
> 
> Mit jedem Teil welches in der Zeit verreckt steigt die Wahrscheinlichkeit das man an der Software was ändern muss,
> ...



Hallo Manuel,
ich beschäftige mich sehr stark mit Retrofit,
eins was ich in den über 20 Jahren wo ich es
mache ist, als aller erstes den alten Schaltplan
und die alte Programm Diskette in den Müll zu
Schneisen. Portieren auf neue Technik halte ich
für völlig überflüssig, ich werde nicht versuchen
neue Technik einzubauen und dann das alte Programm
so zu gestalten, das es auch darauf läuft.


----------



## Gerhard Bäurle (20 April 2011)

bike schrieb:


> ....
> Wenn ich heute irgend eine IEC Programmentwicklungsumgebung  habe, wer sagt, dass ich das in 10 Jahren die Programme noch warten kann?
> S5 Programme aus den achtziger Jahren letztes Jahrhundert kann ich heute noch ändern und dem Kunden helfen, weiter zu produzieren.



Hallo,

wenn Du Siemens-gesteuerte Anlagen aus den letzten 30 Jahren 
warten möchtest, benötigst Du doch eine größere Anzahl von
Tools: Step5, Protool, WinCC, Step7 und was sonst nocht. Wenn 
Du ältere Codesys-Applikation warten möchtest, benötigst Du 
ebenfalls die passende Version. Hier sehe ich keinen signifikanten 
Unterschied.



Helmut_von_der_Reparatur schrieb:


> ich beschäftige mich sehr stark mit Retrofit ...



Bei Retrofit nehmt ihr ja aktuelle Technik. Den Kollegen geht
es eher darum, eine 15 Jahr alten Anlage in Teilbereichen zu
modifizieren, ohne das die gesamte Steuerungstechnik 
ausgetauscht werden muss.


----------



## Gerhard Bäurle (20 April 2011)

Dummy schrieb:


> ...
> Die Bedürfnisse des Kunden sind doch Produzieren und damit Geld verdienen.
> 
> Ich hab noch keinen Kunden gesehen, der mit Programmierung sein Geld verdient und wenn er zur Instandhaltung in das Programm schauen muss ist vorher schon was schief gelaufen.



Hallo,

nach meiner Meinung will der Kunde heute gar nicht mehr so
sehr in die Programme seiner Maschinen schauen – heute muss
der Maschinenbauer hier per Fernwartung mehr Verantwortung
für seine Maschine übernehmen – moderne IT macht es möglich.

Vorteil Kunde: minimale Stillstandszeiten durch schnelle Unter-
stützung bei der Fehlersuche und bei Bedienfragen

Vorteile Maschinenbauer: zusätzliche Einnahmequelle durch 
Servicegeschäft und engere Kundenbindung

Nebeneffekt: Dann ist es für den Kunden zweitrangig, welche
Entwicklungswerkzeuge der Maschinenbauer einsetzt, dieser 
kann dann die Werkzeuge einsetzen, die er für am besten
geeignet hält.


----------



## MSB (20 April 2011)

Gerhard Bäurle schrieb:


> Vorteil Kunde: minimale Stillstandszeiten durch schnelle Unter-
> stützung bei der Fehlersuche und bei Bedienfragen
> 
> Vorteile Maschinenbauer: zusätzliche Einnahmequelle durch
> Servicegeschäft und engere Kundenbindung


Ich kann dir einige Maschinen nennen, wo der Maschinenbauer noch nicht mal mehr weiß,
das er sowas jemals gebaut hat, ist auch bei einigen exotischen Siemens-Sonderbaugruppen so.

Zum Vorteil Maschinenbauer:
Leider übertreiben es manche unserer Kollegen bei der zusätzlichen Einnahmequelle auf absolut unverschämte Art und Weise,
das das leider auch nichts bringt ... von einigen Kunden mit Zitat "Die kommen mir nicht mehr aufs Werksgelände ..." ganz zu schweigen.

Vorteil Maschinenbauer:
Der Kunde ist quasi auf beliebige Art und Weise erpressbar, was per se nicht schlimm ist,
aber leider von vielen auf schamlose Art und Weise ausgenutzt wird ...


----------

