Behinderungen symbolischer Programmierung - Wie umgehen ?

Zuviel Werbung?
-> Hier kostenlos registrieren
Wie ich schon erwähnte, hatte ich letztes Jahr die Ehre ein Graph7-Programm, daß immer mal nicht machte, was es sollte, in ein normales Schrittkettenprogramm umzuschreiben, bzw. neuzuschreiben. Dabei war natürlich erst einmal etwas Reengineering angesagt, um sich etwas Arbeit zu ersparen. Dabei stellte sich heraus, daß der verehrte Kollege seine globalen Daten so verteilte, daß er sie als Stat-Var in einigen FB deklarierte und dann am Anfang des FB diese Variablen per SFC20 umkopierte. Das ging ja noch, da wenigstens nachvollziehbar. Aber dabei ist er ja nicht geblieben. Meßdaten wurden munter hin- und herkopiert, was einmal klappt, geht ja auch woanders. Stat-Bits in FB wurden von außen (aus irgendeinem FC/FB) gesetzte bzw. gelöscht. Rezeptdaten wurden aus ProTool direkt in Stat-Var geschrieben. In einem solchen Gemenge, ist eine Fehlersuche fast schon Glückssache, daher kam ja der Entschluß des Auftraggebers, das Ganze neu zu schreiben.
Ok, kann ich jetzt nachvollziehen - dieses kopieren, besonders ohne Symbolzugriff finde ich auch sehr besch..... Das versuche ich auch nach Möglichkeit ganz zu lassen, oder wenn möglich so, dass die Parameterversorgung symbolisch geht - alles andere geht sehr schnell in die Hose, wenn man kleine Änderungen macht und nicht mehr erkennen kann, wie die Daten dahinein gekommen sind. Dennoch hat es nicht damit zu tun, dass Siemens es einem nicht ermöglicht, diese STAT-Variablen mit dem S7_m_c Attribut zu versorgen. Die IN- OUT und INOUT sind beim FB letztendlich auch im Instanz-DB an irgendswelchen Adressen gehalten und diese kann man mit dem S7_m_c versorgen. Vielleicht gibt es ja eine Erklärung, warum man das nicht zulässt - ich habe bisher nichts plausibles gehört und kann mir im Moment auch nichts vorstellen, warum das grundsätzlich nicht gehen sollte.
 
Und wenn du jetzt von aussen in den I-DB in einen Speicherbereich schreibst dann kann das kein Mensch nachvollziehen von wo das kommt. Wenn du aber IN- OUT- und INOUT-Variablen anlegst und diese hoffentlich auch nicht über den I-DB beschreibst sondern richtig beim Bausteinaufruf mit einem Wert von einem anderen Speicherbereich und den Speicherbereich dann einen schönen Namen/Kommentar gibts wie zb. von wo der Wert herkommt (Visualisierung) dann kann auch ein Betriebselektriker mit wenig Programmierkenntnisse nachvollziehen das dieser Wert aus der HMI kommt und nicht von Irgendeinem anderen Programmteil und er gleich bei einem Störfall in der HMI nachsehen kann und draufkommt das der Bediener nur einen Falschen Parameter/Wert eingegeben hat und nicht irgendwo ein Sensor oder sonstiges defekt ist.
godi

Irgendwie komme ich wohl aus einer ganz anderen Welt. Wenn ich in meinen Programmen (für Kläranlagen) alle IN und OUT Daten, mit denen die FBs arbeiten, über Aufrufparameter übergeben wollte, würde der OB1 etwa die Hälfte des Programms einnehmen. So an die 5000 Daten würden dort in schier unendlichen Parameterlisten auf dem Umweg über globale Datenbausteine umgeschaufelt werden. Das ist nicht das, was ich mir unter Übersichtlichkeit und Durchschaubarkeit vorstelle, die ihr ja auch als Grund angebt. Das ist, als ob sich eine ganze Stadt zum Nachrichten- und Warenaustausch auf dem Marktplatz treffen würde, damit keiner, auch kein Postbote, die Privatsphäre eines Anderen verletzen kann.

Wo welche Daten herkommen und wo sie hingehen, kann ich jederzeit aus dem Quelltext herauslesen. Und wenn jemand keine Quellen lesen kann, gibt es ja noch Querverweislisten. Aber im allgemeinen weiß ich auch ohne Nachsehen an der Art der Daten, woher sie kommen und wohin sie gehen. So wie ich weiß, daß die Brötchen vom Bäcker kommen und der Müll von der Müllabfuhr abgeholt wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
leider hab ich keine Erfahrung mit Anlagen wie Kläranlagen. Bei Maschinen habe ich festgestellt, dass sparsame Schnittstellen dazu geführt haben, dass die Funktionseinheiten in weniger, aber dafür größere Bausteine mündeten. Anfänglich erschienen mir endlose IN/OUT-Zuweisungen auch resourcenverbrauchend - inzwischen trägt diese Gliederung bei mir zur Überschaubarkeit des Programmes bei. Wohl deswegen, weil ich inzwischen anders strukturiere, um diese Schnittstellen klein zu halten.
 
Irgendwie komme ich wohl aus einer ganz anderen Welt. Wenn ich in meinen Programmen (für Kläranlagen) alle IN und OUT Daten, mit denen die FBs arbeiten, über Aufrufparameter übergeben wollte, würde der OB1 etwa die Hälfte des Programms einnehmen. So an die 5000 Daten würden dort in schier unendlichen Parameterlisten auf dem Umweg über globale Datenbausteine umgeschaufelt werden. Das ist nicht das, was ich mir unter Übersichtlichkeit und Durchschaubarkeit vorstelle, die ihr ja auch als Grund angebt. Das ist, als ob sich eine ganze Stadt zum Nachrichten- und Warenaustausch auf dem Marktplatz treffen würde, damit keiner, auch kein Postbote, die Privatsphäre eines Anderen verletzen kann.

Wo welche Daten herkommen und wo sie hingehen, kann ich jederzeit aus dem Quelltext herauslesen. Und wenn jemand keine Quellen lesen kann, gibt es ja noch Querverweislisten. Aber im allgemeinen weiß ich auch ohne Nachsehen an der Art der Daten, woher sie kommen und wohin sie gehen. So wie ich weiß, daß die Brötchen vom Bäcker kommen und der Müll von der Müllabfuhr abgeholt wird.

Schön, daß du so ein toller Hecht bist, das mit den Referenzdaten und deinen hin- und herkopierten statischen Variablen aus den Instanz-DB darfst du gerne zeigen. Und dein Nachfolger (du wirst ja nicht ewig Gülle rühren, sondern irgendwann mal was anderes machen, nehm ich mal einfach an) wird sich sicher auch ganz prima zurechtfinden. Ich denke mal du hast ne 1A-Doku bereitliegen (Die würde mich im übrigen ernsthaft interessieren), denn damit habe ich immer so meine Probleme. Aber ich bin nun doch froh, daß ich nichts mir Kläranlagen am Hut habe. Man muß nicht die gesamten Daten per IN oder OUT übergeben, wo steht das? Man kann auch DB als Global deklarieren und dort Daten liegen haben, da ist nichts ehrenrühriges dran.
 
Irgendwie komme ich wohl aus einer ganz anderen Welt. Wenn ich in meinen Programmen (für Kläranlagen) alle IN und OUT Daten, mit denen die FBs arbeiten, über Aufrufparameter übergeben wollte, würde der OB1 etwa die Hälfte des Programms einnehmen. So an die 5000 Daten würden dort in schier unendlichen Parameterlisten auf dem Umweg über globale Datenbausteine umgeschaufelt werden. Das ist nicht das, was ich mir unter Übersichtlichkeit und Durchschaubarkeit vorstelle, die ihr ja auch als Grund angebt. Das ist, als ob sich eine ganze Stadt zum Nachrichten- und Warenaustausch auf dem Marktplatz treffen würde, damit keiner, auch kein Postbote, die Privatsphäre eines Anderen verletzen kann.

