# Variablenbezeichnung



## HSThomas (14 Januar 2010)

Moin moin,



hier in der Firma kam es neulich zur Diskussion, wie man am besten die Variablen benennen könnte und sollte.
Auf der einen Seite stand mein Kollege, der Variablen mit kryptischen Bezeichnungen (Highlight: der Timer mit der Bezeichnung "krspf") bevorzugt. Ihm würde ein multidimensionales array und eine gut gepflegte Excel-Datei reichen.
Auf der anderen Seite ich, der den Variablen gerne solche Namen gibt, dass man schnell erkennen kann, wozu sie da sind (Highlight: Prozesswerte.Input.Analog.Durchfluss.Sauerstoff_Ist_unscaled).

Im Moment sieht es so aus, dass meine Anlagen meine Bezeichnungen beinhalten, und seine halt seine Bezeichnungen.

Wie macht ihr das denn so?

Gibt es vielleicht irgendwo eine mehr oder wenige freiwillige "Richtlinie", in der steht, wie man es machen könnte oder sollte? So eine Art... Empfehlung für SPS-Programmierer?




Gruß

Hauke


----------



## Perfektionist (14 Januar 2010)

wenn Du bei Google mal die Begriffe "sprechende Bezeichner" oder "sprechende Variablennamen" eingibst, so wirst Du sicherlich einiges finden, was Dir Deinen Standpunkt bestätigen wird.


----------



## rostiger Nagel (14 Januar 2010)

meine Bezeichnungen sehen wie dein zweites Highlight aus


> Prozesswerte.Input.Analog.Durchfluss.Sauerstoff_Ist_unscaled


 
Wobei ich versuche es schon kurz zu halten.
Aber es ist schon sehr hilfreich zu sehen was die Variable
für ein sinn hat, wenn ich es kryptisch möchte mach ich es so.


> MD 100
> DB100.DBD100
> EW 100


----------



## vierlagig (14 Januar 2010)

diesen beitrag finde ich für die diskusion sehr wertvoll:
http://www.sps-forum.de/showpost.php?p=132527&postcount=7

in diesem thread findest du ein paar anregungen für globale symbolik:
http://www.sps-forum.de/showthread.php?t=19419

[edit]eigentlich meinte ich diesen hier: http://sps-forum.de/showthread.php?t=24797  [/edit]


----------



## Perfektionist (14 Januar 2010)

fällt mir übrigens erst heute auf, dass sich bei den Tastaturen unseres werten Kollegen 4L die Umschalttasten nur sehr schwer niederdrücken lassen ...


----------



## OHGN (14 Januar 2010)

Perfektionist schrieb:


> fällt mir übrigens erst heute auf, dass sich bei den Tastaturen unseres werten Kollegen 4L die Umschalttasten nur sehr schwer niederdrücken lassen ...


Die Shifttaste sollte grundsätzlich nur noch für die Sonderzeichen genutzt werden. Groß- Kleinschreibung ist definitiv Uncool und verlangsamt das Verfassen von Beiträgen erheblich. :s3:


----------



## Jens_Ohm (15 Januar 2010)

Ich versuche immer die Bezeichnungen im Schaltplan, die in Bezug zu den Funktionen im Programm stehen, den Variablen Bezeichnungen voran zustellen.
 Des weiteren kommentiere ich im Code die Blöcke nach Funktionen.
 Da ich meist in C oder ST progge, mache ich das wie beim Code für PC Progs.
 Mein Lieblings Kommentar bei einem übernommenen Projekt „von hier an weiter mit 8 Bit, weils besser ist“   


 Grüße Jens


----------



## shovelhead (21 Januar 2010)

Hallo,
also ich versuche mich an die Vorschläge des TwinCAT InfoSys zu halten(Suche->Programmierkonventionen). Die Prefixe sind meiner Meinung nach schon sinnvoll. Ich gebe den Variablen meistens Namen, die ich verstehe und die sind auch meistens deutsch. Wenn das größere Projekte sind, an denen verschiedene Nationalitäten lass ich mir ja noch einreden, das Ganze in Englisch zu halten, aber bei kleineren Sachen, muß ich mich auskennen.
Bsp.: bFehlBest...boolesche VAR für die Fehler Bestätigung!
Gruß Sascha


