- Beiträge
- 14.554
- Reaktionspunkte
- 3.348
-> Hier kostenlos registrieren
Nachdem in der Vergangenheit sehr viel über Siemens und hier vor Allem auch über TIA geschrieben wurde (zum Teil auch von mir) möchte ich mich jetzt einmal an TwinCat 3.x versuchen.
Zu dem Thema hatte ich in der letzten Woche die Gelegenheit einen Lehrgang zu besuchen, da wir für die Zukunft planen, dieses System einzusetzen.
Ich möchte hier einmal versuchen (nach Möglichkeit wertfrei) darzustellen, wie sich das Eine und Andere in dieser Welt für einen bisher eingefleischten Siemens-Programmierer darstellt - ein bißchen auch in der Hoffnung, dass hier nicht nur Forums-Kollegen den Thread mitlesen.
TwinCat läuft als Entwicklungssystem (für die, die das nicht wissen) auf Microsoft Visual Studio - mit diesem System können u.A. auch Applikationen (z.B. in VB.Net oder C#.Net) erstellt werden.
Visual Studio hat für seine Solutions (so heißen die Projekte darunter) u.U. eine recht hohe Ladezeit, hat man es dann aber erstmal geladen dann arbeitet es sich darin recht zügig (um nicht zu sagen : eigentlich ungebremst). Eine ähnliche Performance könnte man unter TIA mit einem Intel i13-Prozessor mit 10 GHz Taktfrequenz (Stand heute) erreichen.
An dieser Stelle sei auch noch erwähnt, dass ich nicht genau weiß, wie und wo die Schnittstelle zwischen dem Codesys von 3S und dem TwinCat von Beckhoff genau ist und wer davon für was verantwortlich zeichnet. Ich weiß nur vom Mitlesen, dass es da eine gewisse Verwandtschafts-Beziehung gibt ...
So ... und jetzt die aus meiner Sicht positiven und negativen Aspekte, die mir so aufgefallen sind. Bestimmt habe ich auch noch Vieles in der Aufzählung vergessen ...
Pos.: Die Hardware läßt sich i.d.R. komplett aus der vorhandenen Installation rücklesen/ überhaupt ins Projekt einlesen.
Es stehen dann auch normalerweise die richtigen Baugruppen in der Liste und nicht irgendwelche HW-Dummi's, wie bei Siemens.
Auch die Topologie wird dabei mit eingelesen.
Neg.: Das Ganze ist in der Projekt-TreeView bei größeren Installationen schnell unübersichtlich.
Pos.: Alles (das Allermeißte) aus der Hardware ist über das PLC-Programm irgenwie ansprechbar und symbolisch zuzuordnen.
Neg.: Die Art und Weise des Anlegens einer Symbol-Tabelle und die anschließende Zuordnung ist EXTREM zeitaufwändig und kompliziert.
Pos.: Es läßt sich für die Hardware in der Symbolik mit Namespaces (Namens-Räumen) arbeiten, die das Programmieren und Wiederfinden einzelner Abschnitte extrem verbessern.
Neg.: Die Namensvergabe der Rubriken (DUT, GLV, POU) ist SEHR gewöhnungsbedürftig. Da hätte man vielleicht auch etwas mit "ein wenig mehr" Klartext machen können - sei es drum ...
Neg.: Das IntelliSense (Vorschlagen von Begrifflichkeiten wie Bausteine und Variablen) ist nicht auf dem Stand dessen, was man gemeinhin von Visual Studio kennt.
Pos.: Man kann von Bausteinen ableiten (Vererbung) und sie mit Aktionen, Methoden und Properties versehen. Das erleichtert die Strukturierung und die Übersichtlichkeit und die Möglichkeiten bei der Programmierung ungemein.
Pos.: Man kann im ST-Editor durch geschicktes Anordnen von Kommentaren und dem Programmcode darunter das Bilden von Code-Regionen erzeugen (Codebereiche können bis auf deren Überschrift minimiert werden).
Pos.: Es lassen sich Enumerationen erzeugen, die bei deren Verwendung im Code bei der Status-Anzeigen nicht mehr den Wert sondern den Enumerations-Namen anzeigen.
Neg.: Strukturen und Enumerationen lassen sich nicht im Baustein deklarieren sondern müssen IMMER global angelegt werden - Hallo ... 21. Jahrhundert ...!?
Pos.: Bei der Status-Anzeige wird bei Verwendung von Stringvariablen auch der String-Inhalt angezeigt.
Neg.: Es lassen sich auf Speicherbereiche andere Sichten mit UNIONS erezugen - auch diese müssen aber global angelegt werden - Global ..!?
Pos.: Alle Deklarationen lassen sich in Unterverzeichnisse und Unter-Unterverzeichnisse) ablegen, was das Projekt übersichtlicher machen kann.
Neg.: So gut der ST-Editor in seiner Ausführung ist (ich nehme an das auf dem von Anfang an der Fokus lag) so unterentwickelt sind die Pendants zu KOP, FUP, AWL.
Da fühlte ich mich doch gleich 25 Jahre jünger - wie zu den "guten alten" S5-Anfangszeiten (und noch schlechter).
Auch die AS (Ablaufsprache - Pendant zu Siemens-Graph) ist m.E. nicht sinnvoll nutzbar da viel zu kompliziert und zeitraubend in der Handhabung.
Pos.: Steuerbarkeit von (ziemlich beliebigen) Servo-Achsen über eigene Funktionsbausteine.
Neg.: Einrichtung der Achse selbst gewöhnungsbedürftig bis teilweise unübersichtlich.
Pos.: Gutes Monitoring des Achs-Verhaltens über integrierte Software-Tools (Oszilloskop).
Neg.: Topologie-Möglichkeiten des EtherCat (gegenüber z.B. ProfiNet) teilweise sehr eingeschränkt (z.B. bezogen auf unsere Anlagen, denen eine sternförmige Topologie entgegen kommt).
Pos.: ADS-Kommunikation zwischen Steuerungen aber auch von Visu zur PLC (über z.B. .Net-Applikation) sehr konfortabel und leicht zu etablieren.
Neg.: Es kann in einer Solution nur ein PLC-Projekt angelegt werden. Das nutzt nicht die Möglichkeiten, die Visual Studio bietet und im .Net-Umfeld auch ermöglicht.
Neg.: Eingebaute Visu ist eher rudimentär, da auch die Darstellungemöglichkeiten sehr eingeschränkt sind.
Pos.: Eingebaute Visu ist als Inbetriebnahme-Hilfsmittel gut einsetzbar.
Neg.: Die für die Versuche zunächst eingesetzte Soft-SPS im Entwicklungssystem ist sehr anfällig kann kann den Rechner bzw. Visual Studio sehr schnell totlegen.
Das Verkaufs-Argument von Beckhoff, dass man Visu und PLC auf dem gleichen Rechner betreiben kann (und auch ruhig sollte), würde ich selbst nur mit Vorsicht betrachten.
Mit einer seperaten CX (embedded PC) hingegen gab es die vorgenannten Probleme gar nicht mehr.
... to be continued ...
Gruß
Larry
Zu dem Thema hatte ich in der letzten Woche die Gelegenheit einen Lehrgang zu besuchen, da wir für die Zukunft planen, dieses System einzusetzen.
Ich möchte hier einmal versuchen (nach Möglichkeit wertfrei) darzustellen, wie sich das Eine und Andere in dieser Welt für einen bisher eingefleischten Siemens-Programmierer darstellt - ein bißchen auch in der Hoffnung, dass hier nicht nur Forums-Kollegen den Thread mitlesen.
TwinCat läuft als Entwicklungssystem (für die, die das nicht wissen) auf Microsoft Visual Studio - mit diesem System können u.A. auch Applikationen (z.B. in VB.Net oder C#.Net) erstellt werden.
Visual Studio hat für seine Solutions (so heißen die Projekte darunter) u.U. eine recht hohe Ladezeit, hat man es dann aber erstmal geladen dann arbeitet es sich darin recht zügig (um nicht zu sagen : eigentlich ungebremst). Eine ähnliche Performance könnte man unter TIA mit einem Intel i13-Prozessor mit 10 GHz Taktfrequenz (Stand heute) erreichen.
An dieser Stelle sei auch noch erwähnt, dass ich nicht genau weiß, wie und wo die Schnittstelle zwischen dem Codesys von 3S und dem TwinCat von Beckhoff genau ist und wer davon für was verantwortlich zeichnet. Ich weiß nur vom Mitlesen, dass es da eine gewisse Verwandtschafts-Beziehung gibt ...
So ... und jetzt die aus meiner Sicht positiven und negativen Aspekte, die mir so aufgefallen sind. Bestimmt habe ich auch noch Vieles in der Aufzählung vergessen ...
Pos.: Die Hardware läßt sich i.d.R. komplett aus der vorhandenen Installation rücklesen/ überhaupt ins Projekt einlesen.
Es stehen dann auch normalerweise die richtigen Baugruppen in der Liste und nicht irgendwelche HW-Dummi's, wie bei Siemens.
Auch die Topologie wird dabei mit eingelesen.
Neg.: Das Ganze ist in der Projekt-TreeView bei größeren Installationen schnell unübersichtlich.
Pos.: Alles (das Allermeißte) aus der Hardware ist über das PLC-Programm irgenwie ansprechbar und symbolisch zuzuordnen.
Neg.: Die Art und Weise des Anlegens einer Symbol-Tabelle und die anschließende Zuordnung ist EXTREM zeitaufwändig und kompliziert.
Pos.: Es läßt sich für die Hardware in der Symbolik mit Namespaces (Namens-Räumen) arbeiten, die das Programmieren und Wiederfinden einzelner Abschnitte extrem verbessern.
Neg.: Die Namensvergabe der Rubriken (DUT, GLV, POU) ist SEHR gewöhnungsbedürftig. Da hätte man vielleicht auch etwas mit "ein wenig mehr" Klartext machen können - sei es drum ...
Neg.: Das IntelliSense (Vorschlagen von Begrifflichkeiten wie Bausteine und Variablen) ist nicht auf dem Stand dessen, was man gemeinhin von Visual Studio kennt.
Pos.: Man kann von Bausteinen ableiten (Vererbung) und sie mit Aktionen, Methoden und Properties versehen. Das erleichtert die Strukturierung und die Übersichtlichkeit und die Möglichkeiten bei der Programmierung ungemein.
Pos.: Man kann im ST-Editor durch geschicktes Anordnen von Kommentaren und dem Programmcode darunter das Bilden von Code-Regionen erzeugen (Codebereiche können bis auf deren Überschrift minimiert werden).
Pos.: Es lassen sich Enumerationen erzeugen, die bei deren Verwendung im Code bei der Status-Anzeigen nicht mehr den Wert sondern den Enumerations-Namen anzeigen.
Neg.: Strukturen und Enumerationen lassen sich nicht im Baustein deklarieren sondern müssen IMMER global angelegt werden - Hallo ... 21. Jahrhundert ...!?
Pos.: Bei der Status-Anzeige wird bei Verwendung von Stringvariablen auch der String-Inhalt angezeigt.
Neg.: Es lassen sich auf Speicherbereiche andere Sichten mit UNIONS erezugen - auch diese müssen aber global angelegt werden - Global ..!?
Pos.: Alle Deklarationen lassen sich in Unterverzeichnisse und Unter-Unterverzeichnisse) ablegen, was das Projekt übersichtlicher machen kann.
Neg.: So gut der ST-Editor in seiner Ausführung ist (ich nehme an das auf dem von Anfang an der Fokus lag) so unterentwickelt sind die Pendants zu KOP, FUP, AWL.
Da fühlte ich mich doch gleich 25 Jahre jünger - wie zu den "guten alten" S5-Anfangszeiten (und noch schlechter).
Auch die AS (Ablaufsprache - Pendant zu Siemens-Graph) ist m.E. nicht sinnvoll nutzbar da viel zu kompliziert und zeitraubend in der Handhabung.
Pos.: Steuerbarkeit von (ziemlich beliebigen) Servo-Achsen über eigene Funktionsbausteine.
Neg.: Einrichtung der Achse selbst gewöhnungsbedürftig bis teilweise unübersichtlich.
Pos.: Gutes Monitoring des Achs-Verhaltens über integrierte Software-Tools (Oszilloskop).
Neg.: Topologie-Möglichkeiten des EtherCat (gegenüber z.B. ProfiNet) teilweise sehr eingeschränkt (z.B. bezogen auf unsere Anlagen, denen eine sternförmige Topologie entgegen kommt).
Pos.: ADS-Kommunikation zwischen Steuerungen aber auch von Visu zur PLC (über z.B. .Net-Applikation) sehr konfortabel und leicht zu etablieren.
Neg.: Es kann in einer Solution nur ein PLC-Projekt angelegt werden. Das nutzt nicht die Möglichkeiten, die Visual Studio bietet und im .Net-Umfeld auch ermöglicht.
Neg.: Eingebaute Visu ist eher rudimentär, da auch die Darstellungemöglichkeiten sehr eingeschränkt sind.
Pos.: Eingebaute Visu ist als Inbetriebnahme-Hilfsmittel gut einsetzbar.
Neg.: Die für die Versuche zunächst eingesetzte Soft-SPS im Entwicklungssystem ist sehr anfällig kann kann den Rechner bzw. Visual Studio sehr schnell totlegen.
Das Verkaufs-Argument von Beckhoff, dass man Visu und PLC auf dem gleichen Rechner betreiben kann (und auch ruhig sollte), würde ich selbst nur mit Vorsicht betrachten.
Mit einer seperaten CX (embedded PC) hingegen gab es die vorgenannten Probleme gar nicht mehr.
... to be continued ...
Gruß
Larry