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

Seite 6 von 8 ErsteErste ... 45678 LetzteLetzte
Ergebnis 51 bis 60 von 74

Thema: Wünsche an Programmier- und Entwicklungstools

  1. #51
    Registriert seit
    01.10.2007
    Ort
    Waiblingen
    Beiträge
    3.317
    Danke
    767
    Erhielt 536 Danke für 419 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Martin Buchwitz Beitrag anzeigen
    Mich wundert es ein wenig, dass es wohl nur selten gelingt eine Software so zu gestalten, dass es verschiedene Zugangsebenen gibt - je nach Ansprüchen der User. Von einer Software mit einer derartigen Herangehensweise träume ich und ich bin überzeugt, dass es machbar sein muss.
    Ich bin neulich an Software verzweifelt, wo es Zugangslevel gab bis ich fand, dass es sie gibt. Nach drei Jahren Pause erinnerte ich mich dann irgendwann vage...

    Zum Thema wächst zum Moloch:

  2. #52
    Registriert seit
    09.08.2006
    Beiträge
    3.629
    Danke
    912
    Erhielt 656 Danke für 542 Beiträge

    Standard

    Zitat Zitat von Ralle Beitrag anzeigen
    sondern nur ein Beispiel geben, wie wichtig kleine Nebendinge werden und sein können.
    Jo, wenn die unausgereifte Software voreilig auf den Markt geworfen wird, bleiben teilweise viele kleine Nebendinge dauerhaft erhalten und summieren sich zum großen Frust auf.

    Beispiel von Siemens: der Baustein SEL_R

    Dieser Baustein schaltet abhängig vom Wert des Eingangs K den Wert des Eingangs IN0 (K = 1) oder des Eingangs IN1 (K = 0) auf den Ausgang.
    bei K=1 wird IN0 verwendet und bei K=0 IN1. Solche Dinge treiben einen zum Wahnsinn... Da fallen mir noch viel mehr ein, wo Dinge einfach invertiert intuitiv funktionieren

    Gruß.

  3. #53
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.726
    Danke
    398
    Erhielt 2.401 Danke für 2.001 Beiträge

    Standard

    Zitat Zitat von Martin Buchwitz Beitrag anzeigen
    Mich wundert es ein wenig, dass es wohl nur selten gelingt eine Software so zu gestalten, dass es verschiedene Zugangsebenen gibt - je nach Ansprüchen der User. Von einer Software mit einer derartigen Herangehensweise träume ich und ich bin überzeugt, dass es machbar sein muss. Man muss sich natürlich auch immer darüber im Klaren sein: Software wächst über die Jahre zu einem Moloch heran. Ist man bereit einen echten Schnitt zu machen, dann kommt ein Sturm der Entrüstung, da man seine Funktionen nicht mehr dort findet wo sie bisher waren, auch wenn es noch so komplex war.
    Ich glaube nicht, dass das wirklich möglich ist - ich kann es mir jedenfalls nicht wirklich vorstellen ... (denn dafür sind die Ansprüche zu unterschiedlich)

    Wenn man aber dann irgendwann einmal so einen "Moloch" hat dann sollte man sich darüber im Klaren sein (und das ist m.E. das Problem der Benutzer) das die Dinge von Version zu Version der gleichen Namen behalten sollten und idealerweise im Menue-Baum ansatzweise gleich plaziert bleiben sollten.

    Gruß
    Larry

  4. #54
    Registriert seit
    30.08.2005
    Beiträge
    280
    Danke
    41
    Erhielt 96 Danke für 66 Beiträge

    Standard

    Zitat Zitat von Martin Buchwitz Beitrag anzeigen
    Mich wundert es ein wenig, dass es wohl nur selten gelingt eine Software so zu gestalten, dass es verschiedene Zugangsebenen gibt - je nach Ansprüchen der User. Von einer Software mit einer derartigen Herangehensweise träume ich und ich bin überzeugt, dass es machbar sein muss. Man muss sich natürlich auch immer darüber im Klaren sein: Software wächst über die Jahre zu einem Moloch heran. Ist man bereit einen echten Schnitt zu machen, dann kommt ein Sturm der Entrüstung, da man seine Funktionen nicht mehr dort findet wo sie bisher waren, auch wenn es noch so komplex war.
    Wir versuchen das durchaus: standardmässig hat CODESYS ein vereinfachtes Bibliothekshandling, eine vereinfachte Gerätekonfiguration, einen reduzierten Sprachumfang, einige Objekttypen
    fehlen, etc. Den Einstieg macht es sicher einfacher, ob man dauerhaft mit diesen Einstellungen arbeitet, weiss ich nicht.
    Man kann sich da viel vorstellen: der einzelne Programmierer hat seine Vorstellungen, sein Arbeitgeber hat Vorstellungen, der OEM hat seine Vorstellungen,
    wir haben unsere Vorstellungen, es gibt branchenbezogene Unterschiede:
    Prozessindustrie, Maschinenbau, Fahrzeuge, Gebäudeautomation etc. haben unterschiedliche Anforderungen.
    Das gibt eine n-dimensionale Matrix von möglichen Konfektionierungen für die (im Grunde) immer gleiche Software. Wenn man das übertreibt, dann ist das Ergebnis ein Alptraum,
    für die Entwickler, für den Support, für den Test und auch für den Kunden.
    Man muss auch hier wieder einen Mittelweg finden zwischen Konfektionierungen und Standardisierung. Ich persönlich bin eher dafür einen guten Standard zu setzen.
    Bernhard Werner
    3S-Smart Software Solutions (CODESYS)

  5. Folgender Benutzer sagt Danke zu Werner29 für den nützlichen Beitrag:

    00alex (02.07.2013)

  6. #55
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.726
    Danke
    398
    Erhielt 2.401 Danke für 2.001 Beiträge

    Standard

    Zitat Zitat von Werner29 Beitrag anzeigen
    Ich persönlich bin eher dafür einen guten Standard zu setzen.
    Das sollte eigentlich für jeden die Prämisse sein -

  7. #56
    Registriert seit
    15.11.2012
    Beiträge
    41
    Danke
    3
    Erhielt 8 Danke für 8 Beiträge

    Böse

    In der Hoffnung, dass Werner29 hier noch mitliest:

    In irgendeiner CoDeSys-Version wurde eingeführt, dass bei Nutzung des SmartCodings (Auto-Vervollständigung/"IntelliSense") der Bibliotheks-Namespace automatisch hinzugefügt wird, wenn es sich um ein Element aus einer Bibliothek handelt.

    Ich bin davon ausgegangen, dass das ein Bug ist. Nun musste ich vom 3S-Support erfahren, dass dies ein Feature ist.

    Ich hätte dafür gerne eine Erklärung. Ich vermute, dass diese Anforderung von einem Bibliotheksentwickler kommt, denn nur dort macht der intensive Einsatz von Namespaces Sinn. Die Mehrheit der Anwender dürften aber Maschinenprogrammierer sein. Als Maschinenprogrammierer muss ich dafür sorgen, dass die Maschine funktioniert und dass man das Programm einigermaßen verstehen und lesen kann.

    Wenn man sich diese beiden Code-Ausschnitte anschaut, erkennt man das Problem des Maschinenprogrammierers.
    Diese Farbe = GVL
    Diese Farbe = FB-Instanz
    Diese Farbe = Enum
    Diese Farbe = Struktur-Instanz
    Diese Farbe = Lib-Namespace

    Ohne SmartCoding nach Einführung des Features bzw. mit SmartCoding vor Einführung des neuen Features:
    Code:
    IF (Cylinder1.Handling.Position = CylinderPosition.BOTTOM)
    THEN
      Cylinder1.Handling.PositionRequest := CylinderPosition.TOP;
      Cylinder1.Handling.Timeout := Cylinder1.Timeout.Auto;
      Cylinder1.Handling.Start := TRUE;
    END_IF
    
    IF (Cylinder1.Handling.State = HandlingState.ACTIVE) OR
       (Cylinder2.Handling.State = HandlingState.ACTIVE) OR
       (Cylinder3.Handling.State = HandlingState.ACTIVE)
    THEN
      Cylinder1.HMI.Update();
      Cylinder2.HMI.Update();
      Cylinder3.HMI.Update();
    END_IF
    Dasselbe nun mit SmartCoding nach Einführung des neuen Features:
    Code:
    IF (Cylinder1.Handling.Position = AC_PneumaticCylinders.CylinderPosition.BOTTOM)
    THEN
      Cylinder1.Handling.PositionRequest := AC_PneumaticCylinders.CylinderPosition.TOP;
      Cylinder1.Handling.Timeout := Cylinder1.Timeout.Auto;
      Cylinder1.Handling.Start := TRUE;
    END_IF
    
    IF (Cylinder1.Handling.State = AC_BaseSystem.HandlingState.ACTIVE) OR
       (Cylinder2.Handling.State = AC_BaseSystem.HandlingState.ACTIVE) OR
       (Cylinder3.Handling.State = AC_BaseSystem.HandlingState.ACTIVE)
    THEN
      Cylinder1.HMI.Update();
      Cylinder2.HMI.Update();
      Cylinder3.HMI.Update();
    END_IF
    Wie man sehen kann, nutze ich bereits die GVL- und Enum-Namen als "Mini"-Namespace. Das hat durchaus Vorteile, weil ich dann z.B. die Enum-Werte selbst einigermaßen kurz halten kann bzw. logisch strukturierte Namen habe.
    Bei den Bibliotheks-Namespaces gibt es offizielle Präfixe von 3S, damit es keine firmenübergreifende Konflikte gibt. Oben habe ich einfach mal das Präfix "AC_" gewählt.

    Nun arbeiten an meinem Projekt mehrere Programmierer. Die einen nutzen das SmartCoding, wodurch deren Code mit lauter Bibliotheks-Namespaces ergänzt wird. Die anderen Programmierer nutzen das SmartCoding nicht und haben den kürzen, übersichtlichen Code.
    Ich nutze das SmartCoding nur teilweise - nämlich nach dem Tippen eines Punktes. Das passt super zu meinen "Mini"-Namespaces. Wenn ich bei den Enums aber keinen Bibliotheks-Namespace davor schreibe, dann bekomme ich nicht einmal mehr die Enum-Werte nach Tippen des Punktes vorgeschlagen

    Dem Compiler ist es egal, wie man es schreibt - solange alles eindeutig ist. Ich habe ein recht großes Projekt (25 Bibliotheken, über 3000 Elemente) und keinen einzigen Namenskonflikt, wenn ich den Bibliotheks-Namespace weglasse. Deshalb machen die Bibliothek-Namespaces in meinem Programm einfach keinen Sinn.

    Klar, wenn ein Bibliotheksersteller seine Bibliothek mit dem Attribut "qualified only" versieht, dann muss man den Bibliotheks-Namespace dazuschreiben. Und wenn sich ein Programmierer die Mühe macht, immer zuerst den Namespace einzutippen, dann soll er das auch können. Aber den Namespace allein den Anwendern von SmartCoding aufzuzwingen, halte ich für falsch.

    Zum Glück erfindet 3S nicht alles neu, sondern schaut sich bei C# Features ab.
    Auch im Bereich SmartCoding hätte 3S lieber bei C#/.NET nachschauen sollen. Dort wird nämlich der Namespace auch nicht automatisch ergänzt und im IntelliSense erscheinen nur Elemente, die im aktuellen Namespace verfügbar sind. Wenn ein Element einen anderen Namespace benötigt, dann muss ich erst den Namespace eintippen, bevor ich im IntelliSense dessen Elemente sehe. Und wenn es mehrere gleichnamige Elemente im aktuellen Namespace gibt, dann erscheint im IntelliSense ein rotes Ausrufezeichen und beim Übersetzen ein Fehler, dass das Element nicht eindeutig ist und man ggf. den Namespace davor schreiben muss. Das ist bei CoDeSys korrekterweise auch der Fall - nur das SmartCoding geht in eine andere Richtung.

    So viel Text wie ich hier geschrieben habe, so sehr stört mich dieses Feature von 3S!
    Geändert von Interface (20.09.2013 um 10:02 Uhr)
    Zitieren Zitieren Codesys Smart Coding fügt Namespace automatisch ein  

  8. Folgender Benutzer sagt Danke zu Interface für den nützlichen Beitrag:

    IBFS (19.09.2013)

  9. #57
    Registriert seit
    30.08.2005
    Beiträge
    280
    Danke
    41
    Erhielt 96 Danke für 66 Beiträge

    Standard

    Hallo,

    Zunächst: in der nächsten Version wird es wieder so sein wie früher.
    Tatsächlich war das mal ein Kundenwunsch, den wir ein bisschen zu willfährig umgesetzt haben.
    Es haben sich dann einige Leute beschwert und jetzt bauen wir das wieder zurück (Version 3.5 SP 4), und man kann sich das per Option
    wieder einschalten.

    Das Problem ist natürlich: ein Bezeichner kann zum einen uneindeutig sein, z.B: wenn dieselbe POU in mehreren Libs vorkommt.
    Oder derselbe Typ "ERROR". Das ist weniger schlimm, weil der Compiler das anmeckert.
    Aber ein Bezeichner kann auch einen anderen Bezeichner verschatten, z.B: wenn im Projekt ein Typ ERROR existiert,
    dann verschattet der alle ERROR-Typen in den Bibliotheken.
    Es kann dann entweder zu seltsamen Fehlermeldungen kommen, oder schlimmer, zu unerwartetem Verhalten.
    Und noch schlimmer: das kann natürlich erst im nachhinein passieren: durch definieren eines lokalen Typs CylinderPosition,
    verwendet der obige Code auf einmal einen anderen Typ und man bekommt es nicht mit.

    Daher ist es erstmal sicherer, alles immer vollqualifiziert zu schreiben.

    Ich kann es jetzt nicht mehr rekonstruieren, vermutlich war es so: es gab in einem Projekt einen Fehler, weil jemand unqualifiziert
    danebengegriffen hat. Dann beschwert sich jemand: wenn euer Intellisense das so anbietet, dann darf das doch keinen Fehler produzieren.
    Dann machen wir die Funktion halt "sicher". Damit macht man ja scheinbar nichts falsch.

    Bernhard
    Bernhard Werner
    3S-Smart Software Solutions (CODESYS)

  10. Folgender Benutzer sagt Danke zu Werner29 für den nützlichen Beitrag:

    Interface (20.09.2013)

  11. #58
    Registriert seit
    15.11.2012
    Beiträge
    41
    Danke
    3
    Erhielt 8 Danke für 8 Beiträge

    Standard

    Zitat Zitat von Werner29 Beitrag anzeigen
    Ich kann es jetzt nicht mehr rekonstruieren, vermutlich war es so: es gab in einem Projekt einen Fehler, weil jemand unqualifiziert
    danebengegriffen hat. Dann beschwert sich jemand: wenn euer Intellisense das so anbietet, dann darf das doch keinen Fehler produzieren.
    Dann machen wir die Funktion halt "sicher". Damit macht man ja scheinbar nichts falsch.
    Vielen Dank für die Erklärung, mit der ich dieses Feature besser nachvollziehen kann und es nicht mehr als Bug ansehe.

    Prinzipiell ist es das gleiche Problem mit lokalen und globalen Variablen. Ich kann in einem FB eine lokale Variable deklarieren, die genauso heißt wie eine globale. Deshalb schreibe ich immer die GVL davor. Insofern ist es tatsächlich richtig, wenn der Lib-Namespace auch dazugeschrieben wird.

    Das eigentliche Problem ist, dass es in der SPS keine using-Direktive gibt. In C# ist der Namespace auch Pflicht, es sei denn man nutzt die using-Direktive. Da man in der SPS den Namespace von Libs nicht angeben muss, kann man das so interpretieren, dass von allen eingebundenen Bibliotheken automatisch die Direktive "using [Lib-Namespace]" zur Applikation hinzugefügt wird (man sieht es nur nirgends). Wenn man sich an C# orientiert, bedeutet das wiederum, dass man bei einem Typ (Enum, Struktur, POU), den es sowohl in der Applikation als auch in einer eingebundenen Bibliothek gibt, immer den Namespace (einer Bibliothek oder der Applikation) davor schreiben muss - ansonsten muss der Compiler einen Fehler melden. Dadurch entsteht der von Werner29 beschriebene Fehler weder bei SmartCoding-Nutzern, noch bei den reinen Tippern ohne SmartCoding (die vom aktuellen Feature der Namespace-Ergänzung gar nichts mitbekommen haben). Im IntelliSense erscheint der Typ idealerweise dann auch als Vorwarnung mit einem roten Ausrufezeichen (denn es gibt diesen Typ in zwei Namespaces: Bibliothek und Applikation, oder 2x Bibliothek).

    Das heißt, es fehlt in CoDeSys eigentlich ein Namespace für die Applikation, oder nicht?

    Falls sich das nicht realisieren lässt, ist die deaktivierbare Namespace-Ergänzung akzeptabel. Wie in den Beiträgen zuvor aber schon angemerkt wurde, bedeutet jede Option eine Komplexität mehr. Diese Option sollte außerdem projektspezifisch sein und nicht PC-spezifisch. Ansonsten könnte sich ein Programm auf unterschiedlichen Entwicklungsrechnern anders verhalten.
    Geändert von Interface (20.09.2013 um 10:26 Uhr)

  12. #59
    Registriert seit
    30.08.2005
    Beiträge
    280
    Danke
    41
    Erhielt 96 Danke für 66 Beiträge

    Standard

    Zitat Zitat von Interface Beitrag anzeigen
    Das eigentliche Problem ist, dass es in der SPS keine using-Direktive gibt.
    Nein die gibt es nicht. Könnte man natürlich machen. Im Moment ist es so, dass eine Lib selbst festlegen kann, ob man auf ihren Inhalt nur
    qualifiziert zugreifen darf und viele Bibliotheken machen das so.
    Das ganze ist halt auch gewachsen. Ursprünglich gab es keine Namespaces, dann liessen sich aber Zweideutigkeiten gar nicht auflösen.
    Zitat Zitat von Interface Beitrag anzeigen
    Das heißt, es fehlt in CoDeSys eigentlich ein Namespace für die Applikation, oder nicht?
    Natürlich definiert die Applikation implizit auch einen Namensraum, man kann diesem Namensraum halt keinen Namen geben.
    Zweideutige Namen werden wie gesagt vom Compiler angemeckert. Verschattungen sind allerdings für den Compiler OK
    wenn auch manchmal für den Programmierer unerwartet.
    Das ist nicht viel anders wie in C#. Wenn man in C# einen Namensraum mit #using importiert, dann kann es durch Verschattung
    auch Probleme geben.
    Zitat Zitat von Interface Beitrag anzeigen
    Falls sich das nicht realisieren lässt, ist die deaktivierbare Namespace-Ergänzung akzeptabel. Wie in den Beiträgen zuvor aber schon angemerkt wurde, bedeutet jede Option eine Komplexität mehr. Diese Option sollte außerdem projektspezifisch sein und nicht PC-spezifisch. Ansonsten könnte sich ein Programm auf unterschiedlichen Entwicklungsrechnern anders verhalten.
    Das ist keine Option an den Compiler, sondern nur für das Intellisense. Und dafür gibt es ohnehin schon mehrere Optionen, jetzt gibt es halt eine mehr.
    Und da sich das an die Bedienung richtet ist es eine Arbeitsplatzoption. Das Programm verhält sich anschliessend überall gleich.
    Bernhard Werner
    3S-Smart Software Solutions (CODESYS)

  13. #60
    Registriert seit
    15.11.2012
    Beiträge
    41
    Danke
    3
    Erhielt 8 Danke für 8 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Werner29 Beitrag anzeigen
    Das ist nicht viel anders wie in C#. Wenn man in C# einen Namensraum mit #using importiert, dann kann es durch Verschattung
    auch Probleme geben.
    Stimmt. Codesys ist an dieser Stelle genauso gut wie C#/.NET. Die Verschattung betrifft auch nur den Applikationscode und keinen Code in Bibliotheken.
    Sobald man den applikationsspezifischen Typ (z.B. ein Enum) mit dem Bibliotheks-Typ in einer Zuweisung mischt, meldet der Compiler einen Fehler. Die Meldung "Cannot convert type 'HANDLINGSTATE' to type 'HANDLINGSTATE'" ist vielleicht nicht ganz selbsterklärend, aber man kann nichts falsch machen (ok, mit Pointer geht alles, aber da ist man selbst Schuld).

Ähnliche Themen

  1. AEG Modicon Programmier- und Testeinrichtung Version 5.0
    Von Voerdal4126 im Forum Sonstige Steuerungen
    Antworten: 0
    Letzter Beitrag: 04.10.2012, 10:30
  2. Antworten: 3
    Letzter Beitrag: 30.03.2012, 15:50
  3. SPS Forum - Eure Ideen, Wünsche und Anregungen
    Von Matze001 im Forum Stammtisch
    Antworten: 126
    Letzter Beitrag: 20.03.2011, 18:28
  4. Wünsche und nie zufrieden
    Von Approx im Forum HMI
    Antworten: 2
    Letzter Beitrag: 27.02.2008, 17:38
  5. Programmier Arbeiten
    Von Balou im Forum Stammtisch
    Antworten: 4
    Letzter Beitrag: 26.06.2004, 01:16

Stichworte

Lesezeichen

Berechtigungen

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