TwinCat V3.x versus Siemens

Zuviel Werbung?
-> Hier kostenlos registrieren
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 ... ;)
 
Zuletzt bearbeitet:
Ich möchte auch mal meinen Senf dazu geben.

Thema Betriebssysteme:
TwinCAT: Von Windows, TwinCAT/BSD und bald LinuxRT und Container
Siemens SPS bieten hier nur die integrierte SPS oder bei den Software Controllern Windows oder Linux
Ich sehe hier also keine Vor / Nachteile für Beide Steuerungen

Stabilität und Support:
Bei der IDE sind Beide gleich auf. Hin und wieder stürzt bei mir sowohl die XAE-Shell als auch TIA-Portal ab. Was ich als nervig bei TIA-Portal empfinde ist, dass die Absturzberichte die man automatisiert an Siemens schickt sowieso keiner ließt.

Nicht alles was in TwinCAT funktionieren sollte, funktioniert auch Reibungslos. Wenn man sich jedoch an den Support wendet, wird das Problem beim nächsten Update behoben. Leider bekommt man von Beckhoff zum Update keine Änderungsliste mit.

Kapselung:
OOP sehe ich ebenfalls als Pluspunkt, Siemens versucht das etwas mit SoftwareUnits umzusetzen, hier aber auch mit Einschränkung auf 255 SU.
  • Bei OOP sehe ich den Vorteil bei der Kapselung von Daten und Methoden / Eigenschaften an sich. Werte von Variablen können einfach überschrieben werden, bei Zugriff auf Getter-Methoden über z.B. Interfaces, erhält man immer den richtigen Wert
  • Man muss nicht zyklisch Werte bearbeiten die eventuell nicht im Zyklus gebraucht werden, sondern werden in der Eigenschaft / Methode nur bearbeitet / berechnet wenn sie gebraucht werden. Klar kann man das auch immer mit Bedingungen Abfangen...

Debuggen:
Bei den Programmiersprachen finde ich KOP gerade bei Boolschen Verknüpfungen deutlich einfacher zu debuggen als in ST und hat daher seine Berechtigung. Ich habe aber noch nicht mit dem KOP Editor von Beckhoff gearbeitet. Der Vorteil von ST ist eben, dass man schneller arbeiten kann als alles mit der Maus hin und her zu ziehen. Bei Siemens stehen die Aktualwerte dann rechts in einem getrennten Abschnitt was vom Handling nicht optimal ist. Ab 4026 hat Beckhoff bei der Anzeige zusätzlich noch einen kleinen Scope.

Verhalten bei Kritischen Fehlern:
Bei Null-Division, Array-Bereichsüberschreitungen usw. kann man das Verhalten in TwinCAT steuern und muss nicht zwangsläufig zum Stopp der SPS führen. Ebenso gibt es __try, __catch ... . Und Exceptions können auch ausgelöst werden.

Siemens zeigt hier aber besser auf, wo die Exception ausgelöst wurde. Zwar gibt es bei Beckhoff CoreDumps jedoch meldete TwinCAT bei meinem Versuch nach dem Importieren, dass der Software-Stand nicht übereinstimmen würde.

Globale DUTs / Structs / Enums
Im Vergleich ist doch TwinCAT hier besser. ENUMs gibt es in Siemens nicht. Structs sind bei Siemens ebenfalls nur Global und nur im Ordner Datentypen zu finden. Bei TwinCAT kann man sich das immerhin verschieben wohin man will, auch in den POU Ordner des FBs um die Struktur schneller zu finden wenn man es bearbeiten will. Aber ich gebe zu, dass Codesys es hier besser macht.

UNIONS sind unter TIA mit dem ALIAS in der Deklaration meiner Meinung nach schlechter umgesetzt.

Hardware Mapping:
Man kann Variablen im FB als "AT %I/O*" deklarieren und diese dann zur Hardware mappen. Man muss also nicht eine Globale Variablenliste hierfür erstellen und die Variable dann an den Eingang des FBs legen.

Hardware auslesen:
Meine Erfahrung: Kann klappen, muss aber nicht. Ich habe das Problem beim Fanuc Roboter gehabt, dass die falsche Schnittstellenlänge ausgelesen wurde. Erst durch exportieren und anpassen der Beschreibungsdatei, konnte ich das Problem beheben. Hier sehe ich in der Einfachheit schon Vorteile bei Siemens.

Versionsverwaltung:
Die Integration von GIT ist in TwinCAT ist deutliche besser als in TIA Portal und hier arbeitet Beckhoff weiter daran mit dem PLC++

Performance:
Hier sehe ich den Vorteil bei Beckhoff. Der Einsatz von Strings um z.B. TCP/IP - Pakete zu bearbeiten von Scannern, RFID, usw .... nagen schon sehr an der Performance der Siemens SPS.

Tools zur Automatischen Generierung von Code:
Ich habe hier keine Erfahrung aber mit meinem Halbwissen, kann man die Codeerstellung auf folgende Weise automatisieren.
Ab TIA V18 kostet die DLL von Siemens extra und eingeschränkt auf die Möglichkeiten der DLL. Bei TwinCAT ist der Quellcode XML-Basiert und kann theoretisch mit allen möglichen Programmiersprachen generiert werden. Auch hier verschafft wahrscheinlich in Zukunft PLC++ weitere Verbesserungen.

Kosten der Entwicklungsumgebung:
Auf TwinCAT kann man kostenlos entwickeln und testen. (Auch wenn die SImulation nicht unbedingt in 4024 funktioniert, so kann man sich doch eine Virtuelle Maschine oder alten PC mit TwinCAT/BSD installieren) und die 7-Tage Testlizenz immer wieder aktivieren.

VISU:
Beckhoff bietet mit der TE2000 / TF2000 die TwinCAT HMI ein ziemlich flexibles integriertes HMI. Ist meiner Meinung nach aber komplizierter als die WinCC / WinCC Unified Umgebung und es ist Ratsam Kenntnisse in der Webentwicklung HTML, CSS, JavaScript / TypeScript zu haben. Zudem ist sie nicht so gut integriert wie WinCC in TIA Portal. Mappen der Variablen ist erst möglich wenn die SPS Software in die Steuerung geladen wurde bzw. über das importieren von TMC Dateien.

Mein Fazit:
TwinCAT ist flexibler, was es etwas kompliziert er macht und damit auch mehr Möglichkeiten hat Fehler zu machen. Ich bin aber der Meinung, dass SPS-Programmierung sich sowieso immer mehr Richtung Hochsprachen entwickelt um verschiedenen Möglichkeiten der Anbindung an IoT, Datenbanken, Produktdatenerfassung / Auswertung, predictive maintenance, IT Sicherheit, .... uvm. gerecht zu werden was zu S7 Zeiten in dem Maße noch nicht Thema war.
 
Eine Thema wäre die Fehlerhantierung von Hardwarefehler zur Laufzeit.
Meiner Meinung nach ist die Hardwarediagnostik in TIA die Industriestandard.
Und man kann mittels einfachen Drag-and-drop dieselbe umfassende Hardwarediagnostik in die WinCC HMI haben. Das ist für mich eine grossen Vorteil mit Siemens S7. Selber so eine Hardwarediagnostik für die End-Anwender zu erstellen wurde unendlich viel Zeit nehmen.

(wie umfassend die Hardwarediagnostik in Twincat ist weis ich nicht).
 
JesperMP schrieb:
Eine Thema wäre die Fehlerhantierung von Hardwarefehler zur Laufzeit.
Meiner Meinung nach ist die Hardwarediagnostik in TIA die Industriestandard.
Und man kann mittels einfachen Drag-and-drop dieselbe umfassende Hardwarediagnostik in die WinCC HMI haben. Das ist für mich eine grossen Vorteil mit Siemens S7. Selber so eine Hardwarediagnostik für die End-Anwender zu erstellen wurde unendlich viel Zeit nehmen.

(wie umfassend die Hardwarediagnostik in Twincat ist weis ich nicht).
Zum Vergrößern anklicken....
Hier hat Beckhoff für die TcHMI Lösung auch recht umfangreiche Drag&Drop Funktionen (bspw. EcDiagnostics) für die Visualisierung. Du erhältst automatisch eine vollständige Übersicht deines gesamten EtherCAT Bussystems und kannst dir Zustands- Kommunikations- und Datenmetriken anzeigen lassen. Außerdem kann man auch direkt IOs forcen wenn nötig.
 
Zuviel Werbung?
-> Hier kostenlos registrieren

TwinCAT CMI - Features

cmi.beckhoff-cloud.com cmi.beckhoff-cloud.com

Feature > Analyse & Diagnose > EtherCAT Diagnose

Mächtiger geht es kaum. Da kann man direkt den IO-Test machen inkl. Forcing usw.

Sowas ähnliches kenne ich bei Siemens nur von PCS7.

Prinzipiell muss man das auch nicht von Beckhoff nehmen. Man kann sich das auch alles über die ADS API selber bauen.
 
Am Ende muss man sagen, dass es sowohl bei Siemens als auch bei Beckhoff (viel) Licht und Schatten gibt. Manchmal würde ich mir ein Entwicklungssystem (oder gesamtes SPS Ökosystem) wünschen, welches die Vorteile und Siemens und Beckhoff vereint und damit in vielen Aspekten die spezifischen Nachteile ausgleicht.
 
Mirko123 schrieb:
... müsste nicht mittlerweile Simatic AX in den Vergleich mit aufgenommen werden?
Zum Vergrößern anklicken....
Ich denke, dafür ist es noch ein paar Jahre zu früh. Soweit ich weiß, ist AX noch immer in der Betaphase und wird im ersten Schritt in erster Linie "nur" zur Bibliotheksentwicklung für TIA nutzbar sein. Zwar soll auch HW Config, Technologieobjekte usw. perspektivisch möglich werden - aktuell spricht Siemens hierbei aber erstmal nur von "einfachen Maschinen".
Aber definitiv hat das in meinen Augen richtig Potential.
 

Similar threads

escride1
erstmalige Installation von TwinCat mit Problemen
2
Antworten
38
Aufrufe
8K
PatrickSt
P
M
TwinCAT HMI mit SPS-Datentypen (Struct, Enum) mit TMC-Datei
Antworten
5
Aufrufe
354
mgl
M
Gurke258
TwinCat 3.1 4026.35 Aufgabenliste
Antworten
0
Aufrufe
623
Gurke258
Gurke258
B
Twincat Visu nachträglich in ein vorhandenes Projekt einfügen
Antworten
11
Aufrufe
513
blimaa
B
Z
Torque Control Baustein | Torque währrend der Bewegung ändern
Antworten
4
Aufrufe
1K
zero
Z
Zurück
Oben