Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 9 von 11 ErsteErste ... 7891011 LetzteLetzte
Ergebnis 81 bis 90 von 101

Thema: TwinCat V3.x versus Siemens

  1. #81
    Registriert seit
    15.08.2011
    Beiträge
    383
    Danke
    2
    Erhielt 73 Danke für 71 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von bike Beitrag anzeigen
    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!
    Geändert von mac203 (26.08.2015 um 12:34 Uhr)

  2. #82
    Registriert seit
    06.10.2004
    Ort
    Kopenhagen.
    Beiträge
    4.626
    Danke
    377
    Erhielt 801 Danke für 642 Beiträge

    Standard

    Zitat Zitat von mac203 Beitrag anzeigen
    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 !
    Jesper M. Pedersen

  3. #83
    Registriert seit
    05.04.2012
    Beiträge
    952
    Danke
    94
    Erhielt 216 Danke für 191 Beiträge

    Standard

    Zitat Zitat von Knaller Beitrag anzeigen
    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, ...).

    Zitat Zitat von rostiger Nagel Beitrag anzeigen
    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.
    Geändert von zako (26.08.2015 um 15:04 Uhr)

  4. #84
    Registriert seit
    13.09.2007
    Beiträge
    566
    Danke
    50
    Erhielt 65 Danke für 57 Beiträge

    Standard

    @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 TwinCat V3.x versus Siemens

    Sent from my iPhone using Tapatalk
    Geändert von Knaller (26.08.2015 um 16:41 Uhr)
    Zitieren Zitieren TwinCat V3.x versus Siemens  

  5. #85
    Registriert seit
    03.04.2008
    Beiträge
    6.200
    Danke
    237
    Erhielt 815 Danke für 689 Beiträge

    Standard

    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
    "Any fool can write code that a computer can understand.
    Good programmers write code that humans can understand."
    --Martin Fowler

  6. #86
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    752
    Danke
    27
    Erhielt 165 Danke für 143 Beiträge

    Standard

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

  7. Folgende 2 Benutzer sagen Danke zu StructuredTrash für den nützlichen Beitrag:

    Blockmove (26.08.2015),zako (26.08.2015)

  8. #87
    Registriert seit
    05.04.2012
    Beiträge
    952
    Danke
    94
    Erhielt 216 Danke für 191 Beiträge

    Standard

    Zitat Zitat von Knaller Beitrag anzeigen
    @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).
    Zitat Zitat von Knaller Beitrag anzeigen
    Positionen mit 0,001 ist doch normal
    Ps: bei Bosch Rexroth wird noch höher aufgelöst TwinCat V3.x versus Siemens
    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.

  9. #88
    Registriert seit
    13.09.2007
    Beiträge
    566
    Danke
    50
    Erhielt 65 Danke für 57 Beiträge

    Standard

    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
    Zitieren Zitieren TwinCat V3.x versus Siemens  

  10. #89
    Registriert seit
    09.11.2007
    Ort
    Rhein Main (Darmstadt)
    Beiträge
    663
    Danke
    61
    Erhielt 112 Danke für 80 Beiträge

    Standard

    Zitat Zitat von StructuredTrash Beitrag anzeigen
    @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.

    OOP.jpg
    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.
    Als Freelancer immer auf der Suche nach interessanten Projekten.
    Zitieren Zitieren OOP ist OK  

  11. #90
    Registriert seit
    25.11.2010
    Ort
    OWL
    Beiträge
    752
    Danke
    27
    Erhielt 165 Danke für 143 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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.

  12. Folgender Benutzer sagt Danke zu StructuredTrash für den nützlichen Beitrag:

    bike (28.08.2015)

Ähnliche Themen

  1. Memcpy versus For / Next
    Von shrimps im Forum Programmierstrategien
    Antworten: 1
    Letzter Beitrag: 03.02.2015, 15:58
  2. Android versus SPS
    Von standroid im Forum Werbung und Produktneuheiten
    Antworten: 47
    Letzter Beitrag: 11.01.2015, 16:44
  3. Steurungsoptimierung versus Notaus-Relais
    Von tofebto im Forum Maschinensicherheit - Normen und Richtlinien
    Antworten: 6
    Letzter Beitrag: 27.09.2011, 19:16
  4. S7-DP versus DP-DP-Koppler
    Von WL7001 im Forum Simatic
    Antworten: 8
    Letzter Beitrag: 05.02.2009, 20:01
  5. ET200M versus ET200S
    Von IPS im Forum Simatic
    Antworten: 10
    Letzter Beitrag: 02.09.2008, 20:38

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •