# TwinCat V3.x versus Siemens



## Larry Laffer (18 August 2015)

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


----------



## JesperMP (18 August 2015)

Sehr interessant.

Wie ist es mit Hardware Diagnosefunktionen ?
Wie ist es mit Software Diagnosefunktionen ? Z.B. wie bei die STACKS in S7 wo man zu den Ort im Program springen kann, wo den Fehler auftauchte.
Wie ist es mit laden von Programbausteine mit geänderte Deklarationen. Gehen die Online Aktualdaten verloren oder behalten ? (habe gehört das Twincat/3S hier besser ist als S7).
Besonders der Handhabung von Änderungen auf ein laufende Program interessiert mich.


----------



## BrainArni (18 August 2015)

Moin moin,

ich arbeite seit ca. einem 3/4 Jahr mit einer CX2030  und Twincat 3. Ich stimme den meisten Punkten von Larry zu, diese decken  sich mit den Erfahrungen die ich gemacht habe. 

Mein Anmerkungen  dazu sind, dass die EtherCat-Topologie frei ist. Ein kurzer Blick auf  die Beckhoff-Seite in die Kategorie Ethercat wird das bestätigen.

Die Tatsache, dass Strukturen, Unions und Enumerationen "nur" global  angelegt werden können, empfinde ich nicht unbedingt als Nachteil, die  Tatsache, dass es überhaupt möglich ist, ist schon ein Meilenstein.

Bisher  waren SPS-Programmiertools eine eigene Welt, mit Twincat 3 ist es  Beckhoff, meiner Meinung nach, gelungen ein Schritt in die Richtung der  heutigen normalen Programmier-tools zu machen.

Zur Hardware-Diagnose, kann ich noch nichts sagen, war noch nicht notwendig.
Um  die Software zu analysieren hast du Möglichkeit die Variablen zu  beobachten und zu forcen, zusätzlich kannst du Breakpoints nutzen um  dein Programm anzuhalten. 
Mit den Beckhoff "ADS Return Codes" kannst du relativ gut Fehler von Beckhoff Basuteinen (z.B. Systemfunktionen) nachvollziehen.

Bei  Funktionsbausteinen gibt es immer die Methoden "FB_Init", "FB_Reinit"  "FB_Exit" mit Hilfe dieser 3 Methoden kannst, musst du aber nicht, das  Verhalten deiner FB's genau definieren. Mit dem "FB_Reinit" kannst du  das Verhalten deiner FB's bei einem Oline change beeinflussen.


----------



## Larry Laffer (18 August 2015)

Also zur Diagnose kann ich mangels wirklicher Erfahrung mit TC noch nicht viel sagen.
Bei der Diagnose der EtherCat-Teilnehmer kommt es darauf an, welchen Typs der Teilnehmer ist - es gibt da 2 Sorten. Die "echten" EtherCat"-Slaves kann du sehr präzise diagnostizieren.
Bei der Programm-Diagnose ist es sehr einfach ein die Instanz eines FB's zu kommen - lange nicht so umständlich wie bei Siemens.
Zu Fehler-Stacks kann ich mich derzeit auch noch nicht äußern.

@BrainArni:
Das man heutzutage mit Strukturen etc. arbeiten kann empfinde ich nicht als Meilenstein sondern als selbstverständlich. ich fände es aber, allein wegen Übersichtlichkeit, schon besser, wenn man Strukturen und auch Enum's dort deklarieren kann (nicht muss) wo sie gebraucht werden. Das heißt nicht, dass es nicht auch globale geben kann und soll.
Die EtherCat-Topologie ist nicht frei. Du kannst nicht einfach einen Switch dazwischen packen und weiter geht's. Das heißt jetzt nicht, dass das nicht lösbar wäre - die Spielregeln von PN und EC sind hier halt nur anders ...

Gruß
Larry


Nachsatz:
Was ich im Eingangs-Beitrag nicht erwähnt hatte : Als SCL-Programmierer hatte ich überhaupt keine Probleme mich im ST von Beckhoff zurecht zu finden. Ein paar Sachen sind ein bißchen anders - aber das hat man m.E. sehr schnell.


----------



## Thomas64 (18 August 2015)

Hallo Larry,

hier ein paar Ergänzungen zu deiner Liste: 

Neg.: Strukturen und Enumerationen lassen sich nicht im Baustein deklarieren sondern müssen IMMER global angelegt werden - Hallo ... 21. Jahrhundert ...!?
Neg.: Es lassen sich auf Speicherbereiche andere Sichten mit UNIONS erzugen - auch diese müssen aber global angelegt werden - Global ..!?

-> Die Implementation von: Enumerationen, Unions und Strukturen sind genauso Global wie die von Funktionen, Interfaces und Funktionsbausteinen. Wo diese und wie viele Instanzen dann davon abgeleitet werden, ist dann Applikationsabhängig und kann natürlich auch lokal geschehen.

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).

-> Wenn du EtherCAT Abgangsklemmen (z.B. EK1122, gibst auch für LWL) hinter einander steckst oder einen Sternverteiler mit 7 Abgängen (CU1128) nutzt, und dann noch mit HotConnect Gruppen arbeitest, kannst du sogar im Betrieb quasi beliebig viele deiner "Sterne" umpatchen.

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.

-> Du kannst soviele PLCs anlegen wie der Speicher und die Performance es zulassen, nur die Anzahl der Task an die diese gebunden werden sind begrenzt. Zur besseren Auslastung können dann die PLCs auf die einzelnen Cores deiner CPU verteilt werden.


----------



## MasterOhh (18 August 2015)

Ich denke Codesys V3 und TwinCAT 3 haben so gut wie garnichts mehr (ausser die in den Normen festgelegten Programmiersprachen) gemeinsam. Das es mal eine engere Verzahnung gab, sieht man nur noch an den Editoren von TwinCAT 2 und Codesys 2, die doch noch sehr ähnlich sind.

Es gibt EtherCAT Sternverteiler (CU1128) oder EtherCAT Abzweige (EK1122) die durch ein ihre interne Verschaltung eine Sterntopologie nach Außen simulieren können. D.h. für dich ist der EtherCAT Bus als Stern aufgebaut, intern werden die Frames jedoch als Linie geführt. EtherCAT ist nun mal ein Bus bei dem das Hauptaugenmerk auf Geschwindigkeit liegt und das geht halt am besten wenn die Pakete nicht zwischendrin an irgendwelchen Switchen rumgammeln müssen. Hot-Connect fähige Teilnehmer und Bus-Stänge kannst du auch im laufenden Betrieb ab- und ankoppeln.

Visu und PLC können auf dem gleichen Rechner laufen, sollte halt nur nicht irgend eine Officemöhre sein, auf der noch zig millionen andere Anwendungen laufen und der Echtzeitvirenscanner im Hintergrund rödelt. Bei uns läuft sogar auf den mittlerweile recht betagten CX9001er die Visu mit auf der SPS (irgend ein Touchscreen angeschlossen und los gehts).

@ Larry
Welchen Lehrgang für TC3 hast du genau besucht? Ich bin immernoch am überlegen ob sich für mich so ein 3 Tage Umstiegskurs von TC2 auf TC3 lohnen könnte. Hab halt immer nur Angst, das ich da in 3 Tagen für teures Geld das gleiche vermittelt bekomme, was ich mir in 7 Tagen auch alleine aneignen könnte...


----------



## silverfreaky (18 August 2015)

Wo läuft es eigentlich hin das ganze, wenn man aus der Siemenswelt kommt und was dazu lernen will?.

Sollte man Codesys lernen,Twin Cat oder Beckhoff?Habe gerade das neueste Codesys runtergeladen.Wie lade ich da die Oscat Bibliothek die ich runtergeladen habe?
Bin totaler Anfänger.


----------



## Larry Laffer (18 August 2015)

Hallo Thomas,

Danke erstmal für deine Anmerkungen.
Vielleicht  ein Hinweis zur Benutzung des Forums : zum Zitieren von Beiträge (quasi  als Verweis auf Textpassagen) gibt es unter jedem Beitrag den Button  "Zitieren" bzw. für allgemeine Zitate des Zitat-Button (sieht aus wie  eine Sprechblase) im Beitrags-Editor.




Thomas64 schrieb:


> Die Implementation von: Enumerationen, Unions und Strukturen sind  genauso Global wie die von Funktionen, Interfaces und  Funktionsbausteinen. Wo diese und wie viele Instanzen dann davon  abgeleitet werden, ist dann Applikationsabhängig und kann natürlich auch  lokal geschehen.



Wenn ich von Global und Lokal geschrieben  habe dann meinte ich mit Global := allgemein im Projekt und mit Lokal :=  im Deklarationsteil des jeweiligen Bausteins.
Mein TwinCat (V3.1)  kann Strukturen und Enum's nur Global verwalten und nicht in einem  Baustein (quasi wie eine Verzeichnis-Struktur).
Dies ist eine  Funktionalität, die ich zur besseren Gliederung der Variablenbereiche  eines Bausteins (quasi als Namespace-Festlegung) sehr häufig nutze (bei Siemens).
Bei  Beckhoff läßt sich das natürlich irgendwie dann auch machen - es macht  ein Projekt, dass dann zwangsläufig seeeeehr viele Strukturen bekommt  aber sehr schnell unübersichtlich ...




Thomas64 schrieb:


> Du kannst  soviele PLCs anlegen wie der Speicher und die Performance es zulassen,  nur die Anzahl der Task an die diese gebunden werden sind begrenzt. Zur  besseren Auslastung können dann die PLCs auf die einzelnen Cores deiner  CPU verteilt werden.


In meiner TwinCat-Version kann ich auch  mehrere PLC-Projekte anlegen - es funktioniert dann nur keines mehr (das  ist irgendein TC-Problem, auch laut unseres Dozenten).
Was mehrere  PLC-Projekte mit der Performance und dem Speicher meines Rechners zu tun  haben kann ich im Augneblick nicht nachvollziehen. Ich sprach nicht von  mehreren gleichzeitig laufenden PLC-Runtimes auf dem gleichen System  (soweit so etwas überhaupt realisierbar ist).

Gruß
Larry


----------



## Larry Laffer (18 August 2015)

MasterOhh schrieb:


> @ Larry
> Welchen Lehrgang für TC3 hast du genau besucht? Ich bin immernoch am  überlegen ob sich für mich so ein 3 Tage Umstiegskurs von TC2 auf TC3  lohnen könnte. Hab halt immer nur Angst, das ich da in 3 Tagen für  teures Geld das gleiche vermittelt bekomme, was ich mir in 7 Tagen auch  alleine aneignen könnte...



Da bin ich mir gerade nicht  sicher - ich denke, es war der TR1000 - es könnte aber auch der TR3030  gewesen sein. Das kann ich aber im Bedarfsfall morgen noch nachreichen.
Hinsichtlich  deiner Befürchtung kann ich dich nicht beruhigen. So, wie ich dich aus  deinen bisherigen Beiträge kennen gelernt habe, könnte ich mir gut  vorstellen, dass du dir den Umstieg (ggf. mit 1 oder 2 Rückfragen im  Forum) auch gut selbst anlernen kannst.
Für mich war die eigentliche  Programmierung auch nicht das Neue sondern mehr das Beckhoff-spezifische  Drum-herum - vor Allem soweit es nicht mit Siemens vergleichbar war -  und ich denke, den Teil kennst du ja schon ...
Was allerdings das genannte "Beckhoff-spezifische Drum-herum" angeht so fürchte ich, dass es mit *meinen *Fragen da mit *meinem *ersten Beckhoff-Projekt erst richtig losgehen wird ... 8)

Gruß
Larry


----------



## Larry Laffer (18 August 2015)

silverfreaky schrieb:


> Wo läuft es eigentlich hin das ganze, wenn man aus der Siemenswelt kommt und was dazu lernen will?.
> 
> Sollte man Codesys lernen,Twin Cat oder Beckhoff?Habe gerade das neueste Codesys runtergeladen.Wie lade ich da die Oscat Bibliothek die ich runtergeladen habe?
> Bin totaler Anfänger.



Diese Frage ist aus meiner Sicht gar nicht zu beantworteten.
Welches System an den Start kommt entscheidet u.U. ja dein Kunde.
Bist du frei darin, das für dich selbst zu entscheiden, dann solltest du das aus meiner Sicht nach Abwägung von Vor- und Nachteilen, die jedes System hat, tun. Das system, das dir am Meißten entgegen kommt / für deine Anwendung passt, dass solltest du nehmen ...

Gruß
Larry


----------



## Thomas64 (18 August 2015)

silverfreaky schrieb:


> Wo läuft es eigentlich hin das ganze, wenn man aus der Siemenswelt kommt und was dazu lernen will?.
> 
> Sollte man Codesys lernen,Twin Cat oder Beckhoff?Habe gerade das neueste Codesys runtergeladen.Wie lade ich da die Oscat Bibliothek die ich runtergeladen habe?
> Bin totaler Anfänger.



Vielleicht noch ein Hinweis zu TwinCAT3 und Codesys: Innerhalb von TwinCAT 3 stellen die Editoren von Codesys nur noch einen kleinen (aber zentralen) Teil der Entwicklungsumgebung. 

Die Antriebsanteile bis zur CNC, Robotic, der Safty-Editor, die Möglichkeit in Echtzeit mit C/C++ zu programmieren, Mathlab/Simulink, .NET Programmierung und vieles andere mehr fehlen hier noch im Vergleich der Umgebungen.




Larry Laffer schrieb:


> 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).



Zu Profinet sollte noch ergänzt werden: TC3 unterstütz über 30 Protokollen (RT und nicht RT), dazu gehört auch Profinet bis Class C (IRT), Siemens unterstütz jedoch EtherCAT und viele weitere nicht.
Ich sehe hier den Vorteil bei TC3 in der höheren Flexibilität, denn ich kann hier die Protokolle bunt mischen und damit auch ganz einfach ein Gateway realisieren.


----------



## norustnotrust (18 August 2015)

Tolle Auflistung!

Was meiner Ansicht nach auf der Pos. Seite noch fehlt (obwohl es in einem Punkt implizit drinnen ist) sind ein paar Vorteile die Visual Studio an sich mitbringt wie:
- Integration von Standard CV-Systemen (TFS, git, subversion)
- Integration von Issue Tracking Tools in die Entwicklungsumgebung.


----------



## silverfreaky (18 August 2015)

Wo kommt dann TwinCat3 zum Einsatz?Ich sehe irgendwie noch nicht wo man den objektorintierten Ansatz verwenden kann in der Steuerungstechnik.


----------



## oliver.tonn (18 August 2015)

Bei meinem jetzigen Auftraggeber wird TwinCAT 3 eingesetzt. Dieser baut unter anderem Anlagen für die Solarzellenfertigung, für die Herstellung von CIGS Modulen und für Lion-Akkus. Es wird dort mit Vererbung gearbeitet und Methoden genutzt.

Von irgendwas mit Internetzugang gesendet.


----------



## Larry Laffer (19 August 2015)

silverfreaky schrieb:


> Wo kommt dann TwinCat3 zum Einsatz?Ich sehe irgendwie noch nicht wo man den objektorintierten Ansatz verwenden kann in der Steuerungstechnik.



Das kommt auf deine Aufgaben an - bei mir ist OOP das Thema schlechthin. In Folge dessen ist Alles, das mir da entgegen kommt für mich wie gemacht ...


----------



## Larry Laffer (19 August 2015)

@NRNT:
Das Visual Studio eine tolle Sache ist steht doch wohl außen vor.
Damit läßt sich sogar noch mehr anfangen als du erwähnt hast - wir haben z.B. auch eine .Net-basierte Visu ... 8)

Gruß
Larry


----------



## rostiger Nagel (19 August 2015)

Larry Laffer schrieb:


> wir haben z.B. auch eine .Net-basierte Visu ...



Die machst du dann aber über ADS oder hast du da noch einen externen wie Inosoft drin?


----------



## rostiger Nagel (19 August 2015)

@Ralf,
vielleicht kannst du auch noch ein wenig dazu schreiben, warum ihr letzendlich auf Beckhoff umsteigt.
Ich weiß ja das du eigendlich Siemens eingesetzt hast, so ein Umstieg muß ja tiefgreifende gründe gehabt 
haben.


----------



## mac203 (19 August 2015)

Larry Laffer schrieb:


> Hallo Thomas,
> 
> In meiner TwinCat-Version kann ich auch  mehrere PLC-Projekte anlegen - es funktioniert dann nur keines mehr (das  ist irgendein TC-Problem, auch laut unseres Dozenten).
> Was mehrere  PLC-Projekte mit der Performance und dem Speicher meines Rechners zu tun  haben kann ich im Augneblick nicht nachvollziehen. Ich sprach nicht von  mehreren gleichzeitig laufenden PLC-Runtimes auf dem gleichen System  (soweit so etwas überhaupt realisierbar ist).
> ...



*Das stimmt so definitiv nicht!*
Da würde mich schon interessieren, wer das in einem TR3030 / TR3040 behauptet hat.

Du kannst, wie schon zuvor beschrieben eine Vielzahl von PLC-Projekten (<>TwinCAT Projekte) in einer Solution anlegen.
Diese PLC-Projekte können alle aktiv sein, also als eigenständiges TcCOM-Objekt PLC im Echtzeitmodus laufen oder aber einfach nur vorhanden sein und nach belieben aktiviert werden.
Letztlich ist das eine Frage des objektorientierten Ansatzes, wie man sein TwinCAT Projekt (nicht das PLC Projekt) auslegt. Manch einer sieht in den Objekten einzelne TcCOM-Objekte (der PLC). Ein anderer hat den Ansatz innerhalb eines TcCOM-Objekts der PLC.*
Also noch mal: Es gab keine TwinCAT Version, in der man nur ein PLC-Projekt anlegen kann!

*Vielleicht noch eine kruze Anmerkung zum Thema VISU und PLC auf dem gleichen System:
Auch das ist schon lange Zeit bei Beckhoff so üblich und wird bei sehr vielen Projekten so realisiert.
In 80% der Fälle "lacht" der IPC über die Arbeit, die er da zu tun hat.
Gerade mit TwinCAT3, der Aufteilung auf mehere Cores und der Core-Isolation, ist die Verteilung der Performance sehr gut handlen.

Gruß,
mac203


----------



## Larry Laffer (19 August 2015)

@mac:
Es war ein TR3030 und der Schulungsleiter hies Laker ...
Entstanden ist die ganze Sache dadurch, dass wir ein neues Projekt anlegen wollten (gleich am Anfang) und ich das, so nach gute alter VS-Manier und dem schon vorhandenen anlegen wollte bzw. auch gemacht habe - mich dann nur nicht mehr mit der Hardware verbinden konnte. Darauf hies es dann, dass das angeblich nicht (oder noch nicht) funktioniert. Ich habe das an der Stelle nicht weiter in Frage gestellt ...

@Helmut:
Wir setzen es in Verbindung mit Inosoft ein. Ich muss dir allerdings Recht geben, dass man auf Basis der ADS-Geschichte sich auch recht schnell einen Item-Server selbst erstellen könnte. Bliebe nur noch die Geschichte an die SPS-Variablen (namentlich) dranzukommen - also nicht erst im Projekt nachzuschauen, wie sie heißen sondern sie über einen Browser reingereicht zu bekommen. Um das als Funktion in VS für VS zu erstellen fehlt mir (ggf. zur Zeit noch) der Background.

Warum wollen wir umschwenken ...? Vielleicht weil wir mir Herrn Siemens und TIA ein-zwei Mal zu oft auf die Nase gefallen sind (am Anfang). Und wenn ich hier so mitlese dann ist das TIA-Thema ja auch nach wie vor nicht durch ...
Ob das so richtig ist wird sich zeigen ... Für mich ist es so, dass ich aus unterschiedlichen Gründen sowieso schon immer gern etwas mehr über TC wissen wollte.

Gruß
Larry


----------



## mac203 (19 August 2015)

Larry Laffer schrieb:


> @mac:
> Es war ein TR3030 und der Schulungsleiter hies Laker ...
> Entstanden ist die ganze Sache dadurch, dass wir ein neues Projekt anlegen wollten (gleich am Anfang) und ich das, so nach gute alter VS-Manier und dem schon vorhandenen anlegen wollte bzw. auch gemacht habe - mich dann nur nicht mehr mit der Hardware verbinden konnte. Darauf hies es dann, dass das angeblich nicht (oder noch nicht) funktioniert. Ich habe das an der Stelle nicht weiter in Frage gestellt ...
> 
> ...



Okay....
Ich denke, da hast du dann TwinCAT-Projekt und PLC-Projekt verwechselt.
Aktuell kann man tatsächlich nur ein "aktives" TwinCAT-Projekt in einer Projektmappe haben.
In diesem TwinCAT-Projekt aber mehrere aktive oder inaktive PLC-Projekte.
Der Aufbau ist also wie so zu sehen
+ Solution
 - TwinCAT Projekt (aktiv, geladen)
      * Plc Projekt 1
      * Plc Projekt 2
      * C++ Projekt 1
      * sonstiges
 - .Net Projekt
 - sonstiges Projekt
 - TwinCAT Projekt (inaktiv, entladen)


Gruß,
mac203


----------



## Larry Laffer (19 August 2015)

OK ... also das Richtige gemeint und das Falsche geschrieben ... ich schiebe das mal auf meine noch geringe Erfahrung mit der TwinCat-Benennungswelt ...


----------



## mac203 (20 August 2015)

Ist ja okay....wollte das nur nicht falsch verstanden wissen!


----------



## leoleo (21 August 2015)

Hallo,
Neg.: Das Ganze ist in der Projekt-TreeView bei größeren Installationen schnell unübersichtlich.
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 ...
TwinCat ist übersichtlich. Du definierst pro Modul Datentypen und dann globale Variablen. Tree View hat alles:Servo Achsen, Hardware Kofiguration, Software, etc...Alles in einer Solution!!!!!
Neg.: Strukturen und Enumerationen lassen sich nicht im Baustein  deklarieren sondern müssen IMMER global angelegt werden - Hallo ... 21.  Jahrhundert ...!?
Das ist eher Vorteil. Z.B ich habe eine Struktur Axis (definiert alles was eine Achse Achse braucht). Dann definiere ich die Struktur global und verwende in allen FB. Ganze Software hat gleiche Achsenstruktur.
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.
Falls du mit ST Editior programmierst, dann solltest du andere Editoren vergessen (ausser eventuell AS)
Neg.: Einrichtung der Achse selbst gewöhnungsbedürftig bis teilweise unübersichtlich.
Das stimmt einfach nicht. Ausserdem du steuerst ein Servo oder Schrittmotor als Software Entwickler mit PLC Open Funktionen sehr einfach. Ich kenne keine andere Firma wo die Schrittmotoren so gut gemacht sind.

Und big PLUS: SPS von Beckhoff ist ein PC, Windows PC. Du kannst auf einem PC auch andere Visualisierung laufen lassen, Team Viewer usw. Alles gratis!!!!

Gruss,

Leo , der Erfahrene


----------



## Larry Laffer (21 August 2015)

@Leo:
Ich bin nicht unbedingt jemand der die Dinge so hinnimmt wie sie sind ...
- In der heutigen Zeit müssen Programme/Anwendungen nicht mehr unübersichtlich sein.
- meine Aufstellung sollte eine Art Gegenüberstellung UND Anregung für die Zukunft sein - deshalb :
- Strukturen und Enums dürfen natürlich auch global vorhanden sein - sie sollten aber auch lokal anlegbar sein - man kann natürlich auch immer den einfachsten Weg gehen - aber muß man das ?
- Ich bin ST-Programmierer. Dennoch war ich sehr erschrocken, dass die anderen Editoren (auch der AS-Editor) so schlecht und schwer handhabbar waren ...
- Für mich war die Einrichtung gewöhnungsbedürftig bis unübersichtlich - ich vergleiche hier. Wie schon in Punkt 1 geschrieben - heute muss nichts mehr unübersichtlich sein.
- Schrittmotoren sind für mich kein Maßstab. Die gehören FÜR MICH in eine frühere Zeit ...

Gruß
Larry


----------



## leoleo (21 August 2015)

Die Programme sind nicht unübersichtlich. CoDeSys bietet gute Möglichkeiten die Module zu kapseln und sehr übersichtlich zu programmieren.Schrittmotoren sind heute sehr wichtig weil diese in vielen Anwendungen ersetzen Servo sehr gut (ein TOP Schrittmotor kostet max. 80 Euro, Servo=300-400 Euro). Sehr wichtig, vor allem gegen China.
Strukturen und Enums können lokal sein. Aber das ist doch kein gewaltiges Nachteil.
Ich programmiere CoDeSys seit 7 Jahren und noch nie habe ich Bedarf nach KOP, FUP oder änliche ....Aber, in C++ und matlab in der Kombination mit CodeSys.....
Also, CoDeSys ist eine gute Sprache, im Vergleich mit Siemens, vieeeeeeeeeeeeeeeeeel besser.


----------



## Larry Laffer (21 August 2015)

Du hast anscheinend die Intension hinter diesem Thread nicht so recht verstanden ... Schade ...



leoleo schrieb:


> Die Programme sind nicht unübersichtlich. CoDeSys bietet gute Möglichkeiten die Module zu kapseln und sehr übersichtlich zu programmieren.


Wir sprechen aber nicht von CodeSys sondern von TwinCat ...



leoleo schrieb:


> Schrittmotoren sind heute sehr wichtig weil diese in vielen Anwendungen ersetzen Servo sehr gut (ein TOP Schrittmotor kostet max. 80 Euro, Servo=300-400 Euro). Sehr wichtig, vor allem gegen China.


Das ist deine Meinung und die darfst du ja auch haben - ICH habe nur geschrieben, das Schrittmotoren FÜR MICH ein Spielzeug aus einer längst vergangenen Zeit sind (Steinzeit oder so ...).



leoleo schrieb:


> Strukturen und Enums können lokal sein. Aber das ist doch kein gewaltiges Nachteil.


Wenn du Strukturen so verwenden würdest wie man es sich als Siemens-Programmierer sehr schnell angewöhnt sie zu benutzen, dann würdest du auch verstehen, was ich gemeint habe.
In einem TC-Programm könnte es sehr gut sein, dass ich darin mehr Strukturen (und vor Allem Struktur-Files weil ja jeweils immer nur eine Struktur in ein File hinein darf) habe als Bausteine.
Ich finde das dann schon unübersichtlich zumal die (also mehrere) auch immer nur in einem Baustein gültig sind. Das macht man sonst in keiner Programmiersprache so ...



leoleo schrieb:


> Ich programmiere CoDeSys seit 7 Jahren und noch nie habe ich Bedarf nach KOP, FUP oder änliche ....Aber, in C++ und matlab in der Kombination mit CodeSys.....
> Also, CoDeSys ist eine gute Sprache, im Vergleich mit Siemens, vieeeeeeeeeeeeeeeeeel besser.


Das steht außen vor und auch davon war keine Rede.
Wie ich schon eingangs geschrieben habe : "die genannten Editoren sind eigentlich nicht benutzbar". Und ... es gibt auch Andere auf dieser Welt, die dir z.B. vorschreiben, nicht in ST programmieren zu dürfen - oder nur das, wo es nicht anders geht. Das sehe ich dann schon ein bißchen kritisch ...

Du darfst ruhig ein bißchen kritisch mit den Dingen um dich herum umgehen.
Wenn immer alle mit Allem zufrieden gewesen wären dann wäre unsere Räder auch heute noch viereckig (und nicht rund).

Gruß
Larry


----------



## leoleo (21 August 2015)

...Schrittmotoren sind keine Spielzeuge.....Schrittmotoren ersetzen Servos in vielen Anwendungen. Falls eine Maschine unter 20000 Euro kostet, dann schaust du auf ALLES!!!!!!!!!(es ist sehr kindisch über Steinzeit zu sprechen).Lächerlich!!!!!!


----------



## rostiger Nagel (21 August 2015)

leoleo schrieb:


> ...Schrittmotoren sind keine Spielzeuge.....Schrittmotoren ersetzen Servos in vielen Anwendungen. Falls eine Maschine unter 20000 Euro kostet, dann schaust du auf ALLES!!!!!!!!!(es ist sehr kindisch über Steinzeit zu sprechen).Lächerlich!!!!!!



Hallo kannste du mal ein wenig sachlicher werden und beim Thema bleiben.

Ausrufezeichen


----------



## norustnotrust (21 August 2015)

@leoleo: Schrittmotoren sind Spielzeuge UND Maschinen unter 20TEUR sich auch Spielzeuge 
 Nein, im Ernst. Nur die Ruhe! (eines reicht) Larry meint es gibt Industrien, wie die in der er tätig ist (und ich zufällig auch), da gibt es Schrittmotoren nicht. Vermutlich aus dem einfachen Fall dass ich keine Schrittmotoren > 1kW kenne und das bei Anlagen der kleinste Motor ist den du findest.


----------



## leoleo (21 August 2015)

Ich habe nicht geschrieben dass es 1 KW Schrittmotoren gibt. Aber in Verpackungsindustrie und Druckindustrie gibt es sehr viele und sehr gute. Warum soll ich 400 Euro bezahlen falls ich etwas für 80 Euro bekomme? Es geht hier nur um Preis. Wir sollen uin Europa endlich über Preis nachdenken. Sonst in 5 Jahren haben wir keine Chance gegen China.


----------



## ostermann (21 August 2015)

Bei den Schrittmotoren und vor allem bei den Steuerungen hat sich einiges getan in den letzten 10 Jahren. Es gibt sowohl Lösungen mit Servoregelung über Encoder, als auch Ansätze in Richtung geberloser Regelung. Das ist hier aber nicht das Thema...

Der große Vorteil bei Beckhoff in Sachen Antriebstechnik ist meiner Meinung nach der, dass es aus SPS-Sicht völlig egal ist, was als Antriebshardware anzusprechen ist. Vom Schrittmotor bis zum "großen" Servo an AX5000 oder AX8000 haben alle aus Sicht der SPS das gleiche Interface und die gleichen Funktionen. Selbst exotische Dinge wie DC-Motor an EL3xxx oder KL2552 mit Feedback über ein analoges Messsystem (Poti) an einer EL-Klemme lassen sich realisieren.
Ein weiterer Vorteil: Das geht auch mit Fremhardware quasi genauso einfach. Man ist also nicht auf Beckhoff abboniert. Dank der Protokolle SoE (Sercos over EtherCAT) und CoE (CAN(open) over EtherCAT) können die Hersteller bestehende Profile unter EtherCAT weiter verwenden.
Ich bin selbst kein Programmierer, sondern mache hauptsächlich Antriebsprojektierung. In der TwinCAT-Welt kann ich Antriebe in Betrieb nehmen und Achsen testweise verfahren, bevor die Programmierer auch nur eine Zeile Code geschrieben haben. Und wenn es drauf ankommt, habe ich aus dem Systemmanager und aus dem Scope Zugriff auf jede Variable bis herunter zu den einzelnen Status-Bits. Man kann Referenzflags setzen oder löschen, Geberwerte manipulieren, Eingänge forcen usw., und so wirklich alles testen.

Mit freundlichen Grüßen
Thorsten Ostermann


----------



## zako (22 August 2015)

ostermann schrieb:


> Der große Vorteil bei Beckhoff in Sachen Antriebstechnik ist meiner Meinung nach der, dass es aus SPS-Sicht völlig egal ist, was als Antriebshardware anzusprechen ist. Vom Schrittmotor bis zum "großen" Servo an AX5000 oder AX8000 haben alle aus Sicht der SPS das gleiche Interface und die gleichen Funktionen. Selbst exotische Dinge wie DC-Motor an EL3xxx oder KL2552 mit Feedback über ein analoges Messsystem (Poti) an einer EL-Klemme lassen sich realisieren.
> Ein weiterer Vorteil: Das geht auch mit Fremhardware quasi genauso einfach. Man ist also nicht auf Beckhoff abboniert. Dank der Protokolle SoE (Sercos over EtherCAT) und CoE (CAN(open) over EtherCAT) können die Hersteller bestehende Profile unter EtherCAT weiter verwenden.


Bei SIEMENS kommuniziert man mit Antrieben, die das Profidrive- Profil unterstützen (über Profibus oder Profinet), oder z.B. analog, oder über Pulsrichtungsschnittstelle (eben die "Billigantriebe"). Ob nun die Achsinterpolation in der überlagerten Steuerung gemacht wird,  oder dezentral im Antrieb, entscheidet der Anwender (bzw. die Applikation) - ach ja, die Antriebe selbst unterstützen auch noch CAN, Ethernet IP, BacNet, ...
Insgesamt hat es aber schon Vorteile wenn man dann aber die Antriebe von SIEMENS nimmt (ist ohnehin eine der Stärken - der Leistungsbereich deckt sehr viel ab) - gerade wenn man Steuerungs, HMI und Antriebsdaten in einen Projekt hat.



ostermann schrieb:


> Ich bin selbst kein Programmierer, sondern mache hauptsächlich Antriebsprojektierung. In der TwinCAT-Welt kann ich Antriebe in Betrieb nehmen und Achsen testweise verfahren, bevor die Programmierer auch nur eine Zeile Code geschrieben haben. Und wenn es drauf ankommt, habe ich aus dem Systemmanager und aus dem Scope Zugriff auf jede Variable bis herunter zu den einzelnen Status-Bits. Man kann Referenzflags setzen oder löschen, Geberwerte manipulieren, Eingänge forcen usw., und so wirklich alles testen.


Das ist Stand der Technik bei SIEMENS seit Jahren. Vergleiche aber mal die Möglichkeit mechatronischer Analysen mit* internen* Tools - z.B. Detektion von Tilger- und Resonanzfrequenzen. Da sind die Messfunktionen bei SIEMENS für die Übertragungsfunktionen von Strecke, Drehzahl-,  Lagereglerkreis usw. direkt integriert. Da kannste bei Beckhoff gerade mal externe Tools bemühen um dann Filtereinstellungen zu erraten.


----------



## Knaller (22 August 2015)

Moin
Hier im Thread wird sich über Twincat unterhalten.   Wenn jetzt alle so schreiben, dann werd ich mal INDRAworks in die Runde werfen.[emoji41][emoji41][emoji41][emoji41]

Beckhoff hat mit Twincat ein Gesamtpaket hingestellt.  Was Siemens lange nicht so konnte.  Die Schnittstellen zur Oberfläche bzw in die Büro Datenwelt waren einfach 


Sent from my iPhone using Tapatalk


----------



## zako (22 August 2015)

Knaller schrieb:


> Beckhoff hat mit Twincat ein Gesamtpaket hingestellt.  Was Siemens lange nicht so konnte.  Die Schnittstellen zur Oberfläche bzw in die Büro Datenwelt waren einfach



Da solltest Du nun schon konkreter werden. Der TE erwartet hier keine Pauschalaussagen, sondern will konkrete Punkte durchgehen. Bei SIEMENS hast Du schon seit Jahrzehnten die Integration von HMI, PLC und Drives. Bzgl. Anbindung an die "Datenwelt" - ein System wie PCS7 hat z.B. Beckhoff gar nicht, wenn Du z.B. an die Prozessleittechnik denkst.


----------



## Blockmove (22 August 2015)

Gesamtsystem:
Wie ist das gleich bei Siemens mit der Integration von S120 in TIA?

Gesamtsystem:
Antriebstechnik ... Wie viele Antriebsplattformen hat Siemens?
SPS T-CPUs und Technologieoblekte
Sinamics
Simotion
Sinumerik
Gibt es da ein Gesamtsystem? Gibt es da einheitliche Schnittstellen zur SPS?

Gesamtsystem:
Was ist nun mit der Vereinheitlichung der Visualisierung?
Wann wird nun WinCC 7.2 abgelöst und PCS in TIA integriert?

Also meines Erachtens ist der Bereich AD ein organisatorisches Chaos.

Nichts gegen die Produkte im einzelnen. Siemens hat sehr gute Lösungen.
Nur von einem Gesamtsystem sind sie meilenweit entfernt.

Gruß
Dieter


----------



## Andy_Scheck (22 August 2015)

Meine Erfahrung zu TwinCat:

Neg: Hin und wieder ruft das TwinCAT 3 in Verbindung mit VS 2012 auch mal einen "Blue-Screen" hervor - Ist mir des öfteren schon beim einrichten einer Anlage aufgetreten - während dem Betrieb, undenkbar!
Neg: Matlab-Simulink-Interface läuft nicht immer ganz problemlos.

Pos: Werden die Fehler direkt an den Beckhoff-Support gemeldet, dann fließt das in das nächste Update mitein oder man erhät sogar direkt per Mail einen HotFix zur Behebung des Problems!


----------



## rostiger Nagel (22 August 2015)

Andy_Scheck schrieb:


> Pos: Werden die Fehler direkt an den Beckhoff-Support gemeldet, dann fließt das in das nächste Update mitein oder man erhät sogar direkt per Mail einen HotFix zur Behebung des Problems!



Das nenn ich mal positiv, bei Siemens musst du wie in einen Gerichtsverfahren 
einen Beweisatrag stellen, das in der Software irgend etwas nicht stimmt.
Aber meistens wird das Verfahren abgeschmetert und es kommt zu einen
Vergleich: 'Deinstallation und komplette Neuinstalation der Software, mit
dem Ergebnis das Problem besteht weiter'


----------



## Larry Laffer (22 August 2015)

... da bringe ich mich doch auch gleich wieder mit ein ...
Da das  Thema Antriebstechnik (Servomotoren) ein paar Beiträge abdeckte ...  etwas was mir sehr gut gefallen hat (es wurde schon angrissen aber nicht  deutlich ausgesprochen) : Es ist dem Beckhoff vollkommen egal, ob man  seinen AX nimmt und den steuert oder z.B. einen Bosch-Rexroth IndraMat.  Vor Allem soll es gerade dann sehr einfach gehen, wenn der Hersteller  TwinCat-Beschreibungdateien mitliefert (was z.B. bei Bosch-Rexroth der  Fall wäre).
Was mir dann noch sehr gut gefallen hatte war z.B. das  Koppeln von Achsen. Nicht, dass ich das schon jemals gebraucht hätte -  ich fand es aber wirklich gelungen, dass das im Grunde mit 2 Klicks zu  erledigen war ... (naja und das Kopplungsverhältnis). Ich bin mir da  nicht so sicher ob Siemens das so kann ...
Die Motion-Bausteine haben  mir auch ganz gut gefallen - die hatten viel Ähnlichkeit mit  Bausteinen, die ich mir unter Step7-Classic so für meine  Servo-Anwenungen gebaut habe. Das Einzige : ich hätte nun Reset und Stop  nicht unbedingt in unterschiedlich Bausteine gepackt ... ABER ... man  kann sich ja auch hier wieder selbst etwas zusammenfassen ...

