- Beiträge
- 22.419
- Reaktionspunkte
- 7.464
-> Hier kostenlos registrieren
Das hat ja auch niemand bezweifelt. Das ist allgemein bekannt.
TC3: Wann nutzt Ihr Methoden und wann "nur" den FB
- Ersteller oliver.tonn
- Erstellt am
-> Hier kostenlos registrieren
OP
- Beiträge
- 5.839
- Reaktionspunkte
- 1.243
OK, sorry, das hörte sich für mich anders an.
seehma
Level-1
- Beiträge
- 112
- Reaktionspunkte
- 31
-> Hier kostenlos registrieren
Wow, hier gehts ja rund. Ich sehe schon, war viel zu lange nicht mehr im Forum -> spannende Diskussion.
Vielleicht hilfts wenn ich unsere Story ein wenig erzähle...
(Achtung: heißt nicht das ist der einzig richtige oder wahre weg, es war halt ein Weg...)
Also wir kommen von der Steuerungsprogrammierung mit Linux und Echtzeitunterbau, Programmierung in C (Antriebe Sercos). Hochsprache mit allen Feinheiten und Raffinessen, extrem viel Performance aber leider auch hoher administrativer Aufwand in der Basisentwicklung (Treiber, OS-Umstieg, Entwicklungssystem, CrossCompile). Wir wollten dann auf einen Systemanbieter (2012) wechseln weil wir uns diesen "Aufwand" sparen wollten und es ist dann der große Rote geworden, der zu dieser Zeit mit Twincat 3.0 ein extrem innovatives Produkt gebracht hat. Objektorientierung, Multitasking, 64Bit usw...
Wir haben uns dann Anfangs voll drauf gestürzt und die komplette Welt der Objektorientierung ausgenutzt. Es wurde eine Art Vorlage entwickelt wie man Maschinen programmiert damit alle gleich arbeiten, es gibt einen Satz an Basisbibliotheken, welche die wesentlichen Funktionen abdeckt (Achsen, IOs, Aktuatoren, ...) und so entstand mal eine erste Version. Die Performance war eher Mau und teils war es auch viel zu kompliziert gemacht, vor allem in Hinblick auf Wiederverwendbarkeit. Es war zwar schön durchdesignt aber mit den falschen Randbedingungen. Wir dachten einfach so eine SoftSPS ist ein wahres Rechenwunder, ab einer gewissen Zykluszeit und größe der Maschine wirds halt auch für eine SoftSPS eng.
In Version zwei sind wir einige dieser Punkte angegangen und haben das ganze nochmal gründlich überarbeitet, größtenteils wurden auch ältere Projekte noch portiert. Es wurden die Performance-Engpass-Verursacher gesucht und entfernt, der Aufbau etwas entwirrt und auch gewisse Dinge noch stärker standardisiert. Leider haben wir es dann aber auch gerade beim Thema Initialisierung und Abstraktion wieder übertrieben und kamen auch hier nach ein paar Sondermaschinen drauf: das geht noch besser.
Ein paar kleine Änderungen wurden dann noch eingearbeitet, sozusagen eine V2.1 und dies verwenden wir jetzt für alle neue Projekte innerhalb unserer Firma. Was sind nun solche Projekte: Im Wesentlichen Sondermaschinen für die interne Produktion. Dabei gehts um ganz kleine Maschinen mit 1-5 Achsen und ein paar hundert IO-Punkten bis rauf zu großen Maschinen 170 Achsen und ein paar Tausend IO-Punkten. Alles mit dem selben Framework und eben auch Aufbau.
Der Vorteil hier ist, durch den klar dokumentierten Aufbau kann man die Mitarbeiter sehr flexibel für Erweiterungen und Verbesserungen (extrem wichtig bei Sondermaschinen da dies meist Prototypen sind) einsetzen. Sie finden sich schnell zurecht und finden die jeweiligen Stellen wo programmiertechnisch angesetzt werden muss, falls es mal Probleme gibt oder man was neues braucht.
Was ich hier sagen will, die Objektorientierung ermöglicht und vereinfacht vieles (Wiederverwendung, Struktur und was nicht zu vernachlässigen ist die Akzeptanz unter den jüngeren Entwicklern/Bewerbern), aber man muss extrem aufpassen dass man sich nicht verhaspelt. Im wesentlichen arbeitet man mit einem hochverfügbaren System das Echtzeit beherrschen soll und da darf man gewisse Dinge einfach nicht tun. Das war schon unter der Linux Steuerung so und ist auch bei Codesys V3 Systemen so. Man darf und kann PLC-Programmierung nicht mit einer "normalen" IT Applikation vergleichen. Ich muss auch sagen, das wissen aus der "C-Welt", also wie das ganze auch dann im Speicher und auf der CPU abläuft, hilft hier natürlich auch stark.
Die Version 3 dieses Frameworks wird jetzt von einer externen Firma nochmals komplett neu entwickelt und die wirds bald inkl. der Libs Online als OpenSource System geben.
Zum Thema KI hab ich lachen müssen. Viele reden von KI und haben ein paar Whitepaper von Herstellern durchgelesen. Auch wir hatten solche Firmen da und haben auch einiges umsetzen können, richtig was gebracht hats nur in wenigen Fällen. Meiner Meinung nach fängt das Problem ja schon bei der Datenaufzeichnung, Haltung und Qualität an. Wie schnell wird aufgezeichnet, wie deterministisch, wie werden die Daten abgespeichert, wo werden sie abgespeichert und wie generisch sind sie gespeichert. Im Sondermaschinenbau natürlich möglich, aber ohne starke Standardisierung nur sehr schwer!
Insgesamt muss ich sagen sind wir doch sehr froh, dass wir komplett auf die Objektorientierung gesetzt haben, da wir dadurch die benötigte Komplexität der Maschinen und auch der Prozesse übersichtlicher und einfacher abbilden konnten. Die Wiederverwendbarkeit ist hiermit auch viel einfacher und besser möglich. Weiters haben einige jüngere Mitarbeiter das Feedback gegeben, dass klassische PLC-Programmierung mit AWL, FUP und KOP oder auch ohne moderne Paradigmen der OOP sie eher zum Jobwechsel gebracht hätten als zum Job halten. Die Learnings die wir mit OOP und dem Codesys System hatten möchte ich eh nochmal niederschreiben, vll teil ich das dann mal hier mit euch...
Sg
M.
Vielleicht hilfts wenn ich unsere Story ein wenig erzähle...
(Achtung: heißt nicht das ist der einzig richtige oder wahre weg, es war halt ein Weg...)
Also wir kommen von der Steuerungsprogrammierung mit Linux und Echtzeitunterbau, Programmierung in C (Antriebe Sercos). Hochsprache mit allen Feinheiten und Raffinessen, extrem viel Performance aber leider auch hoher administrativer Aufwand in der Basisentwicklung (Treiber, OS-Umstieg, Entwicklungssystem, CrossCompile). Wir wollten dann auf einen Systemanbieter (2012) wechseln weil wir uns diesen "Aufwand" sparen wollten und es ist dann der große Rote geworden, der zu dieser Zeit mit Twincat 3.0 ein extrem innovatives Produkt gebracht hat. Objektorientierung, Multitasking, 64Bit usw...
Wir haben uns dann Anfangs voll drauf gestürzt und die komplette Welt der Objektorientierung ausgenutzt. Es wurde eine Art Vorlage entwickelt wie man Maschinen programmiert damit alle gleich arbeiten, es gibt einen Satz an Basisbibliotheken, welche die wesentlichen Funktionen abdeckt (Achsen, IOs, Aktuatoren, ...) und so entstand mal eine erste Version. Die Performance war eher Mau und teils war es auch viel zu kompliziert gemacht, vor allem in Hinblick auf Wiederverwendbarkeit. Es war zwar schön durchdesignt aber mit den falschen Randbedingungen. Wir dachten einfach so eine SoftSPS ist ein wahres Rechenwunder, ab einer gewissen Zykluszeit und größe der Maschine wirds halt auch für eine SoftSPS eng.
In Version zwei sind wir einige dieser Punkte angegangen und haben das ganze nochmal gründlich überarbeitet, größtenteils wurden auch ältere Projekte noch portiert. Es wurden die Performance-Engpass-Verursacher gesucht und entfernt, der Aufbau etwas entwirrt und auch gewisse Dinge noch stärker standardisiert. Leider haben wir es dann aber auch gerade beim Thema Initialisierung und Abstraktion wieder übertrieben und kamen auch hier nach ein paar Sondermaschinen drauf: das geht noch besser.
Ein paar kleine Änderungen wurden dann noch eingearbeitet, sozusagen eine V2.1 und dies verwenden wir jetzt für alle neue Projekte innerhalb unserer Firma. Was sind nun solche Projekte: Im Wesentlichen Sondermaschinen für die interne Produktion. Dabei gehts um ganz kleine Maschinen mit 1-5 Achsen und ein paar hundert IO-Punkten bis rauf zu großen Maschinen 170 Achsen und ein paar Tausend IO-Punkten. Alles mit dem selben Framework und eben auch Aufbau.
Der Vorteil hier ist, durch den klar dokumentierten Aufbau kann man die Mitarbeiter sehr flexibel für Erweiterungen und Verbesserungen (extrem wichtig bei Sondermaschinen da dies meist Prototypen sind) einsetzen. Sie finden sich schnell zurecht und finden die jeweiligen Stellen wo programmiertechnisch angesetzt werden muss, falls es mal Probleme gibt oder man was neues braucht.
Was ich hier sagen will, die Objektorientierung ermöglicht und vereinfacht vieles (Wiederverwendung, Struktur und was nicht zu vernachlässigen ist die Akzeptanz unter den jüngeren Entwicklern/Bewerbern), aber man muss extrem aufpassen dass man sich nicht verhaspelt. Im wesentlichen arbeitet man mit einem hochverfügbaren System das Echtzeit beherrschen soll und da darf man gewisse Dinge einfach nicht tun. Das war schon unter der Linux Steuerung so und ist auch bei Codesys V3 Systemen so. Man darf und kann PLC-Programmierung nicht mit einer "normalen" IT Applikation vergleichen. Ich muss auch sagen, das wissen aus der "C-Welt", also wie das ganze auch dann im Speicher und auf der CPU abläuft, hilft hier natürlich auch stark.
Die Version 3 dieses Frameworks wird jetzt von einer externen Firma nochmals komplett neu entwickelt und die wirds bald inkl. der Libs Online als OpenSource System geben.
Zum Thema KI hab ich lachen müssen. Viele reden von KI und haben ein paar Whitepaper von Herstellern durchgelesen. Auch wir hatten solche Firmen da und haben auch einiges umsetzen können, richtig was gebracht hats nur in wenigen Fällen. Meiner Meinung nach fängt das Problem ja schon bei der Datenaufzeichnung, Haltung und Qualität an. Wie schnell wird aufgezeichnet, wie deterministisch, wie werden die Daten abgespeichert, wo werden sie abgespeichert und wie generisch sind sie gespeichert. Im Sondermaschinenbau natürlich möglich, aber ohne starke Standardisierung nur sehr schwer!
Insgesamt muss ich sagen sind wir doch sehr froh, dass wir komplett auf die Objektorientierung gesetzt haben, da wir dadurch die benötigte Komplexität der Maschinen und auch der Prozesse übersichtlicher und einfacher abbilden konnten. Die Wiederverwendbarkeit ist hiermit auch viel einfacher und besser möglich. Weiters haben einige jüngere Mitarbeiter das Feedback gegeben, dass klassische PLC-Programmierung mit AWL, FUP und KOP oder auch ohne moderne Paradigmen der OOP sie eher zum Jobwechsel gebracht hätten als zum Job halten. Die Learnings die wir mit OOP und dem Codesys System hatten möchte ich eh nochmal niederschreiben, vll teil ich das dann mal hier mit euch...
Sg
M.
- Beiträge
- 11.676
- Reaktionspunkte
- 3.913
@seehma
Vielen Dank für deine Erläuterungen
Ganz besonders zum Thema OOP.
Das deckt sich komplett mit meinen Ansichten.
OOP ist der richtige Weg in der Automatisierung.
Wir arbeiten schließlich mit realen Objekten und warum soll sich das dann nicht auch in der Software wiederspiegeln?
Über das Ziel hinausschießen ist dabei wirklich das Thema.
Ich hatte dazu mal ne nette Erfahrung mit nem jungen Kollegen.
Er hat versucht alles von einer Achse abzuleiten. Ein normaler Zylinder war auch eine Achse.
In der Theorie auch richtig, kann man in OOP machen. Diskussion war zwecklos.
Also hat er sein Programm so geschrieben ... Und ist an der Inbetriebnahme gescheitert.
Daraufhin einfach auf Ableitung und Vererbung verzichtet und Zylinder, Achsen getrennt betrachtet und alles war gut.
Vielen Dank für deine Erläuterungen
Ganz besonders zum Thema OOP.
Das deckt sich komplett mit meinen Ansichten.
OOP ist der richtige Weg in der Automatisierung.
Wir arbeiten schließlich mit realen Objekten und warum soll sich das dann nicht auch in der Software wiederspiegeln?
Über das Ziel hinausschießen ist dabei wirklich das Thema.
Ich hatte dazu mal ne nette Erfahrung mit nem jungen Kollegen.
Er hat versucht alles von einer Achse abzuleiten. Ein normaler Zylinder war auch eine Achse.
In der Theorie auch richtig, kann man in OOP machen. Diskussion war zwecklos.
Also hat er sein Programm so geschrieben ... Und ist an der Inbetriebnahme gescheitert.
Daraufhin einfach auf Ableitung und Vererbung verzichtet und Zylinder, Achsen getrennt betrachtet und alles war gut.
Hallo, mich würden die Erfahrungen der Instandhaltung bei der Fehlersuche interessieren. Sind die auch so positiv ?
gruß rlw
OP
- Beiträge
- 5.839
- Reaktionspunkte
- 1.243
-> Hier kostenlos registrieren
Da muss der Instandhalter sich halt fortbilden. Früher gab es Klappertechnik, bis es einer gewagt hatte da eine Steuerung statt der schönen Schütze einzusetzen. Was hat da der Instandhalter gemacht? Dann wurde die schöne S5 die lief und mit der man doch eigentlich alles machen konnte frecherweise durch eine S7 ersetzt. Was nun? Man muss halt offen für Neuerungen sein, aber natürlich diese nicht mit Gewalt einsetzen. Die Entwicklung geht weiter und wir alle müssen uns anpassen.
Das ist jetzt nicht gerade ein Erfahrungsbericht.
OP
- Beiträge
- 5.839
- Reaktionspunkte
- 1.243
Also ich habe schon für mehrere Kunden gearbeitet die einen gewissen OOP Ansatz (z.B. Ventil FBs vererbt) verfolgen und da kamen keine Klagen aus den entsprechenden Abteilungen.
- Beiträge
- 11.676
- Reaktionspunkte
- 3.913
-> Hier kostenlos registrieren
OOP vs Instandhaltung:
Hier ist es ganz klar abhängig von der Umsetzung durch den Programmierer.
Du kannst OOP so aufbauen, dass du z.B. einen nach aussenhin einen ganz normalen FB für Ventilansteuerung hast.
Vererbung / Erweiterung findet alles intern statt.
Du kannst aber auch OOP so aufbauen dass Methoden und Eigenschaften überall im Programm verstreut sind.
Wie eine Eigenschaft (z.B. "Station2.X-Achse.Bewegungsfrg") aufgebaut ist, wo sie herkommt, kann dann schwierig zu finden sein.
Die Vorteile bei OOP liegen momentan doch mehr bei der Programmerstellung als bei der Fehlersuche.
Hier ist es ganz klar abhängig von der Umsetzung durch den Programmierer.
Du kannst OOP so aufbauen, dass du z.B. einen nach aussenhin einen ganz normalen FB für Ventilansteuerung hast.
Vererbung / Erweiterung findet alles intern statt.
Du kannst aber auch OOP so aufbauen dass Methoden und Eigenschaften überall im Programm verstreut sind.
Wie eine Eigenschaft (z.B. "Station2.X-Achse.Bewegungsfrg") aufgebaut ist, wo sie herkommt, kann dann schwierig zu finden sein.
Die Vorteile bei OOP liegen momentan doch mehr bei der Programmerstellung als bei der Fehlersuche.
seehma
Level-1
- Beiträge
- 112
- Reaktionspunkte
- 31
Die klare Strukturierung hat hier nicht nur dem Steuerungstechniker-Team geholfen den Code gleich aufzubauen und zu programmieren sondern die hilft natürlich auch anderen. Folgende Vorgehensweise haben wir gewählt (keine Garantie auf Erfolg, bei uns hats geklappt):
Vielleicht komme ich ja mal in den Genuss die Idee bzw. den gewählten, künftigen Weg näher zu zeigen, gäbe es da Interesse? Das wäre natürlich auch von anderen interessant, falls noch jemand sich in diese Richtung bewegt hat...
- (Fast hätte ich es vergessen): Coding Guidelines -> wie markiere ich eine variable die statisch da liegt oder am Stack; Wie benamse ich ein Enum und eine Struktur. Das ganze haben wir noch ein paar mal nachschärfen müssen da manche Dinge von der IDE nicht so gut unterstützt waren, aber der Guide sollte dann halt auch quer über alle Abteilungen bekannt sein
- Nomenklatur für Maschinen und Standardisierung des Aufbaus: Es war uns wichtig das jeder das gleiche versteht wenn von einer Station, einer Achse, einem Aktuator oder einem IO gesprochen wird. Jeder muss auch wissen wie und wo sind die Schnittstellen definiert.
- Testbetriebe für standardisiertes Equipment: So gut wie alles, das in der Maschine einen Prozess verrichtet ist standardisiert und somit gibt es dafür auch Testbetriebe. Damit meine ich im wesentlichen elektroantriebe, aktuatoren (meist pneu oder hydr.), inputs, outputs, sensoren usw...
Die Testbetriebe werden bei uns großteils automatisiert erstellt, erzeugen somit keinen Mehraufwand. - Weniger Debuggen mit Haltepunkte mehr übersichtliches Logging: Wir sind von den Haltepunkten etwas weggekommen und verwenden sie nur mehr im äußersten Notfall (der Instandhalter gar nicht mehr). Viel wichtiger war es für uns ein hoch performantes, übersichtliches und standardisiertes Logging zu haben. Diese Logfiles lesen geben eigentlich über alles Aufschluss, erfordert aber auch etwas Übung; Achtung, da spreche ich nicht von Meldungen die am HMI angezeigt werden, die Logfiles die ich meine sind gut mal einige Megabyte große für ein paar Minuten Maschinenleistung. Die Vorteile liegen auf der Hand, aber wenn man aus der Welt der Haltepunkte kommt ist das nicht so eindeutig ersichtlich. Wir hatten sowas bei Linux/C nicht, da gabs auch nur das Logging und daher waren wir das auch so gewöhnt.
Vielleicht komme ich ja mal in den Genuss die Idee bzw. den gewählten, künftigen Weg näher zu zeigen, gäbe es da Interesse? Das wäre natürlich auch von anderen interessant, falls noch jemand sich in diese Richtung bewegt hat...
Zuletzt bearbeitet:
- Beiträge
- 22.240
- Reaktionspunkte
- 6.912
Na, Haltepunkte sind bei SPS zur Störungssuche eh' ein absolutes No-Go.
Instandhalter sind in der Regel nicht doof und können sich auch an die verschiedensten Programmiersysteme gewöhnen, wenn die sich bei der Arbeit einfach beobachten lassen. Instandhalter suchen meistens unter Zeitdruck, warum es in einem Prozess nicht weitergeht "Auf welches Signal wartet der Prozess?" oder "Welcher Sensor ist kaputt?" Wenn sich das nicht einfach beobachten lässt, dann ist die ganze tolle Software-Technologie für die Katz.
Ab welcher Version ungefähr wird es bei dem System Online Change im Run geben?
Harald
Instandhalter sind in der Regel nicht doof und können sich auch an die verschiedensten Programmiersysteme gewöhnen, wenn die sich bei der Arbeit einfach beobachten lassen. Instandhalter suchen meistens unter Zeitdruck, warum es in einem Prozess nicht weitergeht "Auf welches Signal wartet der Prozess?" oder "Welcher Sensor ist kaputt?" Wenn sich das nicht einfach beobachten lässt, dann ist die ganze tolle Software-Technologie für die Katz.
Ab welcher Version ungefähr wird es bei dem System Online Change im Run geben?
Harald
- Beiträge
- 11.676
- Reaktionspunkte
- 3.913
-> Hier kostenlos registrieren
Es gibt halt letztlich ganz verschiedene Arten Maschinen zu programmieren.
Kommt man aus der Embedded-Ecke, dann macht man es lhalt anders als wenn man von der klassischen Steuerungstechnik kommt.
Ich hab mal ein Fördertechnik-Programm ändern müssen. Etwa 20 Elemente (Rollenbahnen, Drehtische, Stopper, ...).
Es gab im gesamten Programm nur 32 Datenbits. Bezeichnet mit Binärregister 0 bis 31. Dazu 32 Datenworte bezeichnet als Wordregister 0 bis 31.
Dann gabs noch einen Stack. Die Anlage hat recht gut funktioniert.
Ich sollte nur eine Kleinigkeit ändern, habs aber in dem System nicht hinbekommen.
Der vorherige Programmierer hat vorher Mikrocontroller basierte Steuerungen programmiert und war nicht mehr greifbar.
Kommt man aus der Embedded-Ecke, dann macht man es lhalt anders als wenn man von der klassischen Steuerungstechnik kommt.
Ich hab mal ein Fördertechnik-Programm ändern müssen. Etwa 20 Elemente (Rollenbahnen, Drehtische, Stopper, ...).
Es gab im gesamten Programm nur 32 Datenbits. Bezeichnet mit Binärregister 0 bis 31. Dazu 32 Datenworte bezeichnet als Wordregister 0 bis 31.
Dann gabs noch einen Stack. Die Anlage hat recht gut funktioniert.
Ich sollte nur eine Kleinigkeit ändern, habs aber in dem System nicht hinbekommen.
Der vorherige Programmierer hat vorher Mikrocontroller basierte Steuerungen programmiert und war nicht mehr greifbar.
seehma
Level-1
- Beiträge
- 112
- Reaktionspunkte
- 31
So war es gar nicht gemeint, hab gemacht bzw. mach das selber ja auch noch teilweise. Software kann da aber schon sehr helfen wenn klar strukturiert, immer gleich und die Meldungen im Log/HMI aussagekräftig. Oft sind auch Testbetriebe sehr wichtig wo man gewisse Sensorfunktionen testen/aufzeichnen kann um eben überhaupt mal deren Funktion zu testen. Das Problem im Sondermaschinenbau ist ja eigentlich, man hat schon genug mit Prozess und der "Sondermaschine" zu tun und meist wenig Zeit für die Standardisierungs-Dinge und so Testbetriebe, deshalb werden die meist nicht umgesetzt.
Online Change im Run gibt es ja bei Twincat schon seit Beginn eigentlich. Das ganze lief mal besser mal schlechter, mittlerweile eigentlich sehr stabil. Früher hat er halt nicht erkannt, bzw. nicht gewarnt wenn sich beim Change im Speicher was tut nach dem OnlineChange, das wurde jetzt verbessert (bin mir nicht ganz sicher mit welcher Version).
Das stimmt natürlich. Da wir aus der C und Linux Welt kamen, waren unsere Ansprüche einfach: wir wollen auf jeden Fall OOP und deshalb auch gleich voll in die Richtung. Wir haben bei Linux mal so UML-Geschichten getestet und waren da sehr weit, das wurde dann aber auf Grund von Zeitdruck wieder verworfen.
Auf jeden Fall, falls man einen Systemwechsel macht, die Möglichkeiten von OOP mal anschauen und falls es gibt, auch mit Hilfe. Die gabs bei uns nicht und wir haben da halt ein paar Jahre ordentlich lernen müssen (viele Überstunden lang, aber ganz ehrlich, hat auch Spaß gemacht)
- Beiträge
- 9.836
- Reaktionspunkte
- 2.854
???
Wieviel Geld habt Ihr denn für V1 und V2 schon ausgegeben? Und wenn dass doch so gut war und toll funktioniert hat, warum wirds dann jetzt nochmal extern neu gemacht?
Hört sich für mich nach entwickeln um des Entwickelns Willen und Lizenz zum Geld verbrennen an. Oder nach Joberhaltung für die Entwickler.
Wenn eine Bibliotheksentwicklung so viel Geld kostet, wieviel Anlagen muss mann dann damit bauen, damit sich das rechnet?
-> Hier kostenlos registrieren
Die OOP in Codesys hat sehr viel Potential, insbesondere in Bibliotheken.
Es gibt leider noch Mankos:
Der Trend geht trotzdem klar zur OOP.
Ich wäre sehr interessiert an deinem Framework @seehma
Es gibt leider noch Mankos:
- Der Status in der Online-Ansicht von Properties / Methoden stoßen bei uns in der Firma aktuell auf großen Unmut. Die Pragmas sind zwar ganz nett, aber auch mit Vorsicht zu genießen. Zudem funktionieren diese nicht so toll bei der Verwendung von Interfaces
- Die Querverweise sind zum Teil gruselig bezgl. Nachverfolgen. Insbesondere bei der der Verwendung von Interfaces
- Ein Onlinechange ist nur noch bedingt möglich. Sobald ein Property / Methoden geändert wird oder in der Deklaration wird es schwierig. Mir hat man erklärt es wäre von Vorteil wenn der Body zyklisch aufgerufen wird, auch wenn dieser keinen Code enthält.
- Bei Verwendung von THIS^ Pointern kann die Variable nicht mehr wie gewohnt mit Rechtsklick zu einem Trace hinzugefügt werden
- Die Performance kann bei richtiger Verwendung gesteigert werden, aber die Lektüren was es aktuell dazu gibt ist sehr dürftig. Man muss eher in andere Programmiersprachen einarbeiten um ein besseres Verständnis zu bekommen
- Die Dokumente was es zu den von Codesys erstellten „OOP Bibliotheken“ gibt sind aus meiner Sicht ungenügend. Da hab ich die .NET Beschreibung besser verstanden, als ich mal was damit gemacht habe, obwohl das nicht meine Welt ist
Der Trend geht trotzdem klar zur OOP.
Ich wäre sehr interessiert an deinem Framework @seehma
seehma
Level-1
- Beiträge
- 112
- Reaktionspunkte
- 31
Du hast Recht, die erste Version war nicht gratis. Vor allem haben wir erstmal mit Twincat und der V3 richtig umgehen lernen müssen. Die genauen Kosten kann ich nicht sagen, aber es wurde auf jeden Fall mal ein Projekt für das ganze aufgesetzt. Man muss dazusagen, die Ideen für das Framework waren nicht neu, wir hatten das alles schon im Linux System und wussten wie vom Grundgerüst her das aufzubauen ist. Probleme gabs am Anfang eher mit der Systemstabilität (Bluescreens, Ethercat Probleme, Ausfälle der Echtzeit und somit der Antriebe, Bibliothekshandling ist auch komplett anders als in anderen Sprachen und Systemen, Abstürze der Umgebung, Links gingen ständig verloren usw...).
Die Folgeversionen wurden dann eigentlich immer im Zuge von neuen Großprojekten mit-(und weiter-)entwickelt. V2 klingt jetzt so, wie wenn es komplett über den Haufen geschmissen wurde, aber im wesentlichen wurde nur der Aufbau (wo liegen welche Objekte und wie wird drauf zugegriffen) geändert. Heißt mehr Verschiebe- und Dokumentationsarbeit als neu entwickeln. Also hier hat sich der Aufwand in Grenzen gehalten.
V2.1 war dann eigentlich nur noch eine Draufgabe um die Performance zu verbessern. Wir haben dann ein paar Maschinen gebaut die von der Zykluszeit her aufgrund Prozess auf 500us und 250us runter mussten, allerdings mit 10-18 Achsen (je nach Ausbaustufe) und da haben wir dann hier nochmal einiges verbessert.
Eigentlich war es immer ein kontinuierliches verbessern.
Ich hab nie gesagt dass es viel Geld war ;-). Die Rechnung ging bei uns dann ganz wo anders auf.
Beispiel: Wir haben eine sehr große Anlage, gemacht von 2 Entwicklern mit dem V2 System und wie der Teufel so will war einer mal Urlaub und der zweite im Krankenstand, zeitgleich. Es trat ein Fehler auf und es war eindeutig ein Softwarebug im Steuerungssystem. Durch den strukturierten Aufbau konnte halt ein dritter Entwickler, der die Maschine nie gesehen hat hingehen, sich das Problem erklären lassen und das Problem zügig beheben (1/2h). Zugegeben sagt jetzt nicht unbedingt viel aus, aber für uns intern war das dann irgendwie eine Bestätigung dass der Weg an sich schon passt. Gerade im Sondermaschinenbau passiert es halt oft dass sich mehrere unterschiedliche Systeme etablieren und die Entwickler nicht beliebig austauschbar sind.
V3 gibts einfach nur deswegen, weil wenn du mit so einem (intern entwickelten) System extern gehst dann muss die Codequalität, Testabdeckung und Dokumentation einfach viel durchgängiger und besser sein. Durch das ständige Weiterentwickeln haben sich halt so manche Unschönheiten eingeschlichen die man auf Grund von Zeitdruck intern nicht ausbessert. Das kannst du mit einem öffentlichen System aber so nicht machen. Leider hat Corona halt auch die Wirtschaftliche Situation nicht unbedingt verbessert und wir mussten auch Leute abbauen.
Möchte nochmal betonen, ich sag hier auf keinen Fall "das ist der einzig richtige Weg". Ich kann nur von meiner Erfahrung und Historie her sagen, für uns hat es sich insgesamt schon gelohnt und ich möchte das ganze nicht mehr missen. Im Endeffekt sind aber natürlich immer mehrere Punkte in so eine Bewertung mit reinzunehmen und man kann das nicht pauschal für eine Entwicklermannschaft oder Firma sagen ob passt oder nicht.
OP
- Beiträge
- 5.839
- Reaktionspunkte
- 1.243
Da werden Dir viele meiner Kunden aber widersprechen, wobei hier Störungssuche eine Definitionssache ist. Da ging es meist um die Fehlersuche während der Entwicklung oder Erweiterung einer Anlage.
- Beiträge
- 22.419
- Reaktionspunkte
- 7.464
-> Hier kostenlos registrieren
Also ich stimme Harald ( @PN/DP ) vollkommen zu. Bei unseren Anlagen wären Haltepunkte absolut sinnbefreit und auch gar nicht möglich.
( Palettierer, Kommissionieranlagen, Abfüllanlagen.... ).
Du kannst dir ja selbst mal überlegen, wenn ich bei einem Flaschenabfüller mit einer schnell rotierenden Masse von ca. 4 to
einen Breakpoint setze, was dann passiert. Dann bin ich nicht mehr mit dem ursprünglichen Problem beschäftigt sondern mit 50 anderen.
Es kommt wohl auf die Anlagenart an.
OP
- Beiträge
- 5.839
- Reaktionspunkte
- 1.243
Das hatte ich nicht extra erwähnt, aber klar kommt es auf den Anlagentyp an. Bei einer hochdynamischen Anlage kann man natürlich nicht einfach einen Breakpoint setzen um sich gewisse Dinge mal in Ruhe anzusehen. Können könnte man natürlich schon, aber mit was für Konsequenzen.
- Beiträge
- 16.599
- Reaktionspunkte
- 6.203
Das Haltepunkte im Maschinenbau Käse sind ist klar,
allerdings wie ich es bei seehma rauslese, wird er die auch
nicht benötigen.