Wo welche Daten herkommen und wo sie hingehen, kann ich jederzeit aus dem Quelltext herauslesen. Und wenn jemand keine Quellen lesen kann, gibt es ja noch Querverweislisten. Aber im allgemeinen weiß ich auch ohne Nachsehen an der Art der Daten, woher sie kommen und wohin sie gehen. So wie ich weiß, daß die Brötchen vom Bäcker kommen und der Müll von der Müllabfuhr abgeholt wird.

Wenn du 5000Werte an einem FB übergeben musst dann währe es ja sowieso sinnvoller wenn du Globale DB's (Wie Ralle schon sagt) verwendest. Da kannst du dann überall Problemlos darauf zugreifen.

Ich stell mir grad eine FB - Schnittstelle mit 5000 Variablen vor! Sicher einfach zum Handhaben! :rolleyes:

godi
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@godi
Das bezog sich auf die Aufrufe der FBs im OB1. Die 5000 sind eine grobe Schätzung, vielleicht sind's in Wirklichkeit beispielsweise nur 3000. In 15 (Multi)Instanz-DBs, mit 27 FBs.

Was ist an einem globalen DB besser als an einem Instanz-DB , wenn man mal vom Dogma absieht? Ich sehe einen InstanzDB nicht als einen DB der einem FB gehört, sondern umgekehrt einen FB als einen Baustein, der sich um Daten eines bestimmten DBs kümmert. So deklarier ich eher mal einen DB über einen FB , um dann später vielleicht festzustellen, daß er gar keinen Code braucht. Aber wenn etwas zu tun ist, ist schon alles bereit dafür und ich muß nichts umdeklarieren von UDT auf FB.
 
...
So deklarier ich eher mal einen DB über einen FB , um dann später vielleicht festzustellen, daß er gar keinen Code braucht.
...

wenn er dann Code braucht, kannst ja immer noch den Global-DB mit einem FC bearbeiten. Und auch, wenn Siemens das oft so vormacht, übergibst dem FC NICHT die DB-Nummer, sondern den Pointer auf den DB ...

Aber ich vermute: Du programmierst auch gerne KOP, weil man da so schön mit dem Finger die Linien verfolgen kann ;)
 
Was ist an einem globalen DB besser als an einem Instanz-DB , wenn man mal vom Dogma absieht? Ich sehe einen InstanzDB nicht als einen DB der einem FB gehört, sondern umgekehrt einen FB als einen Baustein, der sich um Daten eines bestimmten DBs kümmert.

Ja, du zäumst das Pferd halt anders auf als die anderen kleinen Kinder. Man kann eine Flasche Schnaps auch Milch nennen und dann meinen, gesund zu leben.

1. Ein globaler DB ändert sich nicht, wenn du die Schnittstellen deinens FB änderst.

2. Ein globaler DB bleibt wenigstens ansatzweise lesbar (So er nicht zu viel mit UDT und Strukturen arbeitet), wenn jemand das Projekt "verbummelt" oder zerschießt und ein anderer Programmierer nur einen AG-Abzug zur Verfügug hat (im IDB steht dann z.Bsp. STAT0.STAT1.STAT101)

Bsp. toter IDB:

Code:
DATA_BLOCK DB 161
VERSION : 0.0

 FB 161