Wie Beckhoff auf Fehler reagiert kann ich nicht beurteilen - das Support-Statement von Andy hat mir aber schon gefallen ...

Gruß
Larry


----------



## MasterOhh (23 August 2015)

Jo, wenn man dann mal durchgekommen ist, dann ist der Support von Beckhoff sehr gut, man wird auch relativ schnell an die entsprechenden Fachabteilungen weitergeleitet.
Ich finde es auch klasse, dass TwinCAT 2 weiterhin Supported und auch weiterentwickelt wird, auch wenn es mir so schwerer gemacht wird auf TC3 umzusteigen.


----------



## zako (23 August 2015)

Larry Laffer schrieb:


> ... da bringe ich mich doch auch gleich wieder mit ein ...
> Da das  Thema Antriebstechnik (Servomotoren) ein paar Beiträge abdeckte ...  etwas was mir sehr gut gefallen hat (es wurde schon angrissen aber nicht  deutlich ausgesprochen) : Es ist dem Beckhoff vollkommen egal, ob man  seinen AX nimmt und den steuert oder z.B. einen Bosch-Rexroth IndraMat.  Vor Allem soll es gerade dann sehr einfach gehen, wenn der Hersteller  TwinCat-Beschreibungdateien mitliefert (was z.B. bei Bosch-Rexroth der  Fall wäre).


Bei SIEMENS sollten die Antriebe eben "Profidrive" sprechen, da gibt es auch entsprechend viele (z.B. LinMot, Wittenstein, Jena Antriebstechnik,...), ansonsten ist das Portfolio von SIEMENS selbst recht breit.



Larry Laffer schrieb:


> Was mir dann noch sehr gut gefallen hatte war z.B. das  Koppeln von Achsen. Nicht, dass ich das schon jemals gebraucht hätte -  ich fand es aber wirklich gelungen, dass das im Grunde mit 2 Klicks zu  erledigen war ... (naja und das Kopplungsverhältnis). Ich bin mir da  nicht so sicher ob Siemens das so kann ...
> Die Motion-Bausteine haben  mir auch ganz gut gefallen - die hatten viel Ähnlichkeit mit  Bausteinen, die ich mir unter Step7-Classic so für meine  Servo-Anwenungen gebaut habe. Das Einzige : ich hätte nun Reset und Stop  nicht unbedingt in unterschiedlich Bausteine gepackt ... ABER ... man  kann sich ja auch hier wieder selbst etwas zusammenfassen ...


Das klingt nach PLC Open, wie es auch die S7-1500/1200 macht.
Nur das mit den Koppeln von Achsen ist das so eine Sache. Bei geringer mechanischer Kopplung ist ein Getriebegleichlauf der richtige Ansatz, den man per PLC Open Befehle recht einfach hinbekommt. Falls man aber mechanisch gekoppelte Achsen hat, ist eine Drehmomentkopplung oder eine Lastausgleichsregelung notwendig. Ich war schon auf Anlagen mit Beckhoff- Steuerungen unterwegs, da hatten wir uns dann darauf geeinigt, dass wir die Kopplung im Antrieb lösen  (war ein SINAMICS S120, also ein Multiachsantrieb und somit recht einfach möglich - man hat aber damit wieder Technologie im Antrieb und Steuerung, was der Kunde eigentlich so nicht wollte).
Bei einer S7-1500 hätte ich per Telegrammzusatzdaten die relevanten Daten in die Steuerung geschickt und dort verarbeitet. 



Larry Laffer schrieb:


> Wie Beckhoff auf Fehler reagiert kann ich nicht beurteilen - das Support-Statement von Andy hat mir aber schon gefallen ...


Vielleicht hat sich ja in den letzten beiden Jahren was getan:
http://www.sps-forum.de/codesys-und-iec61131/64456-beckhoff-support.html


----------



## Knaller (23 August 2015)

Moin
Das mit Kopplungen von Achsen ist ein weitreichendes Thema.  Meine Erfahrungen sind da sehr unterschiedlich was die Ergebnisse betrifft.  In meinem Bereich sind Kopplungen über die Steuerung oft gescheitert wegen den Zyklus Zeiten oder den Fähigkeiten der Steuerung.  @ Zako  Und Siemens kocht mit dem gleichen Wasser wie alle anderen Hersteller.    @ all Bei Projekten haben sich Ethercat und auch Profinet als nicht ausreichend erwiesen.   Daher bin ich der Meinung das die Problemstellung zu einer Lösung führt. 


Sent from my iPhone using Tapatalk


----------



## zako (24 August 2015)

... es gibt eben schon gravierende Unterschiede zwischen den einzelnen Systemen. Wenn man z.B. einen SINAMICS S120 nimmt, dann kann man direkt im Antrieb das Drehmoment des Masters auf die Folgeachsen verschalten. Ich habe Anlagen in Betrieb genommen (Servopressen mit 2x 500kW)- Antrieben, da konntest Du die Stromverläufe deckungsgleich übereinanderlegen, da war ich selbst überrascht. Es gibt aber noch weitere Ansätze, wie Statik, Drehmomentausgleichsregelung etc. - das kommt dann auf die Anwendung an, was passt (durchlaufende Warenbahnen etc.).  
Ich denke wenn man z.B. an schnelldrehenden Spindeln (mit Sättigungseffekten der Motorinduktivitäten, Reluktanzmomenten / Unsymmetrien Lq/Ld- Achse, Notwendigkeit von Vorschaltdrosseln, ...) denkt, da wirst Du mir sicher zustimmen, dass solche Motoren nicht von jeden Umrichter beherrscht werden - ggf. ein Grund dafür dass die Kombination Beckhoff- Steuerung mit Fremdumrichtern häufiger anzutreffen ist.


----------



## StructuredTrash (24 August 2015)

Es wird immer Sonderanwendungen geben, die man mit Standardhardware nicht beherrschen kann. Wenn ich mir aber mal das XTS-Transportsystem anschaue, denke ich, dass Beckhoff keineswegs nur den Brot-und Butterbereich der Antriebstechnik abdeckt. Ich würde die sogar gern einsetzen, wenn ich nicht mit LL darin übereinstimmen würde, dass die Inbetriebnahme recht umständlich ist. Den einen Karteikartenreiter, den ein Beckhoff EtherCat-Antrieb gegenüber einem anderen EtherCat-Gerät mehr hat, als "Drive Manager" zu bezeichnen, ist eine Beleidigung für andere Hersteller, die unter diesem Namen eine komplette Inbetriebnahmesoftware anbieten. Und dass die Trennung zwischen HW-Stromregler und SW-Lageregler dem Anwender im Systemmanager so deutlich unter die Nase gerieben wird, muss auch nicht sein. Mag sein, dass ich das nach einem Lehrgang anders sehen würde, aber mit den von mir bisher eingesetzten Antrieben bin ich auch ohne Lehrgang klargekommen. Und es gibt auch Dinge, die trotz Lehrgang unterirdisch bleiben würden. Beispiel: Das CoE-Verzeichnis einer EL-Servoklemme hat ein Objekt mit dem wohlklingenden Namen "Actual Torque". Dieses Objekt liefert aber nicht das aktuelle Drehmoment, sondern den aktuellen Strom in Promille vom Nennstrom, aus dem man sich nach einer in den Tiefen des Infosys verborgenen Formel das Drehmoment ausrechnen muss.

Ansonsten gilt: Beckhoff ist um Welten besser als Siemens, sonst würde ich nicht Beckhoff einsetzen. Aber das gilt eben nur für meine Anwendungen und Anforderungen. Es kann gute Gründe geben, nicht auf Beckhoff zu setzen. Hier mal eine kleine Auflistung, die von anderen Usern sicher noch fortgesetzt werden kann. Man sollte von Beckhoff Abstand nehmen, wenn man
nicht ausschliesslich in ST programmieren will oder darf,
auf einen IMMER möglichen und funktionierenden Online-Change angewiesen ist,
den Grossteil seiner zyklisch aktualisierten Steuerungsdaten persistent halten muss und ein Verlust dieser Daten eine Katastrophe darstellt.


----------



## Thomas_v2.1 (24 August 2015)

StructuredTrash schrieb:


> Und es gibt auch Dinge, die trotz Lehrgang unterirdisch bleiben würden. Beispiel: Das CoE-Verzeichnis einer EL-Servoklemme hat ein Objekt mit dem wohlklingenden Namen "Actual Torque". Dieses Objekt liefert aber nicht das aktuelle Drehmoment, sondern den aktuellen Strom in Promille vom Nennstrom, aus dem man sich nach einer in den Tiefen des Infosys verborgenen Formel das Drehmoment ausrechnen muss.


Das ist bei Siemens aber nicht anders, bzw. noch schlechter. Da werden diverse Werte in 0..16384 übertragen, und der Skalierungsfaktor (mal 16,54 oder sonstige krumme Werte) muss dann online aus dem Umrichter ausgelesen werden. Das finde ich eigentlich unpraktischer als eine fixe Berechnungsformel nachzuschlagen. Bei Siemens muss ich immer das Programm nachpflegen, oder den Parameterkanal bemühen und die Skalierungsfaktoren per SPS-Programm auszulesen.


----------



## Knaller (24 August 2015)

Moin.  
Da macht es der Bosch Rexroth dem User einfacher.
Hier werden die Daten immer in einem verständlichen Format dargestellt.    In den Menüs "Wichtung" stellt man die Daten im gewünschten Format ein.   Das können dann die " Mechaniker" und auch ich immer gut verstehen.   Das einzige was ich nicht mag ist die Nummer mit der leitachse wenn die in 2 hoch n umgewandelt wird. 
Ich wundere mich dann bei Beckhoff immer über diese Skalierungen.  


Sent from my iPhone using Tapatalk


----------



## zako (24 August 2015)

StructuredTrash schrieb:


> Ansonsten gilt: Beckhoff ist um Welten besser als Siemens


Dann solltest Du auch benennen, wo Du die Stärken gegenüber SIEMENS siehst (möglichst an konkreten Beispielen). Sonst kann mit dieser Aussage keiner was anfangen. 



Thomas_v2.1 schrieb:


> Das ist bei Siemens aber nicht anders, bzw. noch schlechter. Da werden diverse Werte in 0..16384 übertragen, und der Skalierungsfaktor (mal 16,54 oder sonstige krumme Werte) muss dann online aus dem Umrichter ausgelesen werden. Das finde ich eigentlich unpraktischer als eine fixe Berechnungsformel nachzuschlagen. Bei Siemens muss ich immer das Programm nachpflegen, oder den Parameterkanal bemühen und die Skalierungsfaktoren per SPS-Programm auszulesen.


Also, wenn Du z.B. im TIA Portal (oder auch in SIMOTION / bei der T-CPU dürfte es auch so sein) mit Technologieobjekten "TO" arbeitest, dann übernimmt das für Dich das IBN- Tool. 
Beispiel Drehzahlachse im TIAP. Man sagt zum Antrieb SINAMICS G120, dass dieser an einer SIMATIC MotionControl Steuerung hängt (also S7-1x00), dann wird gleich mal die Bezugsdrehzahl zwischen Steuerung und Antrieb mit gleichen Werten vorbelegt. D.h. der Anwender gibt dann in der Steuerung per PLC- Open Befehle direkt die Sollwerte in seiner gewünschten Einheit vor. Man kann auch die Mechanik vorgeben (dann erfolgt die Drehzahsollwertvorgabe gleich lastseitig).
Man kann das aber auch ohne "TO" machen. Wenn man nun den Drehzahlsollwert als Word überträgt, dann entsprechen 2^14 = 16384 eben 100% der Antriebsbezugsdrehzahl. Das ist immer noch  >16 mal feingranularer als eine Stufung im Promilebereich (das würde ja heißen, dass man z.B. bei einen Motor mit 
3000 min[SUP]-1[/SUP] eine Stufung in 3min[SUP]-1[/SUP] Schritten vorgeben müsste - wäre mir zu grob). Normallerweise gibt man den Drehzahlsollwert sogar als 32bit Wert vor, was nochmal viel feingranularer ist.
Technologisch überwiegen hier die Vorteile.


----------



## Knaller (25 August 2015)

Moin
Einen Sollwert in 32Bit vorgeben, mag ja schön sein.  Aber dann zeig mir eine Mechanik und auch einen Antrieb der das kann.  Alleine die Verwindung der Motorwelle bei der krafterzeugung macht da die Hohe Auflösung platt. 
Da hab ich schon genug Diskussionen mit Kunden gehabt.   Bestes Beispiel für mich VW in Braunschweig. Wollen im 1/1000mm positionieren haben aber keine  konstante Temperatur in der Halle und ein Rolltor was schön die frische Luft rein lässt ob Sommer oder Winter. 
Siemens hat es erst in letzter Zeit geschafft diese Skalierungen automatisch vor zunehmen.  Wo andere schon lange so weit waren. 
Die Bemerkungen mit dem Online Change sind schon richtig.   Es wurde aber schon nach gebessert.  Das ist halt der Nachteil bei Codesys.  Daher ist es wichtig das die Steuerung entsprechend für das online Chance aus gelegt ist. Z.B. NVRam oder andere Maßnahmen 

Sent from my iPhone using Tapatalk


----------



## Blockmove (25 August 2015)

@zako
Du pickst dir hier irgendwie immer die passende Siemens-Lösung heraus.
Wenn ich eben einen simplen G120 mit TIA an eine S7-300 anbinde, dann erfolgt die Drehzahlvorgabe über ein Word und ich muss mir die Drehzahl "basteln"
Von Vereinheitlichung keine Spur.

@Knaller
Beim Thema Online-Change hat die Codesys-Welt gegenüber Siemens immer noch Nachteile. Persönlich ist das für mich quasi ein KO-Kriterium im Bereich Anlagen- und Maschinenbau.
Die Inbetriebnahmezeiten werden immer kürzer und somit findet ein Großteil der Anlagen- / Maschinenoptimerung im Produktionsbetrieb statt.
Hier ist ein Stopp zum Einspielen von Änderungen schlichtweg richtig ärgerlich.
In diesem Bereich sollte Codesys mal dringend nachbessern und vielleicht auch auf eine Interpreter-Lösung anstelle von Nativ-Maschinencode umsteigen.
Die heutige Hardware gibt es her.

Gruß
Dieter


----------



## StructuredTrash (25 August 2015)

@zako
Die Aussage "Beckhoff ist um Welten besser als Siemens" ist meine rein persönliche Meinung, wie ich auch schon geschrieben habe. Aber da es in diesem Thread ja genau darum geht, was jemanden zu einem Umstieg von Siemens oder sonstwo her auf Beckhoff bewegen könnte, hier meine Gründe:
Das Preis-/Leistungsverhältnis,
die hohe Echtzeitleistung der PCs und des EtherCat-Feldbusses,
die Offenheit gegenüber Geräten und Technologie von Fremdherstellern,
der objektorientierte Ansatz bei der Programmierung (auch schon bei TC2),
der Umstand, dass auch relativ kleine Kunden wie unsere Firma nicht von oben herab behandelt werden,
und nicht zuletzt die räumliche Nähe zum Hersteller. Die kommen eben, wie man bei uns in OWL sagt, "von hier wech", die Mentalität passt.

@zako
Welche Massnahmen kann man denn gegen die Unzulänglichkeiten beim Online Change treffen?
Ich habe schon Folgendes mehrfach erlebt:
Beim Versuch, mich auf eine Steuerung einzuloggen, erhalte ich die Meldung, das Programm hätte sich geändert, obwohl ich mir diesbezüglich keiner Schuld bewusst bin. Selbst wenn in dieser Situation ein Online Change angeboten wird, bleibt ein mulmiges Gefühl, weil man keinen Online-Projektvergleich machen kann.
Ein Online Change führt zu einer so grossen Zykluszeitüberschreitung der Steuerungstask, dass der Feldbus-Watchdog zuschlägt. Das könnte gerade bei TC3 zu einem noch grösseren Problem werden, wenn man ausgiebig von Interfaces Gebrauch macht.
Ein Online Change geht voll in die Hose, Daten werden wer weiss wohin verschoben. Einmal wusste die Kiste danach noch nicht mal mehr, wo ihre I/Os stehen. Und ich schwöre Stein und Bein, dass ich nur eine AND-Verknüpfung eingefügt habe. Es besteht offenbar keine Zusammenhang mit dem Umfang der Änderungen. Das ist allerdings seit TC2 R3 anscheinend Geschichte, trotzdem werde ich keinen Online Change mehr durchführen, ohne zuvor die Maschine leerzufahren. Bei unseren Maschinen führt das mit Wiederanfahren zu einem Verlust von einer halben Stunde. Das geht noch, aber wenn die eigentliche Programmänderung nur wenige Minuten dauert, ist es schon ärgerlich.


----------



## rostiger Nagel (25 August 2015)

Meine Meinung:

Siemens ist sehr Stark in der Antriebstechnik, aber leider haben Sie keine aufwärtskompatibele Struktur,
wenn du mit einer kleinen Anwendung gestartet bist und hast dich für ein System endschieden, kann es
sein wenn die Anwendung wächst, das du auf ein völlig anderes System umsteigen musst.
Meinetwegen von einer T-CPU zu Simotion oder Sinumerik. Diese Funktionieren ganz anders, unter umständen
kann man das Hart erarbeitete dann über den Haufen schmeißen und fängt wieder von vorne an.

Das ist bei Beckhoff anders, klar brauchst den Anforderungen entsprechend den richtigen PC aber dort ist
das ganze System auf gleicher Basis erweiterbar.

@Zako,
Beckhoff hat sich gute Leute von einen Antriebshersteller eingekauft, die sich meiner Meinung nach von der
Kompetenz mit Siemens messen können. So wie ich Beckhoff kennengelernt habe, stellen Sie sich den Anforderungen
die ihnen gestellt werden. Da kann es sein, was du als Alleinstellungsmerkmal für Siemens darstellst, ganz schnell
verschwunden ist.


----------



## Blockmove (25 August 2015)

Nunja Beckhoff und Codesys haben in den letzten Jahren sehr viel richtig gemacht.
Besonders gut ersichtlich ist dies bei der Gebäudeautomatisierung.
Hier hat Siemens schlichtweg gepennt bzw. treten sich A&D und Building gegenseitig auf die Füsse.
Joe Käser hat viel zu tun in seinem Laden


----------



## Knaller (25 August 2015)

Moin 
Ja Beckhoff hat sich Leute von "Elau Schneider" und Bosch Rexroth ein gekauft.    Beckhoff baut die Antriebe in Marktheidenfeld
Schaut mal unter fertig-Motors.com 


Sent from my iPhone using Tapatalk


----------



## bike (25 August 2015)

StructuredTrash schrieb:


> Das Preis-/Leistungsverhältnis,
> die hohe Echtzeitleistung der PCs und des EtherCat-Feldbusses,
> die Offenheit gegenüber Geräten und Technologie von Fremdherstellern,
> der objektorientierte Ansatz bei der Programmierung (auch schon bei TC2),
> der Umstand, dass auch relativ kleine Kunden wie unsere Firma nicht von oben herab behandelt werden,



Da magst du aus der augenblicklichen, deiner Situation recht haben.
Aber die Unzulänglichkeiten der PCs, die lässt du außen vor.
Das Betriebssystem ist bei dem Ansatz auch von Beckhoff die Schwachstelle.
Das kann auch 3S oder andere nicht komplett kompensieren.


bike


----------



## MasterOhh (25 August 2015)

Naja, einen Online Change während ein kritischer Prozeß läuft würde ich persönlich bei keiner Steuerung, egal von welchem Hersteller, durchführen. Das TwinCAT der Meinung ist, dass sich das Programm geändert hat, obwohl keine Änderungen vorgenommen wurden, kann auch daran liegen das man Versucht sich mit einer anderen TwinCAT Version einzuloggen. Wenn das Projekt etwas unterschiedlich kompiliert wurde, muss es natürlich neu hochgeladen werden. Das kann man aber mit dem Remote Manager umgehen. 

Stark Verbesserungswürdig ist aus meiner Sicht aber noch der Umgang mit Strukturen im Systemmanager. Das Byte-Padding hat mich schon das ein oder andere mal in den Wahnsinn getrieben. Auch das die Byte-Größe der E/A Strukturen nicht immer konsistent ist, nerft gewaltig. Vorallem das Bits in der Hardware wirklich wie Bits Adressiert werden, Bools in den Strukturen aus dem PLC Programm aber Bytes sind, ist etwas blöde.

Was ich sehr gut finde ist, dass man bei Beckhoff den gesamten Quellcode (incl. Kommentare) auf die SPS (CX) laden kann. Und zwar auf JEDE, auch auf die kleinen (wenn man noch Speicher frei hat). Bei uns kann es passieren, dass man mal kurz zu einer Anlage gerufen wird, weil man gerade im Werk unterwegs war. Dann kann ich zur Not auch auf die Steuerung schauen, ohne das ich mir vorher das aktuelle Archiv vom Server gezogen habe.

EDIT:
@ Bike das Betriebssystem kann eine Schwachstelle sein, aber Beckhoff hat die Runtime eigentlich so robust implementiert, das sie auch bei einem Bluescreen weiterlaufen kann (einmal erlebt). Und das ohne sich kilometertief im System zu verankern wie z.B. ein WinAC RTX. Aber ja, man sollte es vermeiden einen Steuerungsrechner wie einen Desktop PC zu behandeln. Beckhoff bietet da auch einige Tools um diverse Dinge (Schreibzugriffe) einzuschränken.
Andererseits ist das Betriebssystem auch eine große Stärke. Denn ich habe wesentlich mehr Möglichkeiten ausserhalb der gewohnten SPS Pfade zu wandern. Das war auch der Grund warum wir damals zu Beckhoff gewechselt haben, wir brauchten Steuerungen die uns mehr Freiraum zu bieten hatten.


----------



## rostiger Nagel (25 August 2015)

bike schrieb:


> Da magst du aus der augenblicklichen, deiner Situation recht haben.
> Aber die Unzulänglichkeiten der PCs, die lässt du außen vor.
> Das Betriebssystem ist bei dem Ansatz auch von Beckhoff die Schwachstelle.
> Das kann auch 3S oder andere nicht komplett kompensieren.
> ...



Betriebssystem würde ich jetzt Sekundär sehen, um bei Siemens zu bleiben kannst du bei
den neueren IPCs das Betriebssystem durchbooten, ohne das die Soft-SPS aufhört zu arbeiten,
diese geht übrigens an den Start und setzt Ausgänge bevor das Windows Symbol zu sehen ist.

Das Betriebssystem ist dann wie eine HMI zu sehen, die halt noch nicht hochgleufen ist, wie
alle HMI Systeme die ein Betriebssystem haben.


----------



## mac203 (25 August 2015)

bike schrieb:


> Da magst du aus der augenblicklichen, deiner Situation recht haben.
> Aber die Unzulänglichkeiten der PCs, die lässt du außen vor.
> Das Betriebssystem ist bei dem Ansatz auch von Beckhoff die Schwachstelle.
> Das kann auch 3S oder andere nicht komplett kompensieren.
> ...



Welche Unzulänglichkeiten der PCs meinst du denn???

Auf einem IPC/Steuerungsrechner gehört nur Maschinensoftware (SPS/VISU/Maschinenspezifische-SW) und nicht mehr.
Das ein solcher Rechner im laufenden Betrieb abstürzt habe ich bisher (mit Ausnahme von SPS-Programmiererfehlern z.B. durch MEM***-Befehle) noch nicht gesehen oder zu hören bekommen.
Hardware kann natürlich auch durch Alterungsprozesse kaputt gehen....aber auch das ist etwas anderes!


----------



## JesperMP (25 August 2015)

Über Online Change.
Auf Beckhoffs website wird geschrieben von "Online-Change in Programmen* und Variablen*" [meine Hervorhebung]. Das lautet ja besser als Siemens.
Ich bin jetzt sehr verwirrt, geht das oder geht das nicht, und zwar zuverlässig ?
Hat jemand tatsächlich Erfahrung mit Online Change und verwendet es auf laufender Anlagen ?
Wenn es nicht geht, ist es ein absoluten Aus für Twincat für mich.


----------



## mac203 (25 August 2015)

Deine Nachricht bringt mich etwas zum Schmunzeln.

Sicher geht das (zu >99%), wenn man den richtigen Weg einhält, wie bereits in den vorherigen Beiträgen beschrieben.
Das ist ein offiziell beworbenes Feature und bezieht sich auf Variblen, Baustine, Datentypen usw.
Wenn es dann jedoch um Änderungen in der Zuordnung zu physikalisch vorhandener EA geht, kann kein Online Change mehr genutzt werden.


----------



## JesperMP (25 August 2015)

mac203 schrieb:


> Sicher geht das (zu >99%), wenn man den richtigen Weg einhält, wie bereits in den vorherigen Beiträgen beschrieben.
> Das ist ein offiziell beworbenes Feature und bezieht sich auf Variblen, Baustine, Datentypen usw.


Gut das Beckhoff sagt sie haben diesen Feature. Aber lieber will ich das Forum Mitglieder erklärt das es funktioniert. Sonnst, was ist den Zweck mit ein unabhängigen Forum ?
Wie du es formulierst ("Sicher geht das"), denke ich du hast eigentlich keine eigene Erfahrung mit Online Change.



mac203 schrieb:


> Wenn es dann jedoch um Änderungen in der Zuordnung zu physikalisch vorhandener EA geht, kann kein Online Change mehr genutzt werden.


Persönlich brauche ich das nicht. So etwas gibt es bei einige SPS Hersteller, aber nennt sich "Configuration in Run" (CiR).


----------



## MasterOhh (25 August 2015)

Ja man kann auch Variablen ändern im Online Change (ohne sich Gedanken machen zu müssen wie man die Aktualwerte im DB nicht verliert  ).
Es muss nur aufgepasst werden bei Pointern, weil sich die Adressen der Variablen ändern können (TwinCAT warnt da auch vor dem Hochladen vor, wenn das der Fall ist). Wenn die Adressen der Pointer zyklisch aktualisiert werden, ist das aber kein Problem.
Und ja, Online Change von Programmen in laufenden Anlagen ist bei uns Gang und Gäbe. Da hatten wir noch nie Probleme. (Außer besagte Versionskonflikte von TwinCAT die sich mit dem Remote Manager umschiffen lassen)
Aufpassen muss man nur, wenn man das Projekt bereinigt hat. Danach ist kein Online Change mehr möglich. Die Projektbereinung führe ich, wenn überhaupt, das letzte mal am Ende der IBN durch.


----------



## mac203 (25 August 2015)

JesperMP schrieb:


> Wie du es formulierst ("Sicher geht das"), denke ich du hast eigentlich keine eigene Erfahrung mit Online Change.



Ach weißt du was....ich lasse dich einfach in dem Glauben, ich hätte keine Erfahrung damit, auch wenn ich bereits fast 10 Jahre mit dem System arbeite.
Es ist immer besser etwas in Frage zu stellen, als Dinge anzunehmen.
Viel Erfolg!

@MasterOhh
Danke für die Stellunganhme!
Du scheinst ja wirklich Erfahrung zu haben


----------



## JesperMP (25 August 2015)

MasterOhh schrieb:


> Aufpassen muss man nur, wenn man das Projekt bereinigt hat. Danach ist kein Online Change mehr möglich. Die Projektbereinung führe ich, wenn überhaupt, das letzte mal am Ende der IBN durch.


Das gilt auch bei Siemens wenn man ein Bausteinkonsistenzüberprüfung durchführt.


----------



## Knaller (25 August 2015)

Moin
Meine Kollegen machen bei einer Inbetriebnahme auch zwischendurch , wenn die Maschine steht, eine Projektbereinigung. Meist weil der Speicher eng wird.   


Sent from my iPhone using Tapatalk


----------



## StructuredTrash (25 August 2015)

Knaller schrieb:


> Meine Kollegen machen bei einer Inbetriebnahme auch zwischendurch , wenn die Maschine steht, eine Projektbereinigung.


Kann ich auch nur empfehlen. Das ist auch die Massnahme, die nach einem misslungenen Online Change hilft. Ich kann, wie schon gesagt, keinen Zusammenhang mit Art und Umfang der Änderungen feststellen. Es kommt mir eher vor wie ein Fass, das irgendwann überläuft. Da drehe ich lieber ab und zu mal den Ablaufhahn auf. Ich wundere mich übrigens, dass zumindest hier im Forum ausser mir niemand solche Probleme zu haben scheint. Möglicherweise liegt es an der von mir eingesetzten Kombination Win CE/Target Visu.


----------



## bike (25 August 2015)

mac203 schrieb:


> Welche Unzulänglichkeiten der PCs meinst du denn???




Also ich habe negative Erfahrung mit den "Super"IPCs von beckhoff mit Twincad mehrmals erlebt.
Es gab bzw gibt noch Speicheralloc Fehler bei einem Kunden von uns z.B. in Polen.
Da läuft nur das OS, die freigegebene Visu, die PLC und eine Ethernetanbindung an das Firmennetz für BDE.
Und auch der Hersteller konnte unsere Probleme nicht lösen. 

Ich gehe das ganze wie immer rational an:
Welches OS läuft auf den IPC? 
Ist das sicher, jetzt und in Zukunft?
Welche Möglichkeiten darf ich nutzen, wenn alles verboten ist, was den Unterschied ausmacht?
Warum soll ich dann das System nutzen?
Ich kaufe einen Porsche mit acht Ganggetriebe und 350 km/h, darf aber nur 30 fahren?
Warum dann Porsche?

OOP hat inzwischen auch den Charme als Werkzeug für die Zukunft verloren.
Denn ein Programm schreiben ist das eine, aber das über lange Jahre zu warten und am Leben zu erhalten ist etwas anderes.



mac203 schrieb:


> Ach weißt du was....ich lasse dich einfach in dem Glauben, ich hätte keine Erfahrung damit, auch wenn ich bereits fast 10 Jahre mit dem System arbeite.



Mit zehn Jahren hast du die umfassende Erfahrung?
Wenn du argumentieren willst, dann einfach fachlich und nicht unqualifiziert und emotional.
Ich programmiere seit fast 40 Jahre und maße mir solch ein Urteil über andere Programmierer nicht an.


bike


----------



## Cassandra (25 August 2015)

Hallo bike,

:s6:

<polemik>



bike schrieb:


> Ich gehe das ganze wie immer rational an:


Klar, das hilft immer.



bike schrieb:


> Ich kaufe einen Porsche mit acht Ganggetriebe und 350 km/h, darf aber nur 30 fahren?
> Warum dann Porsche?


Wenn die Alternative für das selbe Geld ein Trabbi ist, wieso nicht?



bike schrieb:


> OOP hat inzwischen auch den Charme als Werkzeug für die Zukunft verloren.
> Denn ein Programm schreiben ist das eine, aber das über lange Jahre zu warten und am Leben zu erhalten ist etwas anderes.


Klar, dann lieber von ersten Tag an richtiges Gefrickel. Dann bleibt die Qualität über Jahrzehnte konstant.



bike schrieb:


> Mit zehn Jahren hast du die umfassende Erfahrung?
> Wenn du argumentieren willst, dann einfach fachlich und nicht unqualifiziert und emotional.
> Ich programmiere seit fast 40 Jahre und maße mir solch ein Urteil über andere Programmierer nicht an.


Ein Urteil maße ich mir hier auch nicht an. Aber manche lernen schnell und andere halt nie... 


</polemik>
LG Cassandra


----------



## silverfreaky (25 August 2015)

HUI.Heute ist wieder Dampf im Kessel.Hoffentlich hat er ein Überdruckventil!


----------



## rostiger Nagel (25 August 2015)

silverfreaky schrieb:


> HUI.Heute ist wieder Dampf im Kessel.Hoffentlich hat er ein Überdruckventil!



Ach das ist immer so in einen *X vis Y*, erst geht es ganz sachlich los
und dann geht das Nivau in den Keller, irgendwann geht es in den SV, 
eigentlich ist so ein Vergleich Thema auch nichts anderes.


----------



## silverfreaky (25 August 2015)

Ich sehe den OOP-Nutzen auch nicht.Zumindest in den Programmen, die ich kenne.Zudem kann das niemand "Normaler Warten".
Das heisst aber nciht da es Anwendungen gibt, wo es vielleicht Vorteile bringt.Überhaupt finde ich sollte die Einfachheit des Programmcodes auch wenns mehr wird, der Eleganz des Komplizierten und Kurzen vorgezogen werden.
Aber das ist meine persönliche Philosophie, die muss nicht jeder teilen.


----------



## Blockmove (25 August 2015)

silverfreaky schrieb:


> Ich sehe den OOP-Nutzen auch nicht.Zumindest in den Programmen, die ich kenne.Zudem kann das niemand "Normaler Warten".



Deine Aussage stimmt schlichtweg nicht.
OOP-Konzepte in der SPS können ein Programm übersichtlicher, wartungsfreundlicher und besser lesbar machen.
Gerade Maschinen und Anlagen bestehen ja auch aus Objekten (z.B. Zylinder, NC-Achsen, u.s.w.) und dies lässt sich natürlich auch schön in der Software abbilden.
Die Sprache speilt dabei keine Rolle. OOP geht genauso in KOP und FUP und nicht nur in SCL / ST.

Klar kannst du dich in OOP so austoben, dass kein Schwein mehr weiss was Sache ist, aber das geht in AWL genauso.

Gruß
Dieter


----------



## silverfreaky (25 August 2015)

Schon dann ist das aber noch kein OOP.Objektorintiertes programmieren ist ja Objekt.Funktion oder Objekt.Eigenschaft.
Wo wendest du das in der klassischen SPS-Programmierung an und wenn ja wie?


----------



## oliver.tonn (25 August 2015)

Hallo Siverfreaky,
speziell die Vererbung kann Dir auch bei SPS-Programmen sehr helfen. Hier mal ein Beispiel aus meiner Praxis. Wir haben verschiedene Zylinder, welche mit einem Eingang und keinem Ausgang, also selbszurückstellend und ohne Rückmeldung, welche mit zwei Eingängen und keinem Ausgang, welche mit einem Ein- und Ausgang, usw. Ohne OOP müsstest Du jetzt für jeden Zylindertyp einen FB erstellen und für die Rückmeldung der Position müsstest dir dann Klimmzüge ausdenken, damit das Ventil bei der Abfrage nicht verstellt wird, was ja auch fehleranfällig ist. Mit OOP erstellst Du einen Basistyp und leitest alle anderen ab. Die Verstellung machst Du über Methoden und die Position kannst Du über Get abfragen. Fehlermeldungen könntest Du wiederum im FB direkt generieren lasen den Du zyklisch aufrufst. 

Von irgendwas mit Internetzugang gesendet.


----------



## zako (25 August 2015)

Bei SIEMENS gibt für die WinAC "ODK" und für die SIMOTION "CLIB- Studio" um C/C++ Codes oder eben MATLAB SIMULINK Modelle zu integrieren. 
http://w3.siemens.com/mcms/programm...k/seiten/default.aspx#Aufbau_20und_20Funktion
Bei Beckhoff den TwinCAT 3 – XA Language Support: C/C++
http://www.beckhoff.de/default.asp?twincat/twincat-3-xa-language-support-c.htm?id=1893323818933256

Falls dieser Punkt für bestimmte Anwender relevant ist und es Anwender gibt, die die Vor- und Nachteile beider Anbieter 
aufzeigen können, dann wären entsprechende Beiträge *hier* sicherlich zielführender als eine generelle Diskussion über Sinn und Unsinn von OOP
Z.B. Toolintegration,  Lizenzierung, ...


----------



## silverfreaky (25 August 2015)

Weiss ich nicht ob du das da brauchst.Wenn ich einen Ventilbaustein habe der keine Rückmeldung hat dann schreibe ich für "auf" den Ausgang und für "zu" den Ausgang negiert hin.
Das ist jetzt für mich keine typische OOP-Anwendung.Das kann man auch in deinem Bsp. über die Schnittstelle parametrieren.Für mich macht das nur Sinn der Aufwand wenn man typischerweise viele Objekte hat und kann auf die wie oben gezeigt mit dem Punkt auf Funktionen und Eigenschaften zugreifen.
Dann ist es wirklich sehr elgant.Das schreibt ja auch Blockmove.Blos ich kenne in der Praxis keine Anwendung.Irgendeiner hat mal geschrieben in der Gebäudeleittechnik benutzt er es.Da kenne ich mich aber nicht aus.Mag sein das man da derlei Syntax in Codesys  benutzen kann.Ich weiss es nicht.

Ich frage ja gerade nach der praktischen Anwendung und nicht was man machen kann.Das es geht ist mir klar.Blos wo sind die Anwendungen?


----------



## oliver.tonn (25 August 2015)

Ich sprach auch nicht von einem Zylinder/Ventil, sondern von verschiedenen in einem Projekt und da ist OOP hilfreich?
Wo die Anwendungen sind? Siehe oben. Das Beispiel mit den Zylindern/Ventilen entstammt nicht meiner Phantasie, sondern aus meiner täglichen Praxis. 

Von irgendwas mit Internetzugang gesendet.


----------



## MasterOhh (25 August 2015)

Wir hatten die Diskusion Pro/Contra OOP in der Steuerungswelt schon einige Male hier im Forum. Vieleicht grabt ihr entweder einen alten Thread wieder aus, oder macht einen neuen auf um die selben Argumente auf ein Neues durchzukauen....


----------



## Neals (26 August 2015)

zako schrieb:


> Bei SIEMENS gibt für die WinAC "ODK" und für die  SIMOTION "CLIB- Studio" um C/C++ Codes oder eben MATLAB SIMULINK Modelle  zu integrieren.
> http://w3.siemens.com/mcms/programm...k/seiten/default.aspx#Aufbau_20und_20Funktion
> Bei Beckhoff den TwinCAT 3 – XA Language Support: C/C++
> http://www.beckhoff.de/default.asp?twincat/twincat-3-xa-language-support-c.htm?id=1893323818933256
> ...



Um das Thema mal aufzugreifen...
Ich kenne nur die Beckhoff Features in TwinCAT 3:

C/C++:
- Entwicklung von Modulen anhand der standardisierten Schnittstellen von TcCOM.
- Module werden in Treibern zusammengefasst, welche durch Windows Treiber umgesetzt sind.
- TwinCAT Treiber werden im Kernel von Windows geladen und abgearbeitet.
- Tools und Wizards zur Generierung vom Code und den Schnittstellen anhand der Definition des TcCOM Modules.
- Verwendung vom TwinCAT SDK, inklusive Basis-Funktionen wie Datei-Zugriff, Zugriff auf Windows-Komponenten.
- Verwendung von Teilen der STL (Standard Template Library) aus dem TwinCAT SDK.
- Unterstützung von dynamischen Speicher und Exception Handling.
- Verwendung vom Visual Studio und dem Visual C++ Compiler, inklusive der C++11 und C++14 Standards.
- Erweiterte Debugging-Möglichkeiten mit online Lesen/Schreiben von Variablen ohne nötigen Breakpoint.

Matlab/Simulink:
- Integration eines TwinCAT Targets in den Simulink Coder.
- Keine speziellen Simulink-Blöcke notwendig, die standard Input, Output, etc. sind ausreichen.
- Der C++ Code aus den Simulink Coder wird in ein TcCOM Modul und als Treiber kompiliert (siehe C/C++).
- Blockschaltbild wird in TwinCAT vollständig dargestellt (optional).
- Online Lesen/Schreiben von beliebigen freigegebenen Variablen, ändern von Parametern etc. zur Laufzeit des Moduls.
- Für Debugging/Monitoring ist kein Simulink erforderlich, kann aus TwinCAT herraus erfolgen.


----------



## StructuredTrash (26 August 2015)

OOP ist eine Neuerung in TC3 und wurde auch von LL in seiner Threaderöffnung als Vorteil gegenüber Siemens gesehen. Warum darf man also hier nicht darüber diskutieren, ob es wirklich ein Vorteil ist?


----------



## MasterOhh (26 August 2015)

Wir können gern alles mögliche diskutieren. Ich wollte nur Anmerken, dass die hier gebrachten Argumente zum Thema OOP schon leicht bärtig sind. Und wenn ich die anderen Threads, in denen wir bereits über OOP gestritten haben, als Maßstab nehme, wird das ganze sehr bald damit Enden, dass sich die Leute hier gegenseitig mit detailierten Beispielen eindecken in denen OOP ihrer Meinung nach sinnvoll/unnütz ist.

Das hat dann für mich persönlich nichts mehr mit dem Vergleich von TwinCAT 3 und Siemens zu tun.


----------



## mac203 (26 August 2015)

bike schrieb:


> Mit zehn Jahren hast du die umfassende Erfahrung?
> Wenn du argumentieren willst, dann einfach fachlich und nicht unqualifiziert und emotional.
> Ich programmiere seit fast 40 Jahre und maße mir solch ein Urteil über andere Programmierer nicht an.
> 
> ...



Also wenn du richtig gelesen hast, schrieb ich von 10 Jahren Erfahrung mit diesem System = TwinCAT.
Wenn du damit tatsächlich 40 Jahre Erfahrung hast, dann nehme ich alles zurück. Damit bist du also der Entwicklung von TwinCAT damals schon voraus geeilt!

Ach übrigens: unqualifiziert war lediglich die Antwort auf die ursprünglich Nachricht, in der der Autor der Meinung sei, ich hätte keine Ahnung wovon ich schreibe.
Und da ich ja mitbekommen habe, dass hier scheinbar alle mehr Ahnung/ Erfahrung haben, ist das ja auch eine Erfahrung wert!


----------



## JesperMP (26 August 2015)

mac203 schrieb:


> Ach übrigens: unqualifiziert war lediglich die Antwort auf die ursprünglich Nachricht, in der der Autor der Meinung sei, ich hätte keine Ahnung wovon ich schreibe.


Ich glaube dies ist an mir gemeint. Ich weigere ein antwort dazu in der Hoffnung das diesen Ableitung von den ursprünglichen Thema damit stoppt !


----------



## zako (26 August 2015)

Knaller schrieb:


> Moin
> Einen Sollwert in 32Bit vorgeben, mag ja schön sein. Aber dann zeig mir eine Mechanik und auch einen Antrieb der das kann. Alleine die Verwindung der Motorwelle bei der krafterzeugung macht da die Hohe Auflösung platt.
> Da hab ich schon genug Diskussionen mit Kunden gehabt. Bestes Beispiel für mich VW in Braunschweig. Wollen im 1/1000mm positionieren haben aber keine konstante Temperatur in der Halle und ein Rolltor was schön die frische Luft rein lässt ob Sommer oder Winter.
> Siemens hat es erst in letzter Zeit geschafft diese Skalierungen automatisch vor zunehmen. Wo andere schon lange so weit waren.
> ...


SIEMENS schreibt für den SINAMICS S120 eine Drehzahlgenauigkeit von 0,001% in den Katalog. Meine eigenen Messungen haben gezeigt, dass das noch sehr konservativ angeben ist (man gibt z.B. im drehzahlgeregelten Betrieb einen Drehzahlsollwert von 600 rpm vor und misst z.B. nach 10s die Lageänderung - bei einen Geber mit 2^22 Auflösung pro Motorumdrehung müssten dann nach 100 Umdrehungen entsprechend eine Lageänderung von 100 * 2^22 Geberinkremente stattgefunden haben - und die Abweichung ist tatsächlich minimal). 
Typische Motorgeber haben eine Genauigkeit im Winkelsekundenbereich, mit Getrieben landet man schon im Winkelminutenbereich (auch mit entsprechenden Aufwand nachgemessen - man kann im FFT die Getriebestufen rauslesen). Mit entsprechenden mechatronischen KnowHow kann man das auch bereits in der Projektierungsphase berücksichtigen und dann evtl. Direktantriebstechnik einsetzen (mit entsprechender Messtechnik etc.).
Und hier ist dann bei der Antriebsauslegung und später bei der  IBN eine entsprechende Toolunterstützung notwendig (Scopeaufzeichnungen im Stromreglertakt, Bodediagramme, FFT´s, Mathematikfunktionen, Exportierbarkeit von Messergebnissen, ...). 



rostiger Nagel schrieb:


> Beckhoff hat sich gute Leute von einen Antriebshersteller eingekauft, die sich meiner Meinung nach von der
> Kompetenz mit Siemens messen können. So wie ich Beckhoff kennengelernt habe, stellen Sie sich den Anforderungen
> die ihnen gestellt werden. Da kann es se die OCTin, was du als Alleinstellungsmerkmal für Siemens darstellst, ganz schnell
> verschwunden ist.


Man entwickelt aber nicht über Nacht und führt in die Fertigung ein, z.B.
- Active Line Modules 
- Leistungsbereich von <1kW ... > MW Bereich auf einer Antriebsfamilie
- SAFETY SLS geberlos 
- entsprechend breites Motorenportfolio z.B. Direktantriebstechnik ,Spindelmotoren, Synchron- Reluktanzmotoren..
- Multi-Carrier-System 
- ....

Dem hingegen hat z.B. Beckhoff Kleinstmotoren, oder z.B. die "One Cable Technologie".  
Wenn man sich für ein System entscheidet muss man halt wissen, was einen wichtig ist.


----------



## Knaller (26 August 2015)

@Zako

SIEMENS schreibt für den SINAMICS S120 eine Drehzahlgenauigkeit von 0,001% in den Katalog. Meine eigenen Messungen haben gezeigt, dass das noch sehr konservativ angeben ist (man gibt z.B. im drehzahlgeregelten Betrieb einen Drehzahlsollwert von 600 rpm vor und misst z.B. nach 10s die Lageänderung - bei einen Geber mit 2^22 Auflösung pro Motorumdrehung müssten dann nach 100 Umdrehungen entsprechend eine Lageänderung von 100 * 2^22 Geberinkremente stattgefunden haben - und die Abweichung ist tatsächlich minimal). 

In deinem Text wirfst du 2 Dinge durcheinander. Einmal redest du von Drehzahl und einmal von Lage.  Durch erfassen einer Lage nach 10sec kannst du nichts über die Drehzahl Genauigkeit Aussagen.   Richtige wäre mit einem hochauflösenden analog Tacho eine Aussage zumachen.   Du hast eine Position ausgewertet und das kann man auch mit "wackligen" Drehzahl erreichen. 
Ist verführerisch so zu rechnen.   

Bei digitalen Messmöglichkeiten gilt:
Drehzahl sollte im kleinsten Messtakt mit möglichst vielen Werten aufgezeichnet werden. 

Positionen mit 0,001 ist doch normal

Ps:  bei Bosch Rexroth wird noch höher aufgelöst [emoji41]

Sent from my iPhone using Tapatalk


----------



## bike (26 August 2015)

Unsere Steuerungen löst auf 1/10 µmm das genügt noch?, denn Elektronen wollen wir noch? nicht bearbeiten.

Als die Rede auf OOP kam, habe ich festgestellt, dass der Charme in der Automation nachgelassen hat.
Einige User haben fest gestellt, dass OOP die Zukunft ist.
Ich habe jetzt die Frage, wenn auch OT:
Wer programmiert OOP und kann ein sinnvolles, funktionierendes Programm hier veröffentlichen, damit die ewig gestrigen Programmierer, so wie ich, es verstehen und dazulernen können.

Danke


bike


----------



## StructuredTrash (26 August 2015)

@bike
Ich programmiere OOP, habe aber bislang kein sinnvolles, funktionierendes Programm zustande gebracht. 
Spass beiseite: Es kommt darauf an, was Du unter "OOP programmieren" verstehst. Das Umsetzen von OO-Philosophieen und die Nutzung von OOP-Techniken, die eine Sprache zur Verfügung stellt, sind für mich nicht das Gleiche. Ich behaupte von mir, objektorientiert zu programmieren, verzichte aber, mit Ausnahme der Vererbung, weitgehend auf die OOP-Technologien, die in CoDeSys/TC3 neu eingeführt wurden, wie Methoden, Eigenschaften und Interfaces. Diese Dinge wurden unverändert aus der IT-Hochsprachenwelt übernommen und sind in meinen Augen für Automationsaufgaben ungeeignet bzw. überflüssig.


----------



## zako (26 August 2015)

Knaller schrieb:


> @Zako
> SIEMENS schreibt für den SINAMICS S120 eine Drehzahlgenauigkeit von 0,001% in den Katalog. Meine eigenen Messungen haben gezeigt, dass das noch sehr konservativ angeben ist (man gibt z.B. im drehzahlgeregelten Betrieb einen Drehzahlsollwert von 600 rpm vor und misst z.B. nach 10s die Lageänderung - bei einen Geber mit 2^22 Auflösung pro Motorumdrehung müssten dann nach 100 Umdrehungen entsprechend eine Lageänderung von 100 * 2^22 Geberinkremente stattgefunden haben - und die Abweichung ist tatsächlich minimal).
> In deinem Text wirfst du 2 Dinge durcheinander. Einmal redest du von Drehzahl und einmal von Lage. Durch erfassen einer Lage nach 10sec kannst du nichts über die Drehzahl Genauigkeit Aussagen. Richtige wäre mit einem hochauflösenden analog Tacho eine Aussage zumachen. Du hast eine Position ausgewertet und das kann man auch mit "wackligen" Drehzahl erreichen.
> Ist verführerisch so zu rechnen.
> ...


In meinen Beispiel gebe ich einen Drehzahlsollwert von 600rpm über eine Zeit von 10sec vor. Ich setze einen Geber ein, 
welcher eine Lageänderung von 2^22 pro Umdrehung macht. Wenn ich nun 10 Sekunden mit einer Solldrehzahl von 600 rpm drehen lasse, 
erwarte ich eine Lageänderung von 100 * 2^22 = 419430400. Falls sich die Lage nur um 419430000 Inkremente geändert hätte, ergibt sich eine tatsächliche Drehzahl von 599,9994278 rpm in diesen Zeitraum.
Somit ist die Lage durchaus ein Maß für die Drehzahlgenauigkeit. Die Drehzahlgenauigkeit ist z.B. nicht zu verwechseln mit der "Drehzahlwelligkeit" (aber ich will hier keinen Exkurs über Messtechnik durchführen).


Knaller schrieb:


> Positionen mit 0,001 ist doch normal
> Ps: bei Bosch Rexroth wird noch höher aufgelöst [emoji41]


Man kann beim SINAMICS S120 jedes Geberinkrement ausnutzen. Ob man nun in  µm oder nm  oder sonstwie auflösen kann, hängt vom eingesetzten Geber und von der Mechanik (incl. Getriebe) ab.


----------



## Knaller (26 August 2015)

Moin. 
Hab 30 Jahre Erfahrung in der Antriebstechnik.  Ich sehe das da anderes.   Den Antrieb der auf 1 Inkrement der internen Auflösung stehen bleibt zeigst du mir mal.   Alleine die Toleranzen der Bauteile in den Reglern ist so groß das dies nicht möglich ist.   Das Rauschen lässt ein Wackeln zu.   


Sent from my iPhone using Tapatalk


----------



## RobiHerb (27 August 2015)

*OOP ist OK*



StructuredTrash schrieb:


> @bike
> Ich programmiere OOP,  ... verzichte aber, mit Ausnahme der Vererbung, weitgehend auf die OOP-Technologien, die in CoDeSys/TC3 neu eingeführt wurden, wie Methoden, Eigenschaften und Interfaces. ... .



In meinem letzten Projekt (Fahrerloses Fahrzeug SIL 2 programmiert in ST/Codesys 3.x) habe ich extensiv diese Technik verwendet.

Anstelle die FB aufzurufen werden Methoden verwendet, auf interne Variablen der FB wird LESEND über Eigenschaften zugegriffen.



Hier in etwa (simplifiziert) der Ablauf der Antriebsmotoren (in diesem Falle elektrisch).

Interfaces sind ebenfalls sehr sinnvoll, wenn wie in diesem Fall es möglich sein soll, Fahrzeuge mit Verbrennungs Motor alternativ mit Elektro/Akku Antrieb oder AllradAntrieb alternativ FrontAntrieb oder HeckAntrieb auszustatten. Die Interfaces der Alternativen sind jeweils gleich, damit ist die restliche Software entkoppelt von der speziellen Hardware.

Da die Software von Organisationen wie TÜV und Freunden begutachtet wird, war eine OOP Implementation sehr hilfreich und fast unumgänglich.

Nebenbei gesagt, OOP in Kombination mit Dokumentation und Schulung ist meist auch effektiver als traditionelle Technik für alle Beteiligten.


----------



## StructuredTrash (27 August 2015)

Es hängt sicher von der Anwendung ab, wie sinnvoll der Einsatz der  OOP-Techniken ist. Für mich im Feld-, Wald- und Wiesen-Maschinenbau  überwiegen die Nachteile.
Die Variablen und zurückgemeldeten  Ergebnisse von Methoden und Eigenschaften sind temporär und somit bei  laufendem Programm nicht zu beobachten. Genau das ist aber ein Muss für  mich. Wenn ich erst mal die Maschine an der SPS dranhängen habe, kann  ich nicht mehr mit Breakpoints arbeiten. Deshalb halte ich die  klassische statische VAR_INPUT/VAR_OUTPUT-Schnittstelle der FB's für  besser geeignet. Und auch die lässt sich durch Vererbung in ein  OOP-Konzept integrieren.
Nahezu jeder meiner FB's, der  Steuerungsaufgaben erledigt, beinhaltet auch zyklisch zu bearbeitende  Funktionalität. Wenn ich die in Methoden packe, die von ihrer Art her ja  eher für einen ereignisgetriggerten Aufruf gedacht sind, muss ich  höllisch aufpassen, dass ich in jedem Zyklus genau eine der Methoden  aufrufe. Auf den zyklischen Aufruf des FB-Hauptcodes mag ich deshalb  nicht verzichten. Das heisst nicht, dass ich keine ereignisgetriggerten  Funktionen nutze. Z. B. übergebe ich einem Servoantriebs-FB seine  Fahrbefehle schon auf diese Weise, aber dafür brauche ich keine Methode,  eine Aktion tut es schon seit TC2 auch.
Den Sinn von Interfaces sehe  ich trotz wohlgemeinter Beispiele immer noch nicht. Die braucht man  doch nur, wenn man zur Laufzeit nicht weiss, welchen konkreten FB-Typ  man ansprechen muss, und davon sind die Maschinen, mit denen ich zu tun  habe, noch weit entfernt.


----------



## Gerri (28 August 2015)

TwinCat hat bei weitem bessere DIagnosemöglichkeiten was Hardware und SPS Programm betrifft


----------



## PN/DP (28 August 2015)

Gerri schrieb:


> TwinCat hat bei weitem bessere DIagnosemöglichkeiten was Hardware und SPS Programm betrifft


Welche denn zum Beispiel?

Harald


----------



## bike (28 August 2015)

Gerri schrieb:


> TwinCat hat bei weitem bessere DIagnosemöglichkeiten was Hardware und SPS Programm betrifft



Kennst du Siemens?
Wie Harald schon gefragt hat:
Nenne ein Beispiel.

Ein extra Danke an Structuered Trash. 
  Du hast sehr genau die Erfahrung und Anforderungen an die Automatisierung dargestellt.
So sehe ich es auch und zeigt meine Erfahrung.
Man kann auch mit den Standardmöglichkeiten von TwinCat und Siemens mit Objekten , die mit einzelnen Bausteinen realisiert werden, programmieren. 


bike


----------



## Interface (28 August 2015)

Gibt es bei Siemens eine API (Programmierschnittstelle), um Code z.B. mit einem Projektierungstool zu generieren oder z.B. zu Dokumentationszwecken auszulesen?

Bei TwinCAT ist das über das Automation Interface sehr komfortabel möglich. Man kann das TwinCAT-Projekt und sogar einen FB geöffnet haben und gleichzeitig im Hintergrund Code einfügen, was dann sofort angezeigt wird. Auch zur automatisierten Erstellung von Bibliotheken habe ich mir ein Programm geschrieben, das via Automation Interface auf TwinCAT zugreift.

In Codesys ist Code-Generierung/-Auslesen mit Python etwas rudimentärer, aber auch noch möglich.


----------



## Gerri (28 August 2015)

Der ganze systemmanager mittles CoE pnline diagnose. Da kannst du vom bus alles rauslesen. Twinsafe fehler ebenso. Mit breakpoints und flusscontrolle ist St im PLC cpntrol siemens auf überlegeb. Cpu auslastung bzw tasküberschritungen ebenso. OB s zur diagnose sind jedenfalls mal kacke. Genauso wie die kramphafte diagnose über Geräteadressen. 

Gesendet von meinem SM-P600 mit Tapatalk


----------



## JesperMP (28 August 2015)

Gerri schrieb:


> Der ganze systemmanager mittles CoE pnline diagnose. Da kannst du vom bus alles rauslesen.


Ich war bei eine Vorstellung bei Siemens, wo ich Proneta gesehen hat. Das war relative beeindruckend. Proneta zeigt was gibt es tatsächlich am Bus.
Sonnst gibt es den Topology view in STEP7 und sogar der SPS Webserver. Das Topology View zeigt dir wie das Bus aussehen soll. Also wenn ein konfigurierte Teilnehmer gestört ist, oder fehlt. 
Diese Tools zusammen finde ich gut.



Gerri schrieb:


> OB s zur diagnose sind jedenfalls mal kacke.


Die Fehler-OBs sind da für das Anwenderprogram, so das es auf Fehler reagieren kann. Für Diagnose gibt es die STACKs, der Diagnose Puffer, und der Hardware Diagnostics.



Gerri schrieb:


> Genauso wie die kramphafte diagnose über Geräteadressen.


??

Ein bisschen mehr Details zu deine Erfahrungen wäre nicht schlecht. Sonnst wird es nur zu noch ein Streit über Wörter.


----------



## bike (28 August 2015)

Jesper, lass es.
Der Kollege? kann dir keine sinnvolle Beschreibung geben, was an Siemens schlechter ist als bei TwinCat.
Wer Siemens nicht kennt, der kann auch nur Mist über die vorhandenen Möglichkeiten schreiben.
Wenn jemand wegen Diagnose schreibt OBs sind Scheiße, dann erübrigt sich jede weitere Diskussion.


bike


----------



## oliver.tonn (28 August 2015)

Können wir diesen Glaubenskrieg mal beenden, das bringt doch nichts.
Einigen wir uns doch darauf, dass sowohl Siemens als auch Beckhoff  (oder Beckhoff als auch Siemens) ihre guten und schlechten Eigenschaften haben. Man kann mit beiden etwas gutes zustande bringen, was viele Produkte ja beweisen, oder eine Katastrophe produzieren. Und mit OOP ist es auch so, lasst uns einfach akzeptieren, dass einige es sinnvoll nutzen können für andere es jedoch keinen Sinn macht. Ich glaube einigen im Forum würde ein wenig Offenheit ganz gut tun, seine Meinung zu sagen ist ja in Ordnung, aber das artet hier langsam wieder aus.

Von irgendwas mit Internetzugang gesendet.


----------



## zako (29 August 2015)

oliver.tonn schrieb:


> Können wir diesen Glaubenskrieg mal beenden, das bringt doch nichts.
> Einigen wir uns doch darauf, dass sowohl Siemens als auch Beckhoff  (oder Beckhoff als auch Siemens) ihre guten und schlechten Eigenschaften haben.



Das ist aber gerade der Sinn dieses Thema´s mal konkrete Unterschiede, bzw. Vor- und Nachteile herauszuarbeiten. Aus meiner Sicht war bisher der beste Beitrag der des Themenstarters am Anfang. Hier wurde noch versucht möglichst Fakten zu nennen (und noch ein paar, wo konkret auf die Punkte eingegangen wurde).
Eigentlich müsste man sogar Aufgabenstellungen definieren. Die Forumsmitglieder könnten dann beschreiben (z.B. mit Screenshot´s) wie das mit welchen System umsetzbar ist. 
Z.B.
1.) An einer IO- Baugruppe die am Ethercat bzw. Profinet hängt wird die Spannungsversorgung abgeschalten. Wie ist die Reaktion? Läuft der restliche Bus weiter? Wie sind die Fehlermeldungen / sind diese aussagekräftig?  ...
2.) Es soll eine Achse per Taste an einen HMI relativ positioniert werden. Was muss bei vorhandener Hardware getan werden (hier am besten gleich ein Video vom Bildschirm mitschneiden). Im zweiten Schritt am besten gleich mit SAFETY über Bus.
3.) Portierung einer mit Matlab Simulink erstellten Regelungsstruktur (z.B. einfacher P- Regler). Wie kann dieser als Regler in meinen System eingebunden werden (einmal Twincat, einmal Siemens- Steuerung). Protokollierung der Vorgehensweise - evtl. auch per Video.
4.) ...

Das Problem ist nur, dann kann man plötzlich nicht mehr nur rumlabern, sondern man müsste konkret was tun. Und da würde sich plötzlich der Kreis derer, die hier etwas beitragen schlagartig reduzieren ...


----------



## oliver.tonn (29 August 2015)

Was den TE angeht stimme ich Dir voll und ganz zu. Die Vor- und Nachteile aufzuzeigen ist ja auch in Ordnung, nur vermisse ich dabei oft die Sachlichkeit und Offenheit für anderes. Wobei letzteres mir bis vor kurzem bei einer Angelegenheit auch fehlte. Ich habe mich lange nicht mit Siemens Steuerungen beschäftigt. Letztes Jahr habe ich dann mal etwas Geld in die Hand genommen und mir zwei CPUs samt Zubehör und einem Testrack gekauft und musste feststellen, dass Siemens auch einige tolle Konzepte hat die besser als bei TwinCAT/Codesys sind, anderes fand ich wiederum bei Beckhoff besser.

Von irgendwas mit Internetzugang gesendet.


----------



## Larry Laffer (30 August 2015)

So ... Ich bin nun auch wieder "an Bord".

Also erstmal Danke an Zako, dass er versucht hat, die Grund-Intension dieses Thread wieder ein bißchen heraus zuspielen.
Du  hast allerdings nicht so ganz getroffen - ich bin so vermessen, immer  noch zu hoffen, dass sich Dinge ändern können. Hier konkret bin ich der  Meinung, dass die mit "Neg:" titulierten Unterpunkte einfach beseitigbar  wären. 

Zu den weiteren Unter-Diskussionen :

Da war  einmal das Antriebs-Thema. Hier muß ich sagen, dass es mit persönlich  stellenweise etwas zu abstakt wurde. Das kann aber daran liegen, dass  für mich Servo-Achsen für andere (einfachere) Aufgaben zum Einsatz  kommen (meißtens irgend etwas mit P2P). Auf spezielle Tricks verzichte  ich hier meißtens.

Dann war da noch das OOP-Thema. Auf OOP kommt  man m.E. automatisch früher oder später wenn man über wiederverwendbare  Bausteine nachdenkt. Das fängt vielleicht ganz klein an in dem man sich  einen FB für einen FU baut oder einen Servo-Antrieb. Dann kommt man  vielleicht auf die Idee, dass z.B. der Servo ja auch eine Aufgabe hat :  Fahre von A nach B. Nun könnte man sich ja einen Baustein erstellen, der  das erledigt ... und dabei mit dem FB Servo selbst zusammen arbeitet  (ihn benutzt). Naja ... und so weiter. Jetzt hat dieser FB am Ende  vielleict noch ein paar weitere Funktionen - es werden aber immer die  selben IO's verwendet. Nun könnte z.B. "Fahre von A nach B" eine Methode  sein und "Fahre Referenz" eine andere und "Fahre zurück nach A" wieder  eine usw. 
Ich denke mal, die meißten werden sowieso schon so ewas haben - es vieleicht nur nicht so nennen (es heißt aber so).
Man muß das aber tatsächlich für sich entdecken ...

Gruß
Larry

Nachsatz:
Ich freue mich übrigens sehr, dass die Anzahl der "Spam"-Beiträge in diesem Thread vergleichsweise sehr sehr wenige waren ...


----------