----------



## bike (21 Januar 2010)

shovelhead schrieb:


> muß ich mich auskennen.



Wenn die Symbolik schuld ist an deinem Aus. bzw Nichtauskennen, dann läuft etwas verkehrt.

Symbole sind Krücken die helfen KÖNNEN aber nicht immer tun.
Wenn die Funktion einer ABSOLUTEN Adresse nicht klar  ist hilft auch die Symbolik nicht weiter


bike

P.S: Zur Erklärung und Verbesserung der Sinnhaftigkeit und des Verständnis der Sysmbolik würde ich immer wieder Translinie2000 empfehlen.


----------



## Jan (21 Januar 2010)

Bei uns entspricht der Variablenname / Symbol der Bezeichnung im Schaltplan, der Bezeichnung nach dem KKS, dann wird entsprechend durchnummerriert und die Verwendung in Kurzform angefügt.
Z.B. 
Seite: =13
Antriebsart: Pumpe
Anzahl: zweite Pumpe auf dieser Seite
Verwendung: Meldung Betrieb

=13AP01/Betr

Diese Bezeichnung wird im Programm weitergeführt und bei allem was zusammengehört entsprechend "gleich" bezeichnet, damit sofort erkennbar ist, wozu es gehört.
Die Bezeichnungen werden soweit möglich in der Doku, im SPS-Programm und im PLS einheitlich gehalten, damit alles übersichtlich und nachvollziehbar bleibt.


----------



## vierlagig (12 März 2010)

neue maschine ... natürlich gleich aufs programm gestürzt ... aber seht selbst :sw13:


----------



## rostiger Nagel (12 März 2010)

Jan schrieb:


> Bei uns entspricht der Variablenname / Symbol der Bezeichnung im Schaltplan, der Bezeichnung nach dem KKS, dann wird entsprechend durchnummerriert und die Verwendung in Kurzform angefügt.
> Z.B.
> Seite: =13
> Antriebsart: Pumpe
> ...


 
Eine Blatt-Nr zu nehmen halte ich für völlig Daneben. Wenn jetzt die 
Anlage erweitert wird ( und selbst wenn sie noch im Bau ist ) kann
es doch passieren das das Betriebsmittel nicht mehr auf das Gewünschte
Blatt passt oder es werden Seiten eingeschoben und schon mußt du die
Symbolik ändern, das kann es doch nicht sein.

Zur Symbolik selber noch mal "=" ist ein Anlagen Kennzeichen, wenn schon
Symbolik dann richtig.



> = Anlage
> . Funktionsgruppe
> - Betriebsmittel
> + Ort
> ...


 
So eine Kennzeichnung finde ich auch als Symbolik im Programm richtig.


----------



## Jan (13 März 2010)

Zitat:

Wenn jetzt die 
Anlage erweitert wird ( und selbst wenn sie noch im Bau ist ) kann
es doch passieren das das Betriebsmittel nicht mehr auf das Gewünschte
Blatt passt oder es werden Seiten eingeschoben und schon mußt du die
Symbolik ändern, das kann es doch nicht sein.

Das ist bei uns noch nicht vorgekommen. Unsere Zeichner fügen dann Blätter hinten dran wenn was dazu kommt.


----------



## Sockenralf (13 März 2010)

Hallo,

etwas anderes ist (wenn die BMK die Seitennummern beinhaltet) auch gar nicht handelbar (irgendwo bleibt immer ein Schildchen, ein Symbolikschnippsel, eine Mängelanzeige oder sonstwas mit dem dann falschen Text drauf)



MfG


----------



## Oberchefe (13 März 2010)

> Unsere Zeichner fügen dann Blätter hinten dran wenn was dazu kommt.



