"Saubere" Programme

Zuviel Werbung?
-> Hier kostenlos registrieren
Wie wärs denn mit dem Vorschlag, anstatt der Merker zwei Datenbausteine zu verwenden z.B. "DB-IN", "DB-OUT"?
Hab mit PEW und PAW schon ähnliches gemacht und die Erfahrungen, was gute Vorbereitung anbetrifft, sind recht gut.

is aber von der symbolik her eher gewöhnungsbedürfdig, wenn da dann DB_IN.A420_Q32_DIC_RDY stehen würde ... also alles im allen unübersichtlicher ... auch bei darstellung ohne symbolen...
 
Ich denke , das Rangieren von Merkerbereichen kommt noch aus der Zeit vor einer komplett symbolischen Programmierung, wie sie in einer IEC-Umgebung standardisiert ist.

100%ige Zustimmung!


Umrangieren eines E/A mach ich rein über die Symboltabelle (Operandenvorrang Symbol):

alt: "DI_Befehl_Start" an E0.0

ändern in Symboltabelle in
neu: "DI_Befehl_Start" an E1.1

dann Bausteinkonsistenzprüfung (die findet dann alle geänderten Symbole), schließlich die neuen Bausteine auf die CPU schießen.

(und wer E/A über Pointer addressiert, den schieß ich auf den Mond !!!)


EDIT: und hab es grad nochmal ausprobiert: bei einem jungfräulichen Projekt ist bei Siemens immer noch Operandenvorrang Absolutwert voreingestellt :sb7: :sb6: Leben die immer noch hinter dem Mond?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
100%ige Zustimmung!


Umrangieren eines E/A mach ich rein über die Symboltabelle (Operandenvorrang Symbol):

alt: "DI_Befehl_Start" an E0.0

ändern in Symboltabelle in
neu: "DI_Befehl_Start" an E1.1

dann Bausteinkonsistenzprüfung (die findet dann alle geänderten Symbole), schließlich die neuen Bausteine auf die CPU schießen.
Wer allerdings schon mal in einer Nachtschicht eine Störung an einer Anlage beseitigen musste, weil ein SPS- Eingang defekt war, der wird die Variante mit dem Umrangieren auf Merker oder DB-Bereiche (egal) zu schätzen wissen.
Also ich finde das nicht schlecht.:)
 
Wer allerdings schon mal in einer Nachtschicht eine Störung an einer Anlage beseitigen musste, weil ein SPS- Eingang defekt war, der wird die Variante mit dem Umrangieren auf Merker oder DB-Bereiche (egal) zu schätzen wissen.
Also ich finde das nicht schlecht.:)

Ich versteh das nicht, was ist daran so schwierig, mit "Gehe zur Verwendungstelle" oder mit "Umverdrahten" den defekten Eingang auf einen anderen Eingang zu legen? Das Umrangieren macht das Programm nur unübersichtlicher und ist für mich reine Recourcenverschwendung.
 
Ich versteh das nicht, was ist daran so schwierig, mit "Gehe zur Verwendungstelle" oder mit "Umverdrahten" den defekten Eingang auf einen anderen Eingang zu legen? Das Umrangieren macht das Programm nur unübersichtlicher und ist für mich reine Recourcenverschwendung.

denk doch auch mal einer an die heulsusen von instandhalter ... wenn es in mehreren bausteinen umverdrahtet wird, müssen alle bausteine wieder in die cpu geladen werden und wer, wenn nicht der instandhalter, vergisst da gern mal einen baustein...
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
100%ige Zustimmung!


Umrangieren eines E/A mach ich rein über die Symboltabelle (Operandenvorrang Symbol):

alt: "DI_Befehl_Start" an E0.0

ändern in Symboltabelle in
neu: "DI_Befehl_Start" an E1.1

dann Bausteinkonsistenzprüfung (die findet dann alle geänderten Symbole), schließlich die neuen Bausteine auf die CPU schießen.

(und wer E/A über Pointer addressiert, den schieß ich auf den Mond !!!)


EDIT: und hab es grad nochmal ausprobiert: bei einem jungfräulichen Projekt ist bei Siemens immer noch Operandenvorrang Absolutwert voreingestellt :sb7: :sb6: Leben die immer noch hinter dem Mond?
Tjaja, das alte Leid. Hat das immer zu 100% funktioniert mit dem hin- und herschalten Symbolisch / Absolut?
 
@Ludwig und den Perfektionist:
*ACK*

Also ein und Ausgänge auf Merker oder DBs zu rangieren ist IMHO völlig Überflüssig.

...
EDIT: und hab es grad nochmal ausprobiert: bei einem jungfräulichen Projekt ist bei Siemens immer noch Operandenvorrang Absolutwert voreingestellt :sb7: :sb6: Leben die immer noch hinter dem Mond?

Ich finde es auch gruselig das Siemens noch so stark auf die Absolute Adressierung setzt.

@OHGN:
Ein nicht Siemens Beispiel wie einfach das geht, einen Eingang um zu verdrahten.
Einfach in den Globalen Variablen der Eingänge aus:
Code:
  _0B080A       AT %IX0.8      : BOOL;  (*d Druckluft vorhanden        *)
                                        (*e compressed air ok          *)
                                        (*c Tlak nalezen               *)
z.B. ein:

Code:
  _0B080A       AT %IX1.7      : BOOL;  (*d Druckluft vorhanden        *)
                                        (*e compressed air ok          *)
                                        (*c Tlak nalezen               *)
machen und fertig ist die Aktion. Das Umklemmen der Strippen darf man natürlich nicht vergessen ;o)

Auch das Argument mit dem Austesten im Büro von Approx greif IMHO nicht. Wenn man nicht weis auf welchem Physikalischen Eingang später einmal der Druckschalter angeschlossen sein wird, lässt man bei der Variablen Deklaration die AT Verknüpfung weg und fügt sie ein wenn man es weis.
Code:
  _0B080A                      : BOOL;  (*d Druckluft vorhanden        *)
                                        (*e compressed air ok          *)
                                        (*c Tlak nalezen               *)
Das Siemens das mit der reinen Symbolischen Adressierung nicht auf die Reihe bekommt ist ein Armutszeugnis.
 
denk doch auch mal einer an die heulsusen von instandhalter ... wenn es in mehreren bausteinen umverdrahtet wird, müssen alle bausteine wieder in die cpu geladen werden und wer, wenn nicht der instandhalter, vergisst da gern mal einen baustein...

Bist du nicht auch einer ????:ROFLMAO:

Also ich hätte damit keine Probleme mit dem Umverdrahten

Und mal realistisch gesehen, wie oft geht den heute noch ein Eingang kaputt ???? Bei Ausgängen ist es klar, dass da hin und wieder einer den Geist aufgibt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich versteh das nicht, was ist daran so schwierig, mit "Gehe zur Verwendungstelle" oder mit "Umverdrahten" den defekten Eingang auf einen anderen Eingang zu legen? Das Umrangieren macht das Programm nur unübersichtlicher und ist für mich reine Recourcenverschwendung.
Ja, der Recourcenverbrauch ist natürlich höher. Und natürlich ist es nicht schlimm mit "Umverdrahten" den defekten Eingang auf einen anderen Eingang zu legen.
Ich kann nur aus meiner eigenen Erfahrung als ehemaliger Instanthalter sprechen, dass es sehr Wohl ein Unterschied ist wenn ich genau weis dass ich nur einen Baustein in die SPS übertragen muss, anstatt mehrer und ich nicht erst prüfen muss wieviel und welche.
Vor allem wenn ein ganzes Rudel Anlagenfahrer und der Produktionsleiter um mich rumhüpfen.:ROFLMAO:
Aber ich will hier natürlich nicht behaupten, dass die Rangiererei nun das Non plus Ultra ist, von der Sache her kann das ja jeder machen wie er will.:)
 
Aber ich will hier natürlich nicht behaupten, dass die Rangiererei nun das Non plus Ultra ist, von der Sache her kann das ja jeder machen wie er will.:)
100%ACK! Ich möchte halt keine Merkerschnittstellen und fertig. Meine heulsusigen Instandhalter auf Schicht haben es mir bereits gedankt! :ROFLMAO:
Meine Erfahrungen aus der Stahlindustrie sind die, daß weniger ein Eingang kaputt geht, sondern draussen die Peripherie abraucht... Und den defekten Näherungsschalter, Sensor ect. gilt es so schnell wie möglich zu finden. Das klappt halt besser mit Absolut-Adressierten Programmen ohne Merkerschnittstellen.

P.S: Ich wundere mich über diese kontroverse Diskussion, jeder nach seiner Fasson! (siehe Zitat OHGN...)

Gruß Approx
 
@Ralle: bezog sich nicht auf diese Geschichte - das hab ich gar nicht mitgelesen.

Ansonsten gilt m.E. generell: jeder Zugriff, der nicht im Querverweis auftaucht, ist schon mal verachtenswert. Insofern bin ich entschiedener Gegner von Pointeradressierung. Das gilt für mich bei jedem Pointerzugriff auf globale Elemente.

Dagegen kann ich einen Pointerzugriff auf lokale Variablen innerhalb der eigenen Instanz, gegebenenfalls auf eine UDT-Struktur, gut akzeptieren, besonders dann, wenn an leicht erkennbarer Stelle auf diese indirekte Adressierung hingewiesen wird.

Aber ich geb zu: meine oftmals einfach strukturierten Algorithmen verlangen maximal nach einem Indexzugriff auf eindimensionale Tabellen ...
 
...
Ansonsten gilt m.E. generell: jeder Zugriff, der nicht im Querverweis auftaucht, ist schon mal verachtenswert. Insofern bin ich entschiedener Gegner von Pointeradressierung. Das gilt für mich bei jedem Pointerzugriff auf globale Elemente.

Dagegen kann ich einen Pointerzugriff auf lokale Variablen innerhalb der eigenen Instanz, gegebenenfalls auf eine UDT-Struktur, gut akzeptieren, besonders dann, wenn an leicht erkennbarer Stelle auf diese indirekte Adressierung hingewiesen wird.

Aber ich geb zu: meine oftmals einfach strukturierten Algorithmen verlangen maximal nach einem Indexzugriff auf eindimensionale Tabellen ...

*ACK*

Hab einen neuen Kunden, die lesen über Pointer alle Eingänge vom ASI ein, und geben die über Pointer aus (Zwischengespeichert in einem DB). Den Ventilbaustein gibts nur einmal, und der zählt die Anzahl der Ventile durch, und greift über indirekte Adressierung auf den DB zu. Die schreiben zwar nicht direkt auf den E/A wie oben erwähnt, aber den weg über den DB find ich auch nicht besser.Und die wundern sich, das die Maschinen beim austausch gegen eine 317 schneller werden.

Und jetzt soll ich das für die Maschinen so übernehmen , da alle Maschinen von denen so laufen :sb7:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
100%ACK! Ich möchte halt keine Merkerschnittstellen und fertig. Meine heulsusigen Instandhalter auf Schicht haben es mir bereits gedankt! :ROFLMAO:
Meine Erfahrungen aus der Stahlindustrie sind die, daß weniger ein Eingang kaputt geht, sondern draussen die Peripherie abraucht... Und den defekten Näherungsschalter, Sensor ect. gilt es so schnell wie möglich zu finden. Das klappt halt besser mit Absolut-Adressierten Programmen ohne Merkerschnittstellen.

P.S: Ich wundere mich über diese kontroverse Diskussion, jeder nach seiner Fasson! (siehe Zitat OHGN...)

Gruß Approx

dafür gibts denn aber störmeldungen.
 
dafür gibts denn aber störmeldungen.

Ach ja? :rolleyes: Ich stelle mir gerade eine Störmeldung vor, die etwa so lauten könnte: "Bediener hat gedrückt, es passierte aber nix!" :confused:

Endlagen usw. kann man ja super überwachen, aber bei Befehlsgebern wird es dann schon schwieriger. :ROFLMAO:

Anm.: Die fetteste unserer Anlagen hat ca. 15.000 Meldungen (Alarm_8 ) im WinCC. Also Meldungen (auch Bedienmeldungen) existieren reichlich.

Gruß Approx:cool:
 
Zuletzt bearbeitet:
mal ein beispiel für ... na, wie soll ich sagen ... unsauber is da noch geschmeichelt ...
 

Anhänge

  • angst.JPG
    angst.JPG
    36,2 KB · Aufrufe: 181
mal ein beispiel für ... na, wie soll ich sagen ... unsauber is da noch geschmeichelt ...

In diesem Falle ja, aber !!! Es gibt z.Bsp. auch Global DB, die sind in jedem Programm identisch, weil die Hersteller seinen eigenen Standard hat. Da werden dann auch globale Zugriffe und IN-Var gemischt genutzt. Das spart kilometerlange IN-Listen bei den Bausteinaufrufen. Es hat halt alles zwei Seiten.
 
In diesem Falle ja, aber !!! Es gibt z.Bsp. auch Global DB, die sind in jedem Programm identisch, weil die Hersteller seinen eigenen Standard hat. Da werden dann auch globale Zugriffe und IN-Var gemischt genutzt. Das spart kilometerlange IN-Listen bei den Bausteinaufrufen. Es hat halt alles zwei Seiten.

die IN-Variablen werden alle samt mit globalen Adressen belegt, also Merker oder E/A´s ... man könnte sich in diesem Fall IMHO die Eingabe beim Bausteinaufruf sparen und gleich alles global adressieren ...

... hätte dazu schreiben sollen, dass der baustein nur einmal aufgerufen wird und die globalen Sachen darin garantiert nicht standardisiert sind - Gründe? ich weiß es einfach *kritischüberdenschreibtischzuseinemkollegenguckt*
 
Zuletzt bearbeitet:
Zurück
Oben