Variablenbezeichnung

Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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 :(
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.
 
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!
 

Anhänge

  • IEC_BEZEICHNER.jpg
    IEC_BEZEICHNER.jpg
    430,5 KB · Aufrufe: 59
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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.
 
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.
 
(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...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...
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
Code:
U 102S2

sehr viel aussagekräftiger als
Code:
U Befehl_Start

schade nur - ich hätte gerne noch das Anlagen- und Ortskennzeichen im obigen Beispiel ...
 
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 :rolleyes:
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
 
Zuletzt bearbeitet:
ich finde
Code:
U 102S2
sehr viel aussagekräftiger als
Code:
U Befehl_Start
schade nur - ich hätte gerne noch das Anlagen- und Ortskennzeichen im obigen Beispiel ...

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 :cool:

Gruss Andi
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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 ...
 
Zurück
Oben