Schön für die Fehlersuche, ich muß dann wissen wenn was nachträglich dazugekommen ist und von der Funktion her eigentlich ganz woanders sitzt.


----------



## RobiHerb (15 März 2010)

*Omac etc.*

Deshalb hatte ich ja hier vor einigen Tagen nach OMAC und PackMl gefragt. Da sind nämlich die Variablen von den Amis genormt worden und erst einmal für den Fremden leicht lesbar aber mit viel Tipp Aufwand für den Entwickler verbunden.

Das ganze würde sich entschärfen, wenn so etwas wie Intellisense (Microsoft Visual Studio und andere) vorhanden wäre.

Ich halte es mit der "Hungarian" Schreibweise für die SPS Programmierung.

Ein Bool   Bezeichner beginnt immer mit bXxxx,
ein Word  Bezeichner beginnt immer mit nXxxxx,
ein Int     Bezeichner beginnt immer mit iXxxxx,
etc.

Man schleppt auch in der Syntax von ST viel unnötiges Geschreibsel mit rum, ich würde aus der C,C++,C# Erfahrung die Norm ergänzen:

// leitet einen Kommentar für den Rest der Zeile ein,

= sollte ersetzen :=,
der Vergleichsoperator wäre immer 2 Zeichen: <=, >=, ==, !=.

variable := variable + x; und vergleichbare Konstrukte werden:
    variable += x;

IF (Ausdruck) THEN      und vergleichbare Konstrukte 
    ....
END_IF

wird ersetzt durch:
IF (Ausdruck)
{
    ....
}

Wie sagte mal Ritchie: C ist keine geschwätzige Sprache.

Oder habe ich mir nur den Tipp Kurs gespart?


----------



## Mecki (16 März 2010)

Hallo,

also ich verwende für meine Symbolik immer die exportierten EPLAN Daten. Also =Anlage+Ort-BMK:ANSCHLUSS
Im Kommentar steht dann "Symbol" "Funktionstext"

Merker erstelle ich ähnlich, wobei dann im Kommentarfeld noch erläuternder Klartext steht.


----------



## Kieler (16 März 2010)

Das ist ein wirklich interessantes Thema. Ich bin immer wieder überrascht, wie weit die Lösungsansätze hier auseinander gehen.
Ich versuche immer eine gewisse Objektorientiertheit in die Bezeichnung zu bekommen. Also :

XXXXX_YY

Die XXX sind das Objekt. Also zum Beispiel eine Pumpe. Hinter dem Unterstrich, befindet sich die eigentliche Information. Also EIN, AUS, Störung usw. Die nächsten 100 Pumpen sind nach dem gleichen Schema aufgebaut. 
Ob die Pumpe jetzt im Schaltschrank von "K10" oder "Q25" angesteuert wird, ist mir eigentlich egal. Die Schnittstelle zum Schaltschrank, ist die EA Liste.


----------



## Mecki (16 März 2010)

Kieler schrieb:


> Das ist ein wirklich interessantes Thema. Ich bin immer wieder überrascht, wie weit die Lösungsansätze hier auseinander gehen.
> Ich versuche immer eine gewisse Objektorientiertheit in die Bezeichnung zu bekommen. Also :
> 
> XXXXX_YY
> ...




Frage meinerseits ist an der Stelle, wie du deine Adressen generierst? Alles einzeln Ab- bzw. eintippen oder hast du eine Automation dahinter liegen?


----------



## bike (16 März 2010)

Kieler schrieb:


> Ob die Pumpe jetzt im Schaltschrank von "K10" oder "Q25" angesteuert  wird, ist mir eigentlich egal. Die Schnittstelle zum Schaltschrank, ist  die EA Liste.


Da hast du aus Sicht des Programmierers recht, doch wer denkt an die armen Instandhalter? Wenn in der Symbolik schon die Ortsbezeichnung ist wird es einfacher. Und wenn dann noch die selbe Beschriftung an den Geräten ist, wie es ja sein soll, findet der den Fehler ziemlich schnell



