Herstellerneutrale Programmierung von Steuerungen

Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn der TIA-Programmierer solchen Schwachsinn wie Leerzeichen in Variablennamen macht :roll: dann wird der Name zusätzlich zum # auch noch in doppelte " gesetzt, z.B. #"meine lokale Variable"
Harald

Wer macht schon Leerzeichen in Variablennamen?

Das wird doch beigebracht wie man ordentlich Variablen benennt. Oder nicht?
(Upper- und Lower-) CamelCase oder Trennzeichen getrennte Variablennamen? Aussagekräftige Variablennamen (also nicht "a" und "b" sondern "Sollwert" und "Istwert")? Und speziell in der SPS-Welt das voransetzen des Kürzels des Datentyps, also "xLichtWohnzimmer1" zum Beispiel?
 
Wer macht schon Leerzeichen in Variablennamen?
Ähmm... Was möglich ist, wird auch irgendwer machen. Ob es sinnvoll ist, ist da eher eine untergeordnete Frage

Das wird doch beigebracht wie man ordentlich Variablen benennt. Oder nicht?
Geh mal nicht davon aus, daß jeder auch eine formale Programmierausbildung hat.
Und speziell in der SPS-Welt das voransetzen des Kürzels des Datentyps, also "xLichtWohnzimmer1" zum Beispiel?
das ist eine unheimlich dämliche Regel...
 
Ähmm... Was möglich ist, wird auch irgendwer machen. Ob es sinnvoll ist, ist da eher eine untergeordnete Frage


Geh mal nicht davon aus, daß jeder auch eine formale Programmierausbildung hat.
das ist eine unheimlich dämliche Regel...

Speziell "das ist eine unheimlich dämliche Regel" unterschreibe ich so auch nicht. Früher hat die Entwicklungsumgebung und auch der Compiler diese Typsicherheit nicht hergegeben. Das heißt früher musste man sowas machen, damit man Fehler vermeidet. Ich erinnere mich da an Zeiten, wo man zum Übersetzen eines Programms mal gut 1 1/2h warten musste. Da ist man froh wenn man mit einem boDummy ein Bool schon vornherein erkannt hat.

Heute markiert die Entwicklungsumgebung ja schon während dem Programmieren das hier was falsch läuft, ergo kann man die ersten paar Zeichen des Variablennamens für sinnvollere Konventionen nutzen.

Sg
 
Denkt ihr bitte "ein bißchen" daran, worum es in diesem Thema eigentlich geht ...?
Die Diskussion "wie benenne ich Variablen richtig und warum" hat hier nicht wirklich etwas zu suchen ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn der TIA-Programmierer solchen Schwachsinn wie Leerzeichen in Variablennamen macht :roll: dann wird der Name zusätzlich zum # auch noch in doppelte " gesetzt, z.B. #"meine lokale Variable"


Eine Auswahl weiterer Unterschiede:
- Schreibweise der Slice-Zugriffe ist unterschiedlich
- im Codesys- und Twincat-Universum gibt es bei Functions kein VAR_TEMP, was bei Siemens SCL aber viel genutzt wird. Dafür gibt es in Codesys/Twincat VAR_...-Deklarationen, die es bei Siemens so nicht gibt
- Siemens SCL kennt kein "AT %I*" und "AT %Q*"
- Codesys/Twincat kann mit "AT" nicht Variablen übereinanderlegen so wie Siemens SCL - Codesys/Twincat hat dafür "UNION", was Siemens SCL aber nicht versteht
- direkte Adressierung von Eingängen/Ausgängen/Merkern (z.b. %MW2) funktioniert in Codesys/Twincat/Siemens unterschiedlich
- in Siemens SCL gibt es keine Adressoperatoren und kein SIZEOF, kein INDEXOF, kein UNION, kein Pointer, kein REFERENCE, kein AND_THEN, kein OR_ELSE, kein MEMCPY, ...
- HMI/Visu/Komm.-Zugriffe auf Variablen finden zu unterschiedlichen Zeitpunkten statt
- Parameterübergaben an Functions oder FB sind teilweise unterschiedlich "per Value" und "per Reference", und das bei Siemens sogar zwischen den S7-Familien oder gar innerhalb einer Familie (z.B. S7-1500) je nachdem ob der angeschaltete Aktualparameter in "optimiertem" oder Standard-Speicher liegt
- in Twincat können VAR_IN_OUT-Variablen nicht direkt via <FBInstanz>.<EinAusgabevariable> von außen gelesen oder geschrieben werden
- Twincat: Bei Operationen mit Gleitkomma-Datentypen ist das Rechenergebnis abhängig von der verwendeten Zielsystem-Hardware.
- der BOOL-Datentyp belegt bei Codesys/Twincat ein Byte, bei Siemens nur ein Bit
- ...

- Vorsicht bei (impliziten und expliziten) Typkonvertierungen, besonders bei Bitstring-Datentypen zu REAL! Da kocht jeder Hersteller sein eigenes Süppchen. Da kann man Berechnungen programmieren, die auf einer anderen Plattform ein anderes Ergebnis haben oder gar nicht fehlerfrei übersetzbar sind.


Meine Einschätzung: nur wirklich einfache Programmierung ist relativ kompatibel und automatisch konvertierbar - doch solche "Snippets" konvertiert kaum jemand. Kompliziertere Programme sind nur mit höherem Aufwand und manueller Nacharbeit und Nachkontrolle konvertierbar - da hilft ein automatischer Konvertierer nicht wirklich.

Harald


Hey Harald,

erst mal danke, dass du mir weitere Unterschiede aufzeigen konntest.

Ihr habt doch bestimmt schon mal von PLCopen gehört? Die beschäftigen sich doch eigentlich genau mit dem Thema "Herstellerneutrale Programmierung"? Hierbei führen Sie Standards auf, um bestmöglich ein Projekt (eine Application) zu exportieren bzw. zu Importieren? oder irre ich mich?

mit besten Grüßen
Ekki
 
Zurück
Oben