Bausteinnamen S7

[Waelder]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,

wir basteln gerade an einer "Programmiervorschrift" so´n art Leitfaden für unsere Firma. Im G&G sind wir uns über die Namensgebung der symbolischen Adressierung im reinen aber an einem Punkt scheiden sich unsere Meinungen.
Ein teil meint :

FC,FB,DB usw... müssen immer mit FC,FB,DB anfangen
BSP :
FC_HEIZUNG
DB_HEIZUNG
FB_LICHT
DB_LICHT
FC_MANUELL
DB_MANUELL
FB_VALVE_53
FB_MOTOR_RL
usw.

Die anderen sagen :
Warum fangen wir nicht mit der Symbolik an, da lässt sich besser Sortieren (im S7 Manager) und man sieht sofort welche Bausteine zueinander gehören. Wir benutzen nur FB und FC vorneweg, wenn der Baustein aus der Bibliothek kommt, da er eh fast nur Multiinst. oder immer das selbe ist.

Die machen es dann wie folgt :
HEIZUNG_FC
HEIZUNG_DB
LICHT_FC
LICHT_DB
MANUELL_FB
MANUELL_DB
FB_VALVE_53 <- Element aus Bibliothek
FB_MOTOR_RL <- Element aus Bibliothek

Wie macht Ihr das ? Oder gibts da vielleicht "anerkannte" Richtlinien

Gruss Wälder

 

[vierlagig]

frage: warum die symbolik unnötig unlesbar machen? also, warum dazu schreiben ob es ein FB oder ein FC ist? im programm siehst du an der art der verwendung was es ist und wenn du ihn im programm aufrufen willst, sind sie im katalog nach FC und FB getrennt aufgelistet. überall anders, also zum beispiel im projekt ordnen werden auch die FBs vor den FCs aufgelistet.

wenn es einen FB_heizung und einen FC_heizung gibt, dann fehlt da wohl offensichtlich noch was in der symbolik um genauer zu beschreiben wo der funktionelle unterschied ist, oder?

[edit] jetz hab ichs gesehen - ja, sorry - also die kennzeichnung eines IDB würd ich hinten anhängen, beim FB aber nicht dazu schreiben, das es ein FB ist, da trifft obiges zu [/edit]

 

[Perfektionist]

Zuviel Werbung?
-> Hier kostenlos registrieren

ich komme schon lange ohne FC aus, es sei denn, es handelt sich wirklich um eine Funktion, die garantiert niemals statischer Daten bedürfen wird (solche fünf-Zeiler code ich aber idR direkt). Globale DB brauche ich auch schon lange nicht mehr - seither konnte ich den Bedarf an Globalvariablen aus dem Merkerbereich decken.

Ansonsten heißt ein FB halt "Heizung", seine Instanz "Heizung_Instanz". Und wenn es mehrere Heizungen gibt, dann eben noch "Heizung_Instanz2" und "Heizung_Instanz3". Fertich!

 

[Waelder]

@4L

also, warum dazu schreiben ob es ein FB oder ein FC ist?

ok Versteh Dich, du hast Recht. Der Grund ist "Alte Zöpfe" ...war schon immer so, bleibt auch so... mir ists egal ob mit oder ohne FC,FB usw.
Ich tu mir auch immer schwer mit warum ein Element nochmals zusätzlich mit FC oder FB oder Merker zu beschreiben. Es heisst ja schon so ;-)
@4L

enn es einen FB_heizung und einen FC_heizung gibt, dann fehlt da wohl offensichtlich noch was in der symbolik um genauer zu beschreiben wo der funktionelle unterschied ist, oder?

Die Bausteine sind dann im Symbolkommentar dann genauer beschrieben. Oder haben im Innern eine genaue Beschreibung.

@Perfektionist
Werde ich auch mal tun, die DB,FB weglassen will ich schon lang, darf aber noch nicht. Aber was mich ein klein wenig stört (ist aber nicht unbedingt relevant) ist, dass ich für den Heizungs DB Heizung_Instanz dahinter schreibe. Aber nur wegen der Länge DB ist halt kürzer Heizung_DB & Heizung1_DB gfällt mir halt besser.

Gruss Wälder

 

[Perfektionist]

Mein Chef schreibt statt dessen einfach "Heizung_I" und - ich weiß nicht - "Heizung_I2" oder "Heizung2_I". "Heizung_Instanz" steht bei mir auch in der Deklaration von Multiinstanzen im stat-Bereich.

call #Heizung_Instanz

sieht dann zwar etwas lustig aus, aber bei der Deklaration finde ich die Benennung der Struktur Heizung_Instanz vom Datentyp Heizung ganz OK.

 

[kiestumpe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir machen es so:

Nur die Instanz-DB erhalten den Präfix "IDB_", gefolgt of vom FB-Name oder ähnlichem, ansonsten werden die Bausteine mit Groß/kleinschreibung erstellt.
Großschreibung verwenden wir nur noch für Konstanten, falls man die eben mal in SCL braucht.
Ob FC/FB kann man sich ja vom System aus jederzeit einblenden lassen - also Überflüssiger Ballast, das gleiche gilt für Merker und E/A's.
Diese Schreibweise, den Prefix a,e,m usw in den Symbolnamen zu packen, kommt wohl aus Systemen, die das nicht anzuzeigen erlauben. Meiner Meinung nach bei S7 unnötiger Ballast, den Ihr euch nicht ans Bein binden sollt.

Um nicht altes über den Haufen werden zu müssen, helfen solche Sätze in den Richtlinien, wie, die Regelung gilt ab <Datum>...

hth

 

[Waelder]

@kiestumpe
*ACK*
Bravo endlich mal klare worte . Warum den die Symbolik aufblasen mit EAMDBFB..usw... da mach ich doch lieber noch ne MSR oder sonst was nützliches dran.
Ich werd mal versuchen bei uns rumzubringen das wir auf das "EAMDBFB..usw..." Gelumpe verzichten.

Gruss Wälder

 

[vierlagig]

Bravo endlich mal klare worte.

also wirklich, das ist ja wie ein tritt ins PG ... den aufblähgedanken habe ich auch vertreten und die IDB geschichte wurde von perfektionist untermauert ... aber wahrscheinlich hast du nur die hälfte gelesen oder verstanden ...

vielleicht kannst du ja hier (danke für den link an andreas!) nochmal nachlesen wo die so fundierte meinung des kollegen kiestumpe u.a. gebildet wurde.

ich sag dazu nix mehr! :evil:

 

[kiestumpe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Versteht hier jemand das Geschiss, das 4lagig gerade macht?

 

[vierlagig]

Versteht hier jemand das Geschiss, das 4lagig gerade macht?

da hat sich der falsche angesprochen gefühlt - kiestumpe, das ging nicht gegen dich, deine meinung ist nachvollziehbar und vernünftig dargestellt. PUNKT.

 

[kiestumpe]

...achso, klang irgendwie anders. Zum Hintergrund des links, damals gings mir eigentlich nur um ne Schriftform in der diese Regeln aufgelistet sind und im Zusammenhang mit B&R, für ne Beratung bzw. Erstellung von Programmierrichtlinien für B&R-Steuerungen. Da wir hauptsächlich S7 einsetzen trifft das nicht so gut zu. Das oben beschriebene Verfahren wende ich schon seit Jahren an, also weit vor dem ich diesen Thread gestartet habe und fahre gut damit, es sei denn ein Kunde wünscht es explizit anders. Wenn er den Mehraufwand anderer Symbolik bezahlt tun wir das auch

 

[Perfektionist]

Zuviel Werbung?
-> Hier kostenlos registrieren

aus aktuellem Anlass - grad progg ichs schon fällts mir auf:

wenn es einen FB "Heizung1" und einen FB "Heizung2" gibt, so müssen die Instanzen folglich "Heizung1_Instanz1", "Heizung1_Instanz2", "Heizung2_Instanz1" und "Heizung2_Instanz2" usw. heißen.

 

[Waelder]

OFFTOPIC !
@4L
Sorry aber ich glaub ich werd mir mal ein "Kügelchen mit Bedienerin" zulegen um mir vor der Beantwortung alle Möglichkeiten auzulisten um fehlerhaften Verständnissen vorzubeugen.

OFFT ENDE

So Statements :

Nur die Instanz-DB erhalten den Präfix "IDB_", gefolgt of vom FB-Name oder ähnlichem, ansonsten werden die Bausteine mit Groß/kleinschreibung erstellt.

so würde ichs auch machen....dann

Ob FC/FB kann man sich ja vom System aus jederzeit einblenden lassen - also Überflüssiger Ballast, das gleiche gilt für Merker und E/A's.

also d.h ich kann anstelle Heizung_FB Heizung schreiben ....oder nicht ?
Ich lass FC FB M usw weg. so habs ich verstanden.

Diese Schreibweise, den Prefix a,e,m usw in den Symbolnamen zu packen, kommt wohl aus Systemen, die das nicht anzuzeigen erlauben. Meiner Meinung nach bei S7 unnötiger Ballast, den Ihr euch nicht ans Bein binden sollt.

Jawohl !

 

[HeizDuese]

Bei uns haben die Bausteine einen aussagekräftigen Kürzel, z.B. Trockner, Trockner_Antriebe, Instanz-DBs haben bei uns den Namen des FB's mit vorgestellten Präfix "IDB_" (z.B. IDB_Trockner_A, IDB_Trockner_B).

 

[kiestumpe]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Waelder: Du hast's verstanden. Ein BMK kann auch ne Möglichkeit sein 'nen Instanznamen zu bilden, das Ausführlichere steck ich meist in den Symbolkommentar.