# BMK's im SPS-Software Projekt verwenden: gut oder schlecht?



## Automatinator (20 Juni 2018)

Hallo zusammen

Es stellt sich ja jeder SPS-Programmierer mal die Frage: wie verbinde ich das Elektro-Schema mit der Software (SW) bezüglich der gemeinsamen Hardware und ihrer Bezeichnung.
Da gibt es ja Ansätze wie:
(a) Bezeichnungen der SW als Beitexte im El.Schema-SPS-I/O
(b) Oder die BMK's vom El.Schema im Software-Projekt einbeziehen (z.B. Variablen- und Baustein-/Funktions-InstanzNamen)

für (a) und (b) kann man noch entscheiden wie weit bzw. tief diese Übergreifenden Bezeichnungen gehen sollen:
z.B. bei:
 (a) nur in der Übersicht, oder im ganzen Schema bei allen Positionen (Ein/mehrpolig) usw
(b) nur in der direkten HW-Schnittstellenvariable, oder bis runter zu den Instanzen der Baustein/Funktions-Namen

Ich hab eine Klare Meinung, die aber nur ca. 50% der Programmierer, die ich kenne, mit mir teilen. Deshalb würde ich sehr gerne eure Meinung wissen.
Ich werde vorerst meine Meinung gewollt aus der Diskussion halten. 



*1) Wie ist eure persönliche Meinung zu?*


*2) Da ich beim Google nichts gefunden habe: Kennt ihr Experten-Meinung/Beiträge/Abhandlungen zu diesem Thema? Wenn ja, bitte Link oder Namen / Titel Posten 

*
Danke und Gruss
Autom.


----------



## Blockmove (20 Juni 2018)

Ich glaub da gibt es keine eindeutige Empfehlung.
Viel hängt schon vom Aufbau des BMK ab.
Bei SPS-Signalen ist bei uns die Adresse Bestandteil des BMK.
Daher ist eine Zuordnung gegeben.
Bei anderen BMK-Systemen (Seite-Pfad, Funktionsgruppen, ...) macht es natürlich Sinn, dass dies in irgendeiner Form in der Variable / Symbolik auftaucht.
Im Variablennamen habe ich es meist nicht so gern. Ist halt deutlich mehr Arbeit, wenn Code kopiert wird. Daher am liebsten im Symbolkommentar.

Gruß
Blockmove


----------



## Chräshe (21 Juni 2018)

Ich würde nicht nur das BMK, sondern gerne noch zusätzliche Spalten in der Stuerung vorsehen:
Filterung und Organisation der Symbolnamen

aber leider scheint die Nachfrage nicht all zu groß zu sein...


----------



## vollmi (26 Juni 2018)

Chräshe schrieb:


> Ich würde nicht nur das BMK, sondern gerne noch zusätzliche Spalten in der Stuerung vorsehen:
> Filterung und Organisation der Symbolnamen
> 
> aber leider scheint die Nachfrage nicht all zu groß zu sein...



Ich hätte das gerne ähnlich wie früher in der Step7 Welt. Da konnte man umschalten zwischen Absolutadresse anzeigen und Symbolname anzeigen.

Die Absolutadresse ist mittlerweile ja irrelevant. Aber ich fände es gut wenn eine Variable aus mehr als nur einem Symbol besteht. Cool wäre ein Symbol (Pump3.Sp) eine BMK (+14.LST.D.A3.Sp) und vielleicht noch zusätzliche Symbole pro Symbol die man nutzen kann oder auch nicht (Symbolspalte 3, Symbolspalte 4) und dann einen Knopf mit dem man umschalten kann, ob man in der Software an den Faceplates Symbolspalte 1, 2,3 oder 4 sehen will.
Dann könnte man ein Objekt jederzeit mit dem Symbolischen namen anschliessen. Ist oft einfacher wenn man Pumpe 1 ersetzen kann gegen Pumpe 2 und beim nächsten aufruf gegen Pumpe 3. 
Wenn man das Gewerk ändert, ist es oft einfacher schnell den AKS Code einzugeben fürs erste Objekt dann schaltet man um und sieht ah jetzt ist der 13te Motor da angeschlossen.

Wenn man dann aus der Software noch auf die einzelnen Symbolinfos zugreifen könnte (z.B. für die Alarmgenerierung) würde ich ein goldenes Kalb opfern.


----------



## Lars Weiß (26 Juni 2018)

Betriebsmittelkennzeichnung im E-Plan und in der Symbolik im SPS-Programm sind ein absolutes muss. Vorgegeben werden diese normalerweise durch das R&I-Schema. Ich gehe sogar soweit, das ich einen Export aus E-Plan verlange. Dann gibts auch keine Diskussionen über die Bezeichnung wenn Anlagentechnik, E-Planer und Programmierer an einem Tisch sitzen. Alle sprechen immer von demselben Betriebsmittel.


----------



## Automatinator (2 Juli 2018)

Danke vorerst an alle die geantworten haben!

Aber ich teile da wohl eine andere Meinung. Meiner Meinung nach hat ein BMK (Betriettmittelkennzeichung als spezifisches Kürzel vom El.-Schmema vorgegeben.) nichts in einem SW-Projekt verloren.
Die Verbindung sollte ein projektweites (HW/SW/PL) abgemachtes Bezeichnungskonzept (ganze Wörter, keine Abkürzungen bzw. diese soweit Möglich vermeiden) versehen. Welche dann in allen Entwicklungen und Dokumentationen verwendet werden und somit übereinstimmen.

z.B.: "Auswurfstation B Zylinder Heben" anstatt =AB-4Q3


----------



## vollmi (2 Juli 2018)

Automatinator schrieb:


> z.B.: "Auswurfstation B Zylinder Heben" anstatt =AB-4Q3



Jargl. Wie bringst du dass denn in einer struktur unter.
"Auswurfstation B" wird ja wohl noch andere Funktionen haben als nur "Zylinder heben"
Da würds ja dann doch sinn machen dass man das anspricht im Stil von

"Auswurfstation B"."Zylinder A"."heben"

oder hast du das listen mit tausenden Symboleinträgen? Statt gruppierungen nach Objekten und Unterobjekten?


----------



## JesperMP (2 Juli 2018)

Wir verwenden BMKs überall, auch in der HMI für Alarmmeldungen usw.
Einsigste streitpunkt ist wie man einzelne Signale auf denselbe Gerät identifizert.

Entweder durch Klemmbezeichnung (=C5-Q1:A1 und =C5-Q1:14), oder ein ergänzender Kommentar (=C5-Q1_Spule und =C5-Q1_Rückmeldung).
Den erste Verfahren ist vielleicht meist "korrekt", aber ich finde den letzere Verfahren lesbarer.
Dazu gibt es Kommentare, aber ein direkten identifizierung hilft mMn. enorm.


----------



## Automatinator (2 Juli 2018)

vollmi schrieb:


> Jargl. Wie bringst du dass denn in einer struktur unter.
> "Auswurfstation B" wird ja wohl noch andere Funktionen haben als nur "Zylinder heben"
> Da würds ja dann doch sinn machen dass man das anspricht im Stil von
> 
> ...



Nein, strukturiert natürlich

aber im El. Schema ist dann der gleiche Text an dem I/0 Z.b.


----------



## hucki (2 Juli 2018)

Automatinator schrieb:


> Meiner Meinung nach hat ein BMK (Betriettmittelkennzeichung als spezifisches Kürzel vom El.-Schmema vorgegeben.) ...


Aus diesem Grund wurden ja die Referenzkennzeichen nach EN 81346 eingeführt, die übergeordnet für *alle Gewerke* gelten.

Sprich, in E-, Hydraulik-, Pneumatik- und sonstwas für Plänen immer die gleiche Kennzeichnung.


----------



## Automatinator (4 Juli 2018)

hucki schrieb:


> Aus diesem Grund wurden ja die Referenzkennzeichen nach EN 81346 eingeführt, die übergeordnet für *alle Gewerke* gelten.
> 
> Sprich, in E-, Hydraulik-, Pneumatik- und sonstwas für Plänen immer die gleiche Kennzeichnung.



Eine Norm die fast alle 2 Jahre ändert. Hast du mal die History dieser Norm angeschaut? z.B. wieviel mal die Bustaben vertauscht und gewechselt haben?


----------



## santacrews (4 Juli 2018)

Ich bin auch eindeutig für BMK in der Software. BMK ist BMK ist BMK und steht überall. Am Sensor, Aktor, evtl. Kabel und im ePlan. 
Wenn +07.01-BG3004 einen Fehler hat, dann gibt es da kein Vertun. Bei allem anderen redet man sich um Kopf und Kragen und zudem macht es auch noch jeder anders. Der eine nennt es Hubstation, der andere Hebestation, der nächste Hebeeinheit. Und bei Hebeeinheit A und Hebeeinheit B weiß man schon gar nichts mehr. Und wenn die nächste Anlage ins Ausland geht und in englisch programmiert werden muss, dann ist sowiso alles anders. 
BMK ist eindeutig und gilt überall. Für alle weiteren Informationen kann man gerne das Kommentarfeld verwenden, aber nicht die Symbolbezeichnung.

Ich denke eher, dass die Meinungsverteilung eine 95/5 Aufteilung für BMK ist und nicht 50/50.


----------



## santacrews (4 Juli 2018)

JesperMP schrieb:


> Einsigste streitpunkt ist wie man einzelne Signale auf denselbe Gerät identifizert.
> 
> Entweder durch Klemmbezeichnung (=C5-Q1:A1 und =C5-Q1:14), oder ein ergänzender Kommentar (=C5-Q1_Spule und =C5-Q1_Rückmeldung).
> Den erste Verfahren ist vielleicht meist "korrekt", aber ich finde den letzere Verfahren lesbarer.



Da wirds in der Tat etwas kniffliger, aber bei den meisten Sachen, wie z.B. das Schütz/Relais, was du angesprochen hast sollte jeder elektriker im Schlaf wissen, was :A1 und was :14 ist


----------



## Automatinator (4 Juli 2018)

santacrews schrieb:


> Wenn +07.01-BG3004 einen Fehler hat, dann gibt es da kein Vertun.



Sofern die Software und das Schema übereinstimmen, ja.


Ich muss dazu sagen, das ich aus der Prototypen, 0-Serie, Sondermaschinen-Ecke komme und man da die Unabhängikeiten von anderen Entwicklern anstreben gelernt hat. (unschönerweise, leider)

Bei Serienmaschinen kommt dieser BMK in der SW Vorteil viel eher zum Tragen, weil sich der Pflegeaufwand definitiv lohnt.

Es kommt auch drauf an ob man sich im Gross-Anlagenbau, oder im Kleinmaschinen-Branche findet und entwickelt...
Weil auch bei Gross-Anlagen mit vielen Aktoren/Sensoren wird ein Ganzwort-Laberling schwirig und ggf. zu kompliziert. Da mach der BMK in der SW auch mehr Sinn.


----------

