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

Seite 4 von 6 ErsteErste ... 23456 LetzteLetzte
Ergebnis 31 bis 40 von 55

Thema: Jobwechsel - Softwarestandard in neuer Firma

  1. #31
    Registriert seit
    29.03.2004
    Beiträge
    5.735
    Danke
    143
    Erhielt 1.685 Danke für 1.225 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Blockmove Beitrag anzeigen
    Ja, es wird daran gearbeitet. Das hab ich auch gehört. Aber zur Zeit hat wohl die Stabilisierung und Vervollständigung von TIA die höchste Prio.
    Ob es allerdings soviel Auswirkung auf die Programmierung haben wird, weiß ich nicht.
    Bei Siemens gibt es ein Projekt "Digitale Fabrik".Ein Teil davon ist Schaffung von Schnittstellen zwischen TIA und NX (3D-CAD).
    Hört sich in mancher Hinsicht interessant an (Simulation, Code-Generierung, Visualisierung ...). In wie weit aber die Objekte die dann in NX erstellt werden auch eine OO-Programmierung nach sich ziehen bleibt abzuwarten.
    Unschön an allem was Siemens momentan im TIA-Portal entwickelt ist, sich in allem bestimmte Entwicklungen wiederfinden:
    - Es werden keine offenen Schnittstellen verwendet
    - Bekannte Standards und Vorgehensweisen werden ignoriert, wenn diese nicht von Siemens selber entwickelt wurden (not invented here Syndrom). Es muss eine eigene Lösung her, auch wenn diese schlechter ist. Und da Codesys die OO schon etwas länger beackert und Erfahrungen hat, wird es von Siemens garantiert etwas komplett anderes geben.

    Aber back2topic:
    Bezüglich globalen Merkern habe ich wieder einen Schritt zurück hin zu den Merkern gemacht. Merker kommen bei mir hauptsächlich zum Einsatz um Befehle von Automatiken an Antriebsbausteine weiterzugeben. Ich wollte die Merker dann wegoptimieren, und mit den Befehlen komplett über die Schnittstelle gehen. Vom Prinzip her funktioniert das zwar, hat aber einige Nachteile.
    Man deklariert sich "einen Wolf", d.h. erst an der Schnittstelle vom Automatikbaustein heraus, dann in den Baustein der Antriebsbausteine wieder hinein, und dazwischen will man ja auch keiner Merker haben, d.h. in den Temp Variablen nochmal die Variablen anlegen, damit auch alles schön mit Symbol und auch nachvollziehbar ist.

    Nächster Nachteil: Ich bin in Freund der "Gehe zur Verwendungsstelle" Funktion. Wenn es in einem Programm ein Fehler gibt, gehe ich oft erst zum Antriebsbaustein, und prüfe über die Verwendungsstelle des Startbefehls woher der Startbefehl kommt. Mit Merkern ist das nur ein Schritt um zu der Stelle zu springen von der der Automatikstart kommt. Wenn man das über zig Schnittstellen nachvollziehen muss, war das im Nachhinein sehr nervig.
    Darum habe ich das Konzept verworfen und habe jetzt wieder Merker dafür verwendet. Ich habe auch schonmal direkt in den Instanz-DB des Antriebs geschrieben, was aber noch mehr Nachteile hat.

  2. #32
    Registriert seit
    15.01.2005
    Ort
    In der Mitte zwischen Bayreuth/Weiden
    Beiträge
    6.732
    Danke
    314
    Erhielt 1.520 Danke für 1.282 Beiträge

    Standard

    Zitat Zitat von Simotion84 Beitrag anzeigen
    Aus bestimmten sicheren Quellen weiß ich, dass OOP in Zukunft Einzug in das TIA Portal erhält. Siemens hat da zwar etwas verschlafen zur Konkurrenz aber es wird daran gearbeitet. Und wenn diese Funktionen integriert sind, dann wird sich der Aufbau und die Struktur eh komplett ändern (zumindest wenn man nach OOP programmiert)
    Ganz ehrlich bis TIA überhaupt mal einen derart zuverlässigen Stand erreicht hat wie z.B. Step7, sollte Siemens an sowas wie OOP noch nicht mal denken.
    Zumal das ja dann scheinbar auch wieder nur irgendwie dazugebastelt sein wird, da im jetzigen Stand noch nicht mal wie auch immer geartete zarte Ansätze erkennbar sind.
    Desweiteren sprechen wir da wohl wenn dann von Zeiträumen, die es für die Berücksichtigung in heutigen Standards quasi vollkommen uninteressant machen.
    Die nächste Problematik wird dann natürlich sein, das die Kollegen dann endgültig auf Block gehen, weil das dann nicht mal mehr in Ansätzen deren offensichtlicher Denkweise entspricht.

    Ob das ganze dann über Jahre bis Jahrzehnte betrachtet "wartbarer" oder einfacher wird möchte man dann sowieso noch dahingestellt lassen,
    dazu werden die meisten SPS-Projekte einfach mit viel zu schlechter Planung in viel zu kurzer Zeit durchgezogen, und letzten Endes von Teilfunktionen abgesehen auch viel zu individuell.
    Warum denn einfach, wenn man auch Siemens einsetzen kann!

    Wer die grundlegenden Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu bekommen, verdient weder Freiheit noch Sicherheit (B. Franklin).

  3. #33
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.222
    Danke
    533
    Erhielt 2.697 Danke für 1.949 Beiträge

    Standard

    Zitat Zitat von lilli Beitrag anzeigen
    Hallo Ralle,

    ich kritisiere weder das Alter von Programmen noch das Alter von Kollegen. Meine Kritik gilt einzig dem fehlen gewisser Strukturen. Und diese finde ich, kann man mit gewissen "modernen Mitteln"(*) besser erreichen, als mit Programmrelikten die aus der S5-Zeit aus Kompatibilitätsgründen nach S7 übernommen worden sind.

    Gegen welches der 9 aufgezählten Punkte kannst du ein vernünftiges Gegenargument liefern?

    Liebe Grüße
    Lilli

    *Diese "modernen Mittel" sind auch schon 20 Jahre alt!
    Darum geht es gar nicht, es geht nur um Sinn und Unsinn, ständig zu meinen alle, die schon graue Haare haben, sind ein wenig senil und dusselig und haben ihr halbes Leben lang nur Schwachsinn getrieben, keine Ahnung von Struktur und schon gar keine Ahnung vom Business. Sie halten oft an den Gewohnheiten fest, weil sie diese Gewohnheiten genau kennen und gut damit umgehen können. Ihre Programme laufen und die laufen oft 10 Mal besser als irgendwelches abgehobenes OOP-Informatikergestammel, genau weil es eher praxisorientiert ist. Solchen Kollegen kann man ja mal mit den vom TE wohlgemeinten Argumenten kommen, da hast du gleich verloren. Ich denke, das ein Prozess der Änderung nur langsam vorgenommen werden kann, sonst wird das nichts. Ich hab auch schon Firmen erlebt, die haben es probiert, 2 neue Leute, die haben eine neue Software aufgesetzt, alles toll, Multiinstanzen, UDT, tief verschachtelte Strukturen. Dauerte ganz schön lang, lief auch so lá lá, aber dann zogen die Kollegen weiter, die hatten keinen Bock mehr und fanden einen neuen Arbeitgeber, der mehr zahlte. Dann saß man da mit einem schicken Standard, 80% war ok, aber keiner wollte oder konnte so richtig damit. Und es gibt wirklich auch ältere Kollegen,denen fällt es durchaus auch schwer, noch einmal "von vorn" anzufangen.

    Deine Kritik ist überspitzt und es ist alles zusammengetragen, was man so an negativem in SPS-Programmen finden kann. Wenn ich suche, finde ich das bei mir im übrigen auch und wenn du glaubst, bei dir wäre alles toll, schick mir halt mal deine Wundersoftware.
    Geändert von Ralle (06.04.2015 um 00:23 Uhr)
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  4. #34
    Registriert seit
    15.01.2005
    Ort
    In der Mitte zwischen Bayreuth/Weiden
    Beiträge
    6.732
    Danke
    314
    Erhielt 1.520 Danke für 1.282 Beiträge

    Standard

    Zitat Zitat von lilli Beitrag anzeigen
    Andererseits braucht es auch keine zwei Tage, um grundsätzliche Strukturschwächen zu erkennen.
    Da wären:
    - nahezu keine Verwendung standardisierter Bausteine für wiederkehrende Funktionen
    Was sind denn wiederkehrend Funktionen in aller Pauschalität ... bei mir bleibt da außer wie auch immer gearteten "Treiberbausteinen" für Sensoren oder Aktoren meist nicht sehr viel übrig.

    - keine Verwendung von IEC- Timer (hat sich noch nicht überall rumgesprochen, dass es so was gibt)
    Macht aber auch nur in FB's mit Multiinstanzen wirklich sinn, wobei es das in Bezug auf Änderbarkeit im laufenden Betrieb die Sache definitiv nicht leichter macht

    - Sehr umfangreicher Einsatz von Merkern, verteilt über de ganzen Adressbereich
    Merker sind nüchtern betrachtet auch nur globale Variablen, was anderes gibt es bei Siemens effektiv ja eh nicht, auch nicht bei der Spezialität DB in den div. Variationen.

    - Vielfaches verteiltes Setzen und Rücksetzen diverser Signale
    Damit magst du wohl recht haben

    - Flankenmerker im Temp- Bereich
    Ist keine Struckturschwäche sondern einfach ein Fehler, steht so gesehen also nicht zur Diskussion.

    - keine logische durchgängige Namensgebung bei Variablen
    - fehlende Netzerwerküberschriften, Symbolnamen oder Kommentare
    Das wäre ja jetzt relativ leicht zu ändern ...

    - kein Bezug der E/As zum Schaltplan (z.B. andere Namensgebung)
    Gab es auch schon mal eine Diskussion zu ... kommt ein wenig drauf an würd ich sagen, sicherlich keine pauschale Sache ...

    - kompletter Verzicht auf UDT und Multiinstanzen
    Keine Ahnung warum das jetzt in aller Pauschalität ein Nachteil sein muss.
    Bei durchsichten von fremden Programmen ... deren Logik man nicht auf den ersten Blick erfasst ist das alles defintiv zunächst mal kein Vorteil.
    z.B. weil einem Querverweise in aller Regel nichts bringen, und auch weil da (leider) noch viel mehr Schweinereien möglich sind, die sicherlich auch jeder schon mal in der ein oder anderen Form gesehen hat.
    Anmerkungen im Text ...
    Warum denn einfach, wenn man auch Siemens einsetzen kann!

    Wer die grundlegenden Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu bekommen, verdient weder Freiheit noch Sicherheit (B. Franklin).

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

    Standard

    Zitat Zitat von lilli Beitrag anzeigen
    Also ich finde, ihr tut Simon ein bisschen Unrecht.

    Klar kann man in den ersten zwei Arbeitstagen nicht alles sichten und sich ein unfassendes Urteil bilden. In dieser Zeit gleich mit ausführlichen Verbesserungen rüberzukommen, ist auch kein guter Stiel.

    Andererseits braucht es auch keine zwei Tage, um grundsätzliche Strukturschwächen zu erkennen.
    Da wären:
    - nahezu keine Verwendung standardisierter Bausteine für wiederkehrende Funktionen
    - keine Verwendung von IEC- Timer (hat sich noch nicht überall rumgesprochen, dass es so was gibt)
    - Sehr umfangreicher Einsatz von Merkern, verteilt über de ganzen Adressbereich
    - Vielfaches verteiltes Setzen und Rücksetzen diverser Signale
    - Flankenmerker im Temp- Bereich
    - keine logische durchgängige Namensgebung bei Variablen
    - fehlende Netzerwerküberschriften, Symbolnamen oder Kommentare
    - kein Bezug der E/As zum Schaltplan (z.B. andere Namensgebung)
    - kompletter Verzicht auf UDT und Multiinstanzen

    Sollte das so sein und zudem noch alles auf S7-Klassik basieren, dann wäre es doch sinnvoll, beim Umstieg auf TIA gewisse alte Praktiken zu hinterfragen.


    Wenn ich manchmal Genossen sehe, die ihre Altlasten um biegen und brechen portieren wollen, könnte ich kotzen! In solchen Fällen, kann TIA nicht oft genug abstürzen...

    Liebe Grüße
    Lilli
    Also so leid es mir tut, ich kann deiner "Stellungsnahme" keinerlei sinnvolle Aussage erkennen.
    Alles was war ist schlecht?
    Die "alten" Programmierer können nichts und sind nicht lernfähig?
    OOP ist die Lösung? (Kann ich mein Problem zurück bekommen?)
    Die haben auch noch keine Maschine oder Anlage zum funktionieren gebracht.
    Gut dass es dich gibt.

    Ich denke du solltest einmal nachdenken.
    Dass sich die Technik weiterentwickelt ist gut und wichtig.
    Doch aus einer Maschine Win$ zu machen ist eben nicht sinnvoll und auch nicht möglich.
    Und wenn in einer Firma Standards bestehen, dann macht das Sinn, auch wenn es nicht sofort von dem Neuen erkannt wird.
    Was ist schlecht von den "Alten" zu lernen? Es macht keinen Sinn, das Ras neu zu erfinden, denn es läuft schon seit Jahrtausenden.
    Wenn jeder seinen Stuß, den er oder sie gerade im Kopf hat, wird es für eine Firma unbezahlbar.
    Der Kollege tut gut daran zuerst zu verstehen, warum was wie realisiert wird und dann über Neuerungen nachzudenken.
    Wenn er das nicht will, dann eben wechseln.
    Mir gehen die "revolutionärem" Neuerungen, die von Studis eingeführt werden die Hutschnur hoch.
    Was denkst du wie es möglich ist, dass wie bei uns ca 800 Techniker weltweit unsere Programme verstehen?

    Zu dem Bezug der E/A auf die Hardware noch ein Hinweis:
    Erkläre das den Kunden, die das wollen und auch dafür bezahlen.
    Aber wenn ihr kein Geld verdienen müsst, wir müssen.


    bike
    "Any fool can write code that a computer can understand.
    Good programmers write code that humans can understand."
    --Martin Fowler

  6. #36
    Registriert seit
    05.05.2012
    Beiträge
    96
    Danke
    44
    Erhielt 14 Danke für 14 Beiträge

    Standard

    Zitat Zitat von MSB Beitrag anzeigen
    Anmerkungen im Text ...
    @All: Ich bleibe mal bei der sachlichen Diskussion von MSB, dann wird das etwas weniger Polemisch...

    Andererseits braucht es auch keine zwei Tage, um grundsätzliche Strukturschwächen zu erkennen.
    Da wären:
    - nahezu keine Verwendung standardisierter Bausteine für wiederkehrende Funktionen
    Was sind denn wiederkehrend Funktionen in aller Pauschalität ... bei mir bleibt da außer wie auch immer gearteten "Treiberbausteinen" für Sensoren oder Aktoren meist nicht sehr viel übrig.
    - Füllstandsüberwachung die mit Analogwert und Grenzwerten versorgort wird und hinten die Warnungen und Störungen ausspukt
    - Laufzeitüberwachungen die universell einzelne Signale, oder auch gleich alle Rückmeldungen an Stellorganen wie pneumatischen/hydrauschen/motorischen Schieber auswertet
    - Treiberbausteine für Antriebe, die diese Laufzeitüberwachung bereits integriert haben...


    - keine Verwendung von IEC- Timer (hat sich noch nicht überall rumgesprochen, dass es so was gibt)
    Macht aber auch nur in FB's mit Multiinstanzen wirklich sinn, wobei es das in Bezug auf Änderbarkeit im laufenden Betrieb die Sache definitiv nicht leichter macht
    - Sehr wahrscheinlich wird das Programm in einem FB geschrieben sein. Wenn nicht, wäre es Zeit dies zu tun. Wenn man dann noch pauschal 10-20% Timer mehr deklariert als notwendig, ist man immer gut aufgestellt. Somit muss man den IDB bei den meisten Änderungen nicht mit übertragen. Für andere "Standardbausteine" gilt das selbe...

    - Sehr umfangreicher Einsatz von Merkern, verteilt über de ganzen Adressbereich
    Merker sind nüchtern betrachtet auch nur globale Variablen, was anderes gibt es bei Siemens effektiv ja eh nicht, auch nicht bei der Spezialität DB in den div. Variationen.
    - Da hast du recht. Warum sollte man die dann nicht gleich in einen Global-DB packen, damit der Merkerbereich für Inbetriebnahme oder Sonderanwendungen mit lockierten Adressen (z.B. Modbus) zur Verfügung steht?

    - Vielfaches verteiltes Setzen und Rücksetzen diverser Signale
    Damit magst du wohl recht haben

    - Flankenmerker im Temp- Bereich
    Ist keine Struckturschwäche sondern einfach ein Fehler, steht so gesehen also nicht zur Diskussion.

    - keine logische durchgängige Namensgebung bei Variablen
    - fehlende Netzerwerküberschriften, Symbolnamen oder Kommentare
    Das wäre ja jetzt relativ leicht zu ändern ...
    - Anscheinend nicht! Aber vernünftig...

    - kein Bezug der E/As zum Schaltplan (z.B. andere Namensgebung)
    Gab es auch schon mal eine Diskussion zu ... kommt ein wenig drauf an würd ich sagen, sicherlich keine pauschale Sache ...
    - kommt auch durch die Beschränkung auf 25 Zeichen die Siemens bisher im Symbol zugelassen hatte. Immerhin der Kommentar ist etwas länger.

    - kompletter Verzicht auf UDT und Multiinstanzen
    Keine Ahnung warum das jetzt in aller Pauschalität ein Nachteil sein muss.
    Bei durchsichten von fremden Programmen ... deren Logik man nicht auf den ersten Blick erfasst ist das alles defintiv zunächst mal kein Vorteil.
    z.B. weil einem Querverweise in aller Regel nichts bringen, und auch weil da (leider) noch viel mehr Schweinereien möglich sind, die sicherlich auch jeder schon mal in der ein oder anderen Form gesehen hat.

    IEC- Timer ohne Multiinstanzen? - Das wäre übel!
    Keine fertigen Strukturen für sich zig mal wiederholenden Variablen mit identischen Schnittstellensignalen? - Tippt Ihr so schnell und so Fehlerfrei, als dass Ihrs solch tolle Hilfsmittel nicht nötig hättet?
    Das verstehe wer will!



    Liebe Grüße
    Lilli

  7. Folgender Benutzer sagt Danke zu lilli für den nützlichen Beitrag:

    Matthias_VER (08.04.2015)

  8. #37
    Registriert seit
    16.10.2012
    Beiträge
    743
    Danke
    51
    Erhielt 36 Danke für 29 Beiträge

    Standard

    Zitat Zitat von lilli Beitrag anzeigen
    - Füllstandsüberwachung die mit Analogwert und Grenzwerten versorgort wird und hinten die Warnungen und Störungen ausspukt
    - Laufzeitüberwachungen die universell einzelne Signale, oder auch gleich alle Rückmeldungen an Stellorganen wie pneumatischen/hydrauschen/motorischen Schieber auswertet
    Also bei Stellventilen und Füllstandsüberwachung klingt mir das eigentlich immer weniger nach Fertigungsautomation und immer mehr nach Prozessautomation. Das muss man trennen, da gelten nämlich auch andere Standards. In der Prozessautomation werden alle Bausteine in SCL geschrieben, Verschaltung erfolgt im CFC / SFC und eigentlich benutzt man dafür auch die APL zusammen mit WinCC und PCS 7. Wenn man ganz crazy drauf ist, dann ersetzt man die APL durch eine eigens entwickelte Library, wenn man meint daß es damit besser geht. Einen aktuellen Bezug zu der momentanen Diskussion kann ich darin nicht erkennen, weil nach allem was bisher gesagt wurde, arbeitet der TS nicht in der Prozessbranche.

    Klar kann ich in einer Maschine auch ein Paar Proportionalventile und Füllstände haben, aber falls wir uns dabei nicht in der Prozesswelt befinden, werden daraus simple kleine Treiberbausteine, so wie MSB gesagt hat.

  9. #38
    Registriert seit
    15.01.2005
    Ort
    In der Mitte zwischen Bayreuth/Weiden
    Beiträge
    6.732
    Danke
    314
    Erhielt 1.520 Danke für 1.282 Beiträge

    Standard

    @Lilli
    Nicht das ich dir grundsätzlich widersprechen würde, meine Programme nutzen auch zahlreiche deiner gerühmten Struckturierungen,
    aber gerade deshalb sind mir auch die Nachteile dieser Arbeitsweise voll bewusst, und eben jene klammerst du in deinem pauschalierten Statement vollkommen aus.
    Und das ist pauschal genau so falsch wie richtig.
    Warum denn einfach, wenn man auch Siemens einsetzen kann!

    Wer die grundlegenden Freiheiten aufgibt, um vorübergehend ein wenig Sicherheit zu bekommen, verdient weder Freiheit noch Sicherheit (B. Franklin).

  10. #39
    Registriert seit
    13.10.2007
    Beiträge
    12.033
    Danke
    2.788
    Erhielt 3.269 Danke für 2.157 Beiträge

    Standard

    Ich finde es schön etwas komisch das hier Leute für jemanden einsetzen, den
    Sie nicht kennen, gegen einer Firma die sie nicht kennen, deren Arbeitsweise
    und Grund für diese. Der User hat erst zwei Tage die Firma von innen gesehen,
    stellt im Internet alles in Frage, anstatt mal die neuen Kollegen direkt zu fragen.

    So einen Mitarbeiter wünsche ich keinen Arbeitgeber.
    - - -
    Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

  11. #40
    Registriert seit
    03.07.2006
    Beiträge
    1.725
    Danke
    515
    Erhielt 303 Danke für 223 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Draco Malfoy Beitrag anzeigen
    Also bei Stellventilen und Füllstandsüberwachung klingt mir das eigentlich immer weniger nach Fertigungsautomation und immer mehr nach Prozessautomation. Das muss man trennen, da gelten nämlich auch andere Standards. In der Prozessautomation werden alle Bausteine in SCL geschrieben, Verschaltung erfolgt im CFC / SFC und eigentlich benutzt man dafür auch die APL zusammen mit WinCC und PCS 7. Wenn man ganz crazy drauf ist, dann ersetzt man die APL durch eine eigens entwickelte Library, wenn man meint daß es damit besser geht. Einen aktuellen Bezug zu der momentanen Diskussion kann ich darin nicht erkennen, weil nach allem was bisher gesagt wurde, arbeitet der TS nicht in der Prozessbranche.

    Klar kann ich in einer Maschine auch ein Paar Proportionalventile und Füllstände haben, aber falls wir uns dabei nicht in der Prozesswelt befinden, werden daraus simple kleine Treiberbausteine, so wie MSB gesagt hat.
    Soll man auf den Quatsch wirklich was antworten ??........ Liegt das an dem "Wenn man ganz crazy drauf ist" oder wo kommen diese intelligenten Lebensweisheiten her ??

Ähnliche Themen

  1. 3 Jobwechsel in 3 Jahren
    Von Krumnix im Forum Stammtisch
    Antworten: 15
    Letzter Beitrag: 07.08.2012, 18:46
  2. Neuer IBHNet Treiber inkl. neuer Firmware für den IBH Link S7++ verfügbar
    Von IBHsoftec GmbH im Forum Werbung und Produktneuheiten
    Antworten: 0
    Letzter Beitrag: 23.12.2011, 13:23
  3. Suche MES Firma
    Von mnuesser im Forum Sonstige Steuerungen
    Antworten: 0
    Letzter Beitrag: 06.10.2009, 15:20
  4. Welches Gehalt bei Jobwechsel mit Berufserfahrung?
    Von KingPin im Forum Stammtisch
    Antworten: 30
    Letzter Beitrag: 02.12.2007, 20:03

Lesezeichen

Berechtigungen

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