Mecki schrieb:


> Frage meinerseits ist an der Stelle, wie du deine Adressen generierst? Alles einzeln Ab- bzw. eintippen oder hast du eine Automation dahinter liegen?


Also bei uns kommt die Liste aus Elcad, es ist aber unerheblich wer der Verursacher ist, die Bezeichner müssen eben nur Durchgängig sein Elektrik,Mechanik und Dokumentation.


bike


----------



## Kieler (16 März 2010)

Mecki schrieb:


> Frage meinerseits ist an der Stelle, wie du deine Adressen generierst? Alles einzeln Ab- bzw. eintippen oder hast du eine Automation dahinter liegen?



Das hängt vom jeweiligen Projekt ab. Ich habe mir einige Tools in VB geschrieben, die mir aus einer CSV (Excel) Datei einiges zusammenbasteln. Beim Projektanfang, entsteht jedenfalls erst einmal eine Excelliste. Aus diesen erstelle ich dann die EA Listen und die DB, für die Kopplung.



			
				bike schrieb:
			
		

> Da hast du aus Sicht des Programmierers recht, doch wer denkt an die  armen Instandhalter? Wenn in der Symbolik schon die Ortsbezeichnung ist  wird es einfacher. Und wenn dann noch die selbe Beschriftung an den  Geräten ist, wie es ja sein soll, findet der den Fehler ziemlich schnell



Für die Instandhaltung ist aus meiner Sicht ein vernünftiger Alarmtext auf der VISU wichtiger. Wenn ich zum suchen eines Hardwarefehlers das PG anschmeißen muss, läuft es schon nicht optimal. Unser Objektname (für die Pumpe) befindet sich natürlich in der Zeichnung, auf der Pumpe und den Steuerstellen. ...und irgendwann muss mal halt einen Blick in die Zeichnung werfen.



			
				bike schrieb:
			
		

> Also bei uns kommt die Liste aus Elcad, es ist aber unerheblich wer der  Verursacher ist, die Bezeichner müssen eben nur Durchgängig sein  Elektrik,Mechanik und Dokumentation.



Das sehe ich auch als wichtig an. Das muss durchgängig am Projektanfang erfolgen. Sonst hat der gleiche Antrieb nicht nur unterschiedliche Bezeichnungen, sondern wird im Sprachgebrauch auch noch anders genannt. Das geht soweit, dass man denkt die meinen einen ganz anderen Antrieb.


----------



## Perfektionist (16 März 2010)

so hat ein jeder so sein eigenes System ...

Für mein Programm sind ausschließlich Symbole maßgebend. Da halte ich es wie Kieler. Das macht den Code leichter portierbar (für mich - bestimmt gibt es noch immer die Liebhaber von Absolutadressen).

Für BMKs etc. habe ich Platz im Symbolkommentar gefunden. Und die Angabe der physikalischen Adresse im E/A-Bereich - das ist was ähnliches wie ein BMK - also aus Sicht des Codes eher variabel.

Und in der Visu - da wird natürlich nicht nur "Sicherungsfall Pumpe" gemeldet - da steht dann auch das BMK, dass man nicht rätselraten muss, welche der 100 Pumpen und dazugehörigen Moschus gemeint ist. Und auch der Schütz und Abgangsklemme sind benannt - man braucht fast nicht den Schaltplan, um den Fehler zu lokalisieren und zu verfolgen. (natürlich ist ganz nebenbei auch der SPS-Eingang benannt.)

Dann kann man jeden Sensor in der HMI ansehen, ebenfalls alle Angaben von BMK und Klemmpunkten vorhanden. Wenn das Signal für die Visu zu kurz ist, so kann auf ein Signalanalyser geschaltet werden, der aktuelle, kürzeste und längste Signallänge des Eingangs anzeigt.

Und in einer Sonderbetriebsart kann alles von Hand oder automatisch gepulst gefahren werden.

Gut - dass der halbe Schaltplan in ZuLi und Visu abgetippt ist - das ist schon ganz schön Aufwand und ödet mich manchmal schon sehr an. Und Änderungen ziehen sich somit durch die Programmdokumentation schon ziemlich durch. Aber die Entschädigung dafür kommt in dem Moment, wo etwas nicht funktioniert und man (ich) den Schaltplan nicht aufschlagen muss, nein, nichtmal das PG aufklappen. Selbst die Projektmappe mit der ZuLi ist meist unnötig: es ist ja alles in der Visu auffindbar. Und das kann auch eine Inbetriebnahme ungemein beschleunigen - der Nutzen besteht nicht erst ab Betrieb der Anlage/Maschine.

Allerdings: auch wenn ich mich "Perfektionist" getauft habe - meine Bitmeldungen sind leider noch immer über absolute Bezeichner zwischen SPS und HMI verbandelt


----------



## Mecki (17 März 2010)

Ich stimme meinen Vorpostern zu.
In meinem Fall ist es so, dass ich den Vorteil darin sehe, dass ich mir aus meinem CAE alle notwendigen Informationen exportieren kann und so schnell zu einer sauberen Symbolik komme.
Bei einer Anlage mit vlt 1000 E/As würde das Abtippen zu viel Zeit kosten.

Bisher waren die Kunden jedenfalls mit dieser Art der Programmierung immer zufrieden. Bei mir in der Firma ist es so, dass der Plan eigentlich die Mutter aller Dinge darstellt und das SPS-Programm aus dem EPLAN heraus entsteht.


----------



## vierlagig (17 März 2010)

Kieler schrieb:


> Wenn ich zum suchen eines Hardwarefehlers das PG anschmeißen muss, läuft es schon nicht optimal.



das ist auch eine Form von Arroganz. ...die irgendwie immer wieder auftaucht und nicht nachzuvollziehen ist, zumindest nicht, wenn man Instandhaltung betreibt und/oder betrieben hat.


----------



## RobiHerb (17 März 2010)

*Die Norm und deren Umsetzung ...*

Anscheinend haben wir doch nicht so grosse Freiheit, wenn wir der IEC Norm konform programmieren wollen.

Ich zitiere mal, ich hoffe, der Franzis Verlag erlaubt es, aus dem Buch SPS Programmierung nach IEC 61131-3:

"Die ersten 6 Zeichen müssen signifikant sein. Das bedeutet, dass es möglich ist, dass ein System zwei Bezeichner, die sich erst ab dem 7.Zeichen unterscheiden, als den selben Bezeichner auffasst."

Kann sein, muss nicht und wie es sich real verhält, entscheidet der Hersteller der SPS oder der Entwickler der Programmier Software!


----------



## bike (17 März 2010)

vierlagig schrieb:


> das ist auch eine Form von Arroganz. ...die irgendwie immer wieder auftaucht und nicht nachzuvollziehen ist, zumindest nicht, wenn man Instandhaltung betreibt und/oder betrieben hat.



Wie wahr, leider wie wahr.

Selbst bei Serienmaschinen die ca 500 mal pro Jahr verkauft werden ist das nicht immer der  Fall.
Auch da muss der Bediener bzw Instandhalter manchmal verschiedene E/A oder M oder ähnliches prüfen damit der Entwickler weiss wo der Fehler sich versteckt hat.


bike


----------



## Kieler (17 März 2010)

vierlagig schrieb:


> das ist auch eine Form von Arroganz. ...die irgendwie immer wieder auftaucht und nicht nachzuvollziehen ist, zumindest nicht, wenn man Instandhaltung betreibt und/oder betrieben hat.



Sehe ich nicht so. Es ging hier nicht gegen die Instandhaltung und ihren berechtigten Anspruch, ein sauber strukturiertes Programm vorzufinden. Es war mehr ein Anspruch an die eigene VISU, die Instandhaltung möglichst effektiv zu unterstützen.


----------



## Kieler (17 März 2010)

RobiHerb schrieb:


> Anscheinend haben wir doch nicht so grosse Freiheit, wenn wir der IEC Norm konform programmieren wollen.
> 
> "Die ersten 6 Zeichen müssen signifikant sein. Das bedeutet, dass es möglich ist, dass ein System zwei Bezeichner, die sich erst ab dem 7.Zeichen unterscheiden, als den selben Bezeichner auffasst."



Das war mir bis dato nicht bewusst. Habe ich selbst auch schon andere Dinge aufgesetzt. Aber es gut zu wissen.


----------



## Perfektionist (17 März 2010)

RobiHerb schrieb:


> Anscheinend haben wir doch nicht so grosse Freiheit, wenn wir der IEC Norm konform programmieren wollen.
> ...


AUA!

Na, ja, vielleicht sollte ich mal in Betracht ziehen, mich wieder an 8.3-Dateinamen zurückzuerinnern ...


----------



## vierlagig (17 März 2010)

Perfektionist schrieb:


> AUA!
> 
> Na, ja, vielleicht sollte ich mal in Betracht ziehen, mich wieder an 8.3-Dateinamen zurückzuerinnern ...



sind deine dateinamen etwa länger? wahrscheinlich noch mit leerzeichen und son schruz ... versteh einer die welt...


----------



## Perfektionist (17 März 2010)

vierlagig schrieb:


> sind deine dateinamen etwa länger? wahrscheinlich noch mit leerzeichen und son schruz ... versteh einer die welt...


nein, natürlich nicht!!! PFDSMMONY.mp3 ist klar erkennbar Pink Floyd Dark Side Of The Moon Money.


----------



## vierlagig (17 März 2010)

Perfektionist schrieb:


> nein, natürlich nicht!!! PFDSMMONY.mp3 ist klar erkennbar Pink Floyd Dark Side Of The Moon Money.



was ist *.mp3?


----------



## Perfektionist (17 März 2010)

vierlagig schrieb:


> was ist *.mp3?


Wer das Netz nicht bedienen kann, wird auch mit den folgenden Links nichts anfangen können ...

http://www.stupidedia.org/stupi/Mp3

http://kamelopedia.mormo.org/index.php/MP3

(ja, ich verstehe Deine unterschwellige Forderung, nun auch endlich bei den Dateinamenserweiterungen mehr Klartext einzuführen.)

so, nun schlechtes Gewissen hab: wie lang macht Ralle dieses Plauderstündchen noch mit?


----------



## vierlagig (17 März 2010)

Perfektionist schrieb:


> (ja, ich verstehe Deine unterschwellige Forderung, nun auch endlich bei den Dateinamenserweiterungen mehr Klartext einzuführen.)



gar nicht, mein DOS 6.2 kennt *.MP3 nicht ... aber die FreeDOS-Version kanns, was ich schon fast verrückt finde ...

8 Zeichen für einen Dateinamen sind halt leider bei Sepp7 immer noch Standard, was aber bei automatisierter Auswertung z.B.von Quellen oder der Projekt-DBFs um z.B. den KNOFF-HOFF-Schutz zu eliminieren schon wieder sehr viel Sinn macht (bei letzteren eher nicht, außer dass man nicht soviel tippen muß ^^ ) ...
bei Variablennamen könnte man mit 8 Zeichen hinkommen, oder? mit ordentlicher, Hardwarebezogener Struktur...


----------



## Perfektionist (18 März 2010)

vierlagig schrieb:


> ...
> bei Variablennamen könnte man mit 8 Zeichen hinkommen, oder? mit ordentlicher, Hardwarebezogener Struktur...


Huch - tut bei Dir die Umschalttaste wieder?

ja! Die Norm fordert ja nur 6 Zeichen ...

ich finde
	
	



```
U 102S2
```
 
sehr viel aussagekräftiger als 
	
	



```
U Befehl_Start
```
 
schade nur - ich hätte gerne noch das Anlagen- und Ortskennzeichen im obigen Beispiel ...


----------



## Question_mark (18 März 2010)

*Unterstützung bei Fehlersuche durch VISU*

Hallo,



			
				Kieler schrieb:
			
		

> mehr ein Anspruch an die eigene VISU, die Instandhaltung möglichst effektiv zu unterstützen.



Den Anspruch sehe ich auch als gerechtfertigt an, aber bringe dann dies mal in die Kalkulation für ein Angebot an den Kunden ein. Irgendwie entstehen Kosten für die Realisierung solcher Aufwendungen für die Unterstützung der Fehlersuche durch ein gutes, visuelles Systems zur Unterstützung der Instandhalter. Den zusätzlichen Aufwand zur Unterstützung der Instandhalter durch eine smarte Visu ist nicht gerade gering (aber eigentlich notwendig und sinnvoll), aber bezahlen will das keiner.

Macht bei Serienmaschienen bestimmt Sinn, da sich die Entwicklungskosten auf eine x-Anzahl von Anlagen verteilen, aber bei individuellen Programmen kann und will das (leider) kein Auftraggeber bezahlen. Ich bin ganz Deiner Meinung, jede Anlage aus Gründen der Effizienz bei der Wartung und Instandhaltung durch ein geeignetes Diagnosesystem (ob nun Visu oder sonstwas) zu unterstützen. Fakt ist aber, wenn Du ein solches System in Dein Angebot einkalkulierst, wirst Du erst gar nicht zur Auftragsverhandlung eingeladen, Du bist von Anfang an zu teuer ...

In diesem Sinne, der Einkauf programmiert eigentlich vor, wie anwenderfreundlich die gelieferte Anlage sein wird 
Ob das immer sinnvoll und vorteilhaft für die Instandhalter ist, möchte ich auch stark bezweifeln, ist aber leider Realität.

Gruß

Question_mark


----------



## Zefix (19 März 2010)

Perfektionist schrieb:


> ich finde
> 
> 
> 
> ...



Naja, Befehl_start liest sich wiederum für mich besser, Wenn ich unbedingt den Eingang wissen will, fahr ich mit der Maus drüber oder mach die Symbolik auf ;-)
Denn mit 102S2 brauch ich eigentlich gleich gar keine Symolik, wenns so mit S3, S4... so weiter geht.



Bei uns siehts z.B.oft so aus:

U E102_Taste_Start  (Und im Symbolkommentar evtl. noch: Starttaste PP031)

Bei unseren neueren Anlagen ist die Adresse nicht mehr im Symbol enthalten und störte bis jetzt noch nicht.
Sieht halt z.B. dann so aus:
L MW_Programmnummer


Auch an Bausteinen wird die Übergabe anegeben mit vorangestellten i,io,o für IN,INOUT und OUT usw...

Find das so einwandfrei 

Gruss Andi


----------



## Perfektionist (19 März 2010)

Zefix schrieb:


> Naja, Befehl_start liest sich wiederum für mich besser,
> ...


tschuldigung - ich dachte, aufgrund der vorangegangenen Posts sei mein Beitrag unmissverständlich als Ironie, Sarkasmus oder was auch immer erkennbar gewesen. Insbesondere wollte ich aber auch meinen Standpunkt zu den sechs signifikanten Symbolbezeichnern untermauern, da ich auch 24 Zeichen bereits als zu knapp erachte, um wirklich sprechende Symbole zu erstellen.

"Befehl_Start" kann laut Norm identisch sein mit "Befehl_nicht_Stopp". dagegen wehre ich mich ...


----------



## Kieler (19 März 2010)

*kalkulierte VISU*



Question_mark schrieb:


> Den Anspruch sehe ich auch als gerechtfertigt an, aber ......
> Question_mark



Ja, leider hast Du recht. Alles andere ist wohl Wunschdenken. 

Ich stricke gerade auch noch an einer Anlage, die schon letzte Woche fertig sein sollte. Oft kann man so etwas nicht machen.


----------

