TwinCat V3.x versus Siemens

[mac203]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

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

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]

@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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

@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]

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

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

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

OOP ist OK

@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]

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]

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

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

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

Welche denn zum Beispiel?

Harald

 

[bike]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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.

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.

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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.