BEGIN
   IN0 := FALSE; 
   IN1 := FALSE; 
   IN2 := FALSE; 
   IN3 := FALSE; 
   IN4 := FALSE; 
   OUT5 := FALSE; 
   OUT6 := TRUE; 
   OUT7 := FALSE; 
   OUT8 := FALSE; 
   STAT9.STAT10 := FALSE; 
   STAT9.STAT11 := TRUE; 
   STAT9.STAT12 := TRUE; 
   STAT13 := TRUE; 
   STAT14 := FALSE; 
   STAT15 := FALSE; 
   STAT16 := TRUE; 
   STAT17.STAT18 := FALSE; 
   STAT17.STAT19 := FALSE; 
   STAT17.STAT20 := FALSE; 
   STAT17.STAT21 := TRUE; 
   STAT17.STAT22 := 0; 
   STAT17.STAT23 := DW#16#0; 
   STAT17.STAT24 := DW#16#0; 
   STAT17.STAT25 := DW#16#0; 
   STAT26.STAT27 := FALSE; 
   STAT26.STAT28 := FALSE; 
   STAT26.STAT29 := FALSE; 
   STAT26.STAT30 := FALSE; 
   STAT26.STAT31 := 10; 
   STAT26.STAT32 := DW#16#7000000; 
   STAT26.STAT33 := DW#16#7000000; 
   STAT26.STAT34 := DW#16#4000000; 
   STAT35.STAT36 := FALSE; 
   STAT35.STAT37 := FALSE; 
   STAT35.STAT38 := FALSE; 
   STAT35.STAT39 := FALSE; 
   STAT35.STAT40 := 11; 
   STAT35.STAT41 := DW#16#1000000; 
   STAT35.STAT42 := DW#16#0; 
   STAT35.STAT43 := DW#16#0; 
   STAT44.STAT45 := FALSE; 
   STAT44.STAT46 := FALSE; 
   STAT44.STAT47 := FALSE; 
   STAT44.STAT48 := FALSE; 
   STAT44.STAT49 := 15; 
   STAT44.STAT50 := DW#16#F000000; 
   STAT44.STAT51 := DW#16#F000000; 
   STAT44.STAT52 := DW#16#0; 
   STAT53.STAT54 := TRUE; 
   STAT53.STAT55 := FALSE; 
   STAT53.STAT56 := FALSE; 
   STAT53.STAT57 := FALSE; 
   STAT53.STAT58 := 200; 
   STAT53.STAT59 := DW#16#1000000; 
   STAT53.STAT60 := DW#16#1000000; 
   STAT53.STAT61 := DW#16#0; 
   STAT62.STAT63 := FALSE; 
   STAT62.STAT64 := FALSE; 
   STAT62.STAT65 := FALSE; 
   STAT62.STAT66 := FALSE; 
   STAT62.STAT67 := 915; 
   STAT62.STAT68 := DW#16#3000000; 
   STAT62.STAT69 := DW#16#3000000; 
   STAT62.STAT70 := DW#16#0; 
   STAT71.STAT72 := FALSE; 

...

   STAT706.STAT730 := FALSE; 
   STAT706.STAT731 := FALSE; 
   STAT706.STAT732 := FALSE; 
   STAT706.STAT733 := FALSE; 
   STAT706.STAT734 := B#16#0; 
   STAT706.STAT735 := B#16#0; 
   STAT706.STAT736 := DW#16#0; 
   STAT737[0] := B#16#2; 
   STAT737[1] := B#16#4; 
   STAT737[2] := B#16#0; 
   STAT737[3] := B#16#0; 
   STAT737[4] := B#16#0; 
   STAT737[5] := B#16#0; 
   STAT737[6] := B#16#0; 
   STAT738[0] := B#16#1; 
   STAT738[1] := B#16#11; 
   STAT738[2] := B#16#5; 
   STAT738[3] := B#16#0; 
   STAT738[4] := B#16#0; 
   STAT738[5] := B#16#0; 
   STAT738[6] := B#16#0; 
   STAT739[0] := B#16#1; 
   STAT739[1] := B#16#11; 
   STAT739[2] := B#16#0; 
   STAT739[3] := B#16#0; 
   STAT739[4] := B#16#0; 
   STAT740[0] := B#16#1; 
   STAT740[1] := B#16#0; 
   STAT740[2] := B#16#10; 
   STAT740[3] := B#16#0; 
   STAT740[4] := B#16#0; 
   STAT741[0] := B#16#1; 
   STAT741[1] := B#16#0; 
   STAT741[2] := B#16#0; 
   STAT741[3] := B#16#0; 
   STAT741[4] := B#16#0; 
   STAT742[0] := B#16#1; 
   STAT742[1] := B#16#2; 
   STAT742[2] := B#16#0; 
   STAT742[3] := B#16#0; 
   STAT742[4] := B#16#0; 
   STAT743[0] := B#16#2; 
   STAT743[1] := B#16#11; 
   STAT743[2] := B#16#0; 
   STAT743[3] := B#16#0; 
   STAT743[4] := B#16#0; 
   STAT744[0] := B#16#1; 
   STAT744[1] := B#16#7; 
   STAT744[2] := B#16#0; 
   STAT744[3] := B#16#0; 
   STAT744[4] := B#16#0; 
   STAT744[5] := B#16#0; 
   STAT744[6] := B#16#0; 
   STAT744[7] := B#16#0; 
   STAT744[8] := B#16#0; 
   STAT744[9] := B#16#0; 
   STAT744[10] := B#16#0; 
   STAT744[11] := B#16#0; 
   STAT744[12] := B#16#0; 
   STAT744[13] := B#16#0; 
   STAT744[14] := B#16#0; 
   STAT744[15] := B#16#0; 
   STAT744[16] := B#16#0; 
   STAT744[17] := B#16#0; 
   STAT744[18] := B#16#0; 
   STAT745[0] := B#16#2; 
   STAT745[1] := B#16#11; 
   STAT745[2] := B#16#10; 
   STAT745[3] := B#16#11; 
   STAT745[4] := B#16#0; 
   STAT745[5] := B#16#0; 
  
...

   STAT820.STAT833 := FALSE; 
   STAT820.STAT834 := FALSE; 
   STAT820.STAT835 := FALSE; 
   STAT820.STAT836 := FALSE; 
   STAT837 := DW#16#940; 
   STAT838 := DW#16#1E90; 
   STAT839 := DW#16#1E90; 
   STAT840 := DW#16#1DF0; 
   STAT841 := DW#16#1D50; 
   STAT842 := DW#16#84000000; 
   STAT843 := DW#16#A100A1; 
   STAT844 := W#16#5; 
   STAT845 := W#16#0; 
   STAT846 := DW#16#6000002F; 
   STAT847 := DW#16#6000002E; 
   STAT848 := DW#16#1C20; 
   STAT849[0] := FALSE; 
   STAT849[1] := FALSE; 
   STAT849[2] := FALSE; 
   STAT849[3] := FALSE; 
   STAT849[4] := FALSE; 
   STAT849[5] := FALSE; 
   STAT849[6] := FALSE; 
   STAT849[7] := FALSE; 
   STAT849[8] := FALSE; 
   STAT849[9] := FALSE; 
   STAT849[10] := FALSE; 

...

   STAT884.STAT897 := FALSE; 
   STAT884.STAT898 := FALSE; 
   STAT884.STAT899 := FALSE; 
   STAT900 := B#16#34; 
   STAT901 := B#16#34; 
   STAT902 := B#16#37; 
   STAT903 := B#16#47; 
END_DATA_BLOCK
Ein IDB ist schneller zerschossen, als man glaube mag, einen Änderung des FB ohne "Neuerzeugen" des IDB und peng.

3. Zugriffe auf einen globalen DB (lesen und schreiben) kann man in der Referenzliste finden, solange nicht mit indirekter Adressierung und SFC20 gearbeitet wird. Im FB des IDB wird mit dem internen Symol gearbeitet, außerhalb des eigenen FB mit der symolischen Adresse, der absoluten adresse, indirekter Adressierung oder SFC20. Man kann keinen Zusammenhanf zwischen der Variablen im eigenen FB und der gleichen Variablen im "Fremd"-FB/FC herstellen.

4. reicht erstmal.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
wenn er dann Code braucht, kannst ja immer noch den Global-DB mit einem FC bearbeiten.

Ob du einen DB mit einem FC oder als Instanz-DB mit einem zugehörigen FB bearbeitest, ist nur bei absoluter Adressierung kein großer Unterschied.
Bei symbolischer Adressierung muß im FC jedesmal der komplette globale Name angegeben werden, zB "DSonstwas".irgendwas, während du das im FB einfach mit #irgendwas ansprechen kannst. Das ist nicht nur bequemer und leichter lesbar, sondern auch im Maschinencode kürzer und schneller, also effizienter.



Aber ich vermute: Du programmierst auch gerne KOP, weil man da so schön mit dem Finger die Linien verfolgen kann ;)

Wie kommst du denn da drauf? Ich bevorzuge zur Programmierung reine Texte. KOP, FUP oder Graph ist was nettes für'n Kindergarten und so praktisch wie Dreiradfahren.
 
Ja, du zäumst das Pferd halt anders auf als die anderen kleinen Kinder.

Das mag sein, ich weiß ja garnicht, wie die anderen kleinen Kinder das machen. Und ich bezweifle inzwischen, daß die zu zäumenden Viecher sich ähnlich sind. Die Probleme, die bei dir im Vordergrund stehen, hab ich einfach nicht, dafür andere, die bei dir keine Rolle zu spielen scheinen. Für dich scheint ein Datenbaustein so etwas wie ein Schatzkästchen zu sein, dessen Inhalt geschützt und bewahrt werden muß. Für mich ist er wie ein Flußbett, wo die Daten rein und raus fließen. Was soll daran zerschossen werden, wenn er eh immer wieder mit neuen Daten gefüttert wird, von der Peripherie, vom PC oder von anderen SPSen.

Damit wir nicht so völlig aneinander vorbeireden, hier ein Beipiel für einen OB1 von mir :
Code:
BEGIN
NETWORK
TITLE = Init

CALL "FCInitGlobal" ;   // Initialisieren Globaler Variablen,Impulse,Takte

SET; S "KeinStoer";

NETWORK
TITLE = Daten holen

CALL "FCDigEin" ;        // Digitale Eingänge verteilen
CALL "FCAnaEin" ;        // Analoge Eingänge einlesen

CALL "FBComm","DComm";   // Kommunikation mit anderen SPSen

CALL "FCGeraeteListe";   // Vergeben von Gerätenummern

CALL "FBGVorgaben","DGVorgaben";// Geräte Vorgaben vom PC verteilen

CALL "FBvonMiras","DVonMiras";  // Daten von MIRAS (Steuerungs-PC) verteilen
CALL "FBvonAWFS","DvonAWFS";    // Daten von SPS Abwasserfeinsiebung verteilen
CALL "FBvonABG","DvonABG";      // Daten von SPS Altes Betriebsgebäude  (Belebung) verteilen

NETWORK
TITLE = Gerätefunktionen

CALL "FBPumpSt","DPumpSt";       // Pumpstation
CALL "FBALeucht","DALeucht";     // Außenbeleuchtung
CALL "FBSonst","DSonst";     // Sonstige Funktionen

NETWORK
TITLE = Daten weitergeben

CALL "FBanMiras","DanMiras";     // Daten an MIRAS (Steuerungs-PC) sammeln
CALL "FBanAWFS","DanAWFS";      // Daten an SPS Abwasserfeinsiebung sammeln
CALL "FBanABG","DanABG";        // Daten an SPS Altes Betriebsgebäude  (Belebung) sammeln

CALL "FCDigAus" ;                // Digitale Ausgänge ansteuern
CALL "FCAnaAus" ;         // Analoge Ausgänge beliefern

UN "KeinStoer"; ="SammStoer";
Ich hoffe, daß daraus deutlich wird, wie sich aus den notwendigen Datenflüssen die Aufgaben der FBs ergeben. Und daß die DBs nicht einfach nur Anhängsel der FBs sind.

Ein IDB ist schneller zerschossen, als man glaube mag, einen Änderung des FB ohne "Neuerzeugen" des IDB und peng.

Da ich wie schon erwähnt mit Quellen arbeite, wird beim Übersetzen gleichzeitig mit dem neuen FB auch immer ein neuer DB erzeugt.

3. Zugriffe auf einen globalen DB (lesen und schreiben) kann man in der Referenzliste finden, solange nicht mit indirekter Adressierung und SFC20 gearbeitet wird. Im FB des IDB wird mit dem internen Symol gearbeitet, außerhalb des eigenen FB mit der symolischen Adresse, der absoluten adresse, indirekter Adressierung oder SFC20. Man kann keinen Zusammenhanf zwischen der Variablen im eigenen FB und der gleichen Variablen im "Fremd"-FB/FC herstellen.

Die Zugriffe von außen auf meine Instanz-DBs werden in der Querverweisliste genauso aufgeführt wie auf globale DBs. Das interne Symbol im FB ist dasselbe Symbol wie von extern, nur daß der "DBName". durch # ersetzt wird.
 
Für dich scheint ein Datenbaustein so etwas wie ein Schatzkästchen zu sein, dessen Inhalt geschützt und bewahrt werden muß.

Fast richtig erkannt, das gilt tatsächlich für den Instanz-DB, nicht aber für globale DB, das sagen doch schon die Namen. Das du das anders auslegtst, macht es nicht korrekter.

Wenn du also Programmänderungen durchführen mußt, sind jedesmal alle deine Daten in der SPS hinüber? Denn ein sich ändernder IDB zwingt ja zum neuen Übertragen in die SPS. Da die Größe (teilweise reicht schon der Zeitstempel) des IDB sich geändert hat, werden alle "alten" Daten ja durch den neuen DB überschrieben. Das würde ich mir tatsäclich nicht antun wollen, genau das ist ja eigentlich der Vorteil der S7, daß man im laufenden Prozeß ändern kann. Ich denke noch mit Schaudern an einige andere Steuerungen, die einem beim Übertragen zum Stop zwingen. Übrigens einer der Gründe für mich, recht sparsam mit FB und IDB und schon gar mit all zu ausufernden Multiinstanzen umzugehen. Es mag einige Leute geben, die nur mit Quellen arbeiten (kannte bisher noch keinen), aber m.E. gibt man damit einige der wenigen halbwegs durchdachten Errungenschaft von Step7 auf.

Aber ich seh schon, wir kommen da eh auf keinen gemeinsamen Nenner. Prinzipiell ist mir das egal, da ich nicht in deiner Branche tätig bin, ich würde deine Programme wohl besser nicht anfassen, da ich dann regelmäßig am hochgehen wäre, wetten :ROFLMAO:.

Deshalb für mich nun, Thema beendet, werde glücklich ;).
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Ob du einen DB mit einem FC oder als Instanz-DB mit einem zugehörigen FB bearbeitest, ist nur bei absoluter Adressierung kein großer Unterschied.
Bei symbolischer Adressierung muß im FC jedesmal der komplette globale Name angegeben werden, zB "DSonstwas".irgendwas, während du das im FB einfach mit #irgendwas ansprechen kannst. Das ist nicht nur bequemer und leichter lesbar, sondern auch im Maschinencode kürzer und schneller, also effizienter.
Wie kann es dann passieren, dass ein DB ohne zugehörigem Code entstehen kann? siehe:
So deklarier ich eher mal einen DB über einen FB , um dann später vielleicht festzustellen, daß er gar keinen Code braucht.

... Ich bevorzuge zur Programmierung reine Texte. KOP, FUP oder Graph ist was nettes für'n Kindergarten und so praktisch wie Dreiradfahren.
wollte Dich nur mal testen :p

Zu Deinem OB1: wenn ich da lese
Code:
CALL "FCDigEin" ;
läuft mir schon ein Schauer über den Rücken. Das sehen zwar andere Kollegen im Forum hier anders, aber genau diese Rangiererei würde ich an die Schnittstelle eines FB legen. Und wenn
Code:
CALL "FBPumpSt","DPumpSt";       // Pumpstation
CALL "FBALeucht","DALeucht";     // Außenbeleuchtung
nichts miteinander zu tun haben, kann man beide vollständig kapseln. Oder geht bei Pumpstation Störung automatisch die Aussenbeleuchtung an?
 
Code:
CALL "FBALeucht","DALeucht";     // Außenbeleuchtung
nichts miteinander zu tun haben, kann man beide vollständig kapseln. Oder geht bei Pumpstation Störung automatisch die Aussenbeleuchtung an?

Tja, manche können eben kapseln und abstrahieren und andere nicht.


Die Folgen obiger Vorgehensweise sind oft "duplizierter Code" oder auch "copy&paste"-Programmierung. Der Nachfolger der Kläranlagenprogramme langt garantiert ins Weiche:rolleyes:
 
Fast richtig erkannt, das gilt tatsächlich für den Instanz-DB, nicht aber für globale DB, das sagen doch schon die Namen. Das du das anders auslegtst, macht es nicht korrekter.

Instanz heißt soviel wie Exemplar, also ein konkretes Beispiel eines allgemeinen Schemas. Das Schema ist in diesem Fall eine Struktur, die in einem FB deklariert wird. Global sind Instanz-DBs auch, man kann von überall darauf zugreifen, auch wenn du meinst, daß man es nicht tun sollte.

Ein Instanz-DB hat dadurch, daß er die Struktur von einem FB übernimmt, die wiederum Strukturen von anderen FBs enthalten kann, den Vorteil, daß diese FBs besonders einfach darauf zugreifen können. Nachteile hat er nicht, es sei denn, man macht sich welche. Deshalb konzeptiere ich fast alle DBs als FB-Instanzen.

Die Frage nach der Unersetzbarkeit von Daten ist davon völlig unabhängig, wobei es dir natürlich freisteht, nur unersetzliche Daten in Instanz-DBs unterzubringen. Die Daten, mit denen ich zu tun habe, werden meist sowieso ständig erneuert.



Wenn du also Programmänderungen durchführen mußt, sind jedesmal alle deine Daten in der SPS hinüber? Denn ein sich ändernder IDB zwingt ja zum neuen Übertragen in die SPS. Da die Größe (teilweise reicht schon der Zeitstempel) des IDB sich geändert hat, werden alle "alten" Daten ja durch den neuen DB überschrieben. Das würde ich mir tatsäclich nicht antun wollen, genau das ist ja eigentlich der Vorteil der S7, daß man im laufenden Prozeß ändern kann. Ich denke noch mit Schaudern an einige andere Steuerungen, die einem beim Übertragen zum Stop zwingen.
Die meisten meiner Daten sind in jedem Zyklus hinüber, weil sie von neuen Daten (die teilweise dieselben wie alten sind) überschrieben werden. Die wertvolleren Vorgaben- und Einstellungsdaten kommen vom PC und werden dort auf der Festplatte gespeichert.

Bei Programmänderungen kommt es selten vor, daß ich die Datenbausteine übertragen muß, weil sich an der Struktur der FBs/DBs selten etwas grundlegendes ändert. Ich plane immer gleich ein paar Reservevariablen mit ein, so daß sich außer Namen selbst dann nichts ändert, wenn ich neue Variablen brauche. Alles Alte bleibt seinem Platz, nur wo sich vorher nichts tat, tut sich jetzt etwas neues. Meistens geht es ganz ohne Stop und falls doch, ist es in meiner Branche auch nicht so dramatisch.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Zu Deinem OB1: wenn ich da lese
Code:
CALL "FCDigEin" ;
läuft mir schon ein Schauer über den Rücken. Das sehen zwar andere Kollegen im Forum hier anders, aber genau diese Rangiererei würde ich an die Schnittstelle eines FB legen.

Das kann man vielleicht bei 3 oder 4 Eingänge pro FB machen. Bei den Datenmengen mit denen ich zu tun habe, wäre das eine völlige Überladung und damit Unüberschaubarkeit des OB1.(siehe früheren Beitrag von mir in diesem Thread.)

Den Zugriff auf Ein- und Ausgänge auf dafür spezielle FCs zu beschränken, bringt eine Menge Vorteile. Gut sortiert hab ich den Überblick, wohin die Eingänge gehen und wovon die Ausgänge angesteuert werden. Alle anderen Bausteine bleiben unhabängig von der Peripherie, sind leicht wiederverwertbar und auszutesten. Nachteile hab ich bis jetzt noch keine erlebt, wenn ihr welche seht, müßt ihr es schon erklären.

Und wenn
Code:
CALL "FBPumpSt","DPumpSt";       // Pumpstation
CALL "FBALeucht","DALeucht";     // Außenbeleuchtung
nichts miteinander zu tun haben, kann man beide vollständig kapseln. Oder geht bei Pumpstation Störung automatisch die Aussenbeleuchtung an?

Die Pumpstation braucht aber die Daten der Eingänge vom FCDigEin, Meßwerte vom FCAnaEin, Vorgaben vom PC usw. Wenn ich sie davon abkapseln würde, könnte ich mir auch das ganze Programm sparen. Es geht um notwendige Flüsse von Daten, nicht um stehende Tümpel oder Pfützen.
 
Zurück
Oben