Step 7 Klärung FC-internes beschreiben einer IN-Variable

[MW]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

mir ist jetzt mal ein Code von einem Lieferanten unter gejubelt worden über den ich jetzt eine ganze Weile gegrübelt habe und immer noch keinen Sinn erkenne.
Vielleicht kann mir von euch jemand auf die Sprünge helfen.


In einem mehrfach verwendeten FC fand ich im ersten Netzwerk folgenden Code:

   AUF   DB   120  [COLOR=#ff0000]--> den DB gibt's auf der Steuerung, das Öffnen ist aber Sinnlos[/COLOR]
      L     #DW                 [COLOR=#006400]--> FC_IN REAL: beschalten mit Variable "DB120.DBD72"[/COLOR]
      T     #VALUE            -->[COLOR=#006400] FC_TEMP REAL: wird mit dem Wert der Variable aus DB120 beschrieben und im weiteren Code verwendet, ist OK [/COLOR]

Das der DB120 dort geöffnet wird hat in meinen Augen keinen Sinn, macht aber auch keine Probleme, richtig?

Auf diesen Code folgt folgender Abschnitt:

   AUF   DB   105  [COLOR=#ff0000]--> DB online nicht vorhanden[/COLOR]
      L     #ON   --> FC_IN REAL: beschalten mit fixem Wert
      T     #DW   --> FC_IN REAL: beschalten mit Variable aus DB120
      AUF   DB   115  --[COLOR=#ff0000]> DB online nicht vorhanden[/COLOR]
      L     #OFF  --> FC_IN REAL: beschalten mit fixem Wert
      T     #DW   --> FC_IN REAL: beschalten mit Variable aus DB120
      AUF   DB   107  [COLOR=#ff0000]--> DB online nicht vorhanden[/COLOR]
      L     #RSL  --> FC_IN REAL: beschalten mit fixem Wert
      T     #DW   --> FC_IN REAL: beschalten mit Variable aus DB120
      AUF   DB   117  [COLOR=#ff0000]--> DB online nicht vorhanden[/COLOR]
      L     #RTL   --> FC_IN REAL: beschalten mit fixem Wert
      T     #DW   --> FC_IN REAL: beschalten mit Variable aus DB120

Der Programmierer öffnet immer einen DB, liest dann aber einen Wert der dem FC übergeben wurde und transferiert diesen Wert wieder auf eine Eingangsvariable.
Da die DBs aber online nicht vorhanden sind gibt's immer einen OB121-Aufruf.
Für mich unklar sind dabei zwei Dinge:
- Das Öffnen des DB bringt doch rein gar nichts(außer das er im DB-Register steht) da im Anschluss eine Eingangsvariable geladen wird, richtig?
- Das Schreiben einer IN-Variable(an Schnittstelle fix eingetragen mit z.B. 0.0e+0) auf eine andere IN-Variable(an Schnittstelle steht dort ein Real-Wert aus DB120) ist doch ebenfalls Sinnfrei, richtig?


Die Variable #DW wird Übrigens im weiteren Verlauf des Bausteins nicht mehr verwendet.

 

[Wincctia]

Hallo Mw

wenn der Fc im Awl aufgerufen wird dann kannst du einen In beschreiben das hab ich schon gesehen dass das Funktioniert also beschrieben wird wie ein In Out. Würde das aber nicht unterschreiben könnte stark von der Abhängen und wenn der Fc im Fub Kop aufgerufen wird es eher nicht gehen weil der Compiler die Daten gerne auf Temp umlegt.
Das mit den auf DB ist ist sinnlos wenn du mich fragst aber wer weis was es hier wieder für Themen gibt.
Könntest du den Fc mal online Stellen?


Gruß Tia

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da gibt es bei FCs die Besonderheit, dass Parameter als Zeiger übergeben werden. Das funktioniert aber nur, wenn der Parameter M, E, A oder ein nicht vollqualifizierter DB-Zugriff ist.
D.h. wenn du als Parameter dann einen vollqualifizierten Zugriff DB120.DBD72 übergibst dann funktioniert das Schreiben nicht (weil der Zeiger dann auf den Temp-Bereich des aufrufenden Bausteins zeigt). Wenn du nur DBD72 übergibst und dann im FC vorher den DB120 öffnest, dann funktioniert das Schreiben.

Ich habe kürzlich ein Programm gesehen wo das genau so gemacht wurde und musste auch erstmal nachdenken was da wohl getrickst wurde. Das wurde wohl von einem S5-Programm so konvertiert, und wie mein Chef sagte wurde das früher bei der S5 viel so gemacht.

 

[Heinileini]

... und wie mein Chef sagte wurde das früher bei der S5 viel so gemacht.

Was wurde früher bei S5 viel so gemacht? Meinst Du Thomas bzw. meint Dein Chef damit die "nicht vollqualifizierten DB-Zugriffe"?
Das stimmt allerdings, denn "vollqualifizierte Zugriffe" - wie z.B. DB120.DBD72 - gab/gibt es in S5 nicht.

Das Öffnen vier verschiedener, online nicht vorhandener DBs und das Beschreiben ein und desselben DoppelWortes (getarnt als Wort!?) im zuvor erfolgreich geöffneten DB120 mit 4 verschiedenen Werten ist mit Sicherheit kein Trick, den man aus S5 nach S7 übernommen hat.
Da hat sich jemand austricksen lassen. Vielleicht sollte man nachforschen, warum die 4 DBs nicht vorhanden sind?

Gruss, Heinileini

 

[Thomas_v2.1]

Was wurde früher bei S5 viel so gemacht? Meinst Du Thomas bzw. meint Dein Chef damit die "nicht vollqualifizierten DB-Zugriffe"?

Nein, das Übergeben von Parametern mit z.B. DBW100, und im FC wurde dann immer ein bestimmter DB geöffnet auf den zugegriffen wurde. Da hatte er dann bestimmte Standard-DBs für Meldungen, Befehle usw. Mit den Möglichkeiten die die S5 damals bot stand da schon ein durchdachtes Konzept dahinter.

Nur muss man dann beim Konvertieren auf die S7 aufpassen. Wenn man dann meint, ok der DBW100 wird immer aus dem DB50 genommen, dann ändere ich doch ganz einfach alle Aufrufe in vollqualifiziert DB50.DBW100 damit ich auch ein vernünftiges Symbol und eine vernünftige Querverweisliste bekomme, dann funktionieren diese Bausteine nämlich nicht mehr.
Meiner Meinung nach sollte es in Step7 auch mindestens eine Warnung geben, wenn auf IN Parameter geschrieben wird. Das ahnt ja auch keiner, außer wenn man weiß dass IN-Parameter eben immer Zeiger sind, die bei vollqualifizierten Zugriffen in der S7 dann aber im Nirvana landen weil die Parameter eben nur einfache Pointer und kein Any sind.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was das mit dem Beschreiben der nicht vorhandenen DBs auf sich hat ist noch zu prüfen.
Wenn am Parameter nur DBDx angetragen ist, dann sollte es ja auch einen Systemfehler geben wegen Zugriff auf nicht vorhandenen DB.
Wenn dort aber DBx.DBDy angetragen ist, dann gibt es zwar keinen Fehler, aber die ursprünglich vorgesehene Funktionalität ist vermutlich nicht vorhanden.

 

[MW]

Vielleicht sollte man nachforschen, warum die 4 DBs nicht vorhanden sind?

Das die 4 DBs online nicht vorhanden sind kann ich mir nur so erklären, das der Programmierer diesen Baustein aus einem seiner anderen Projekte rüberkopiert hat um die Funktion(simple Grenzwertüberwachung) nutzen zu können. Offensichtlich hat er sich dabei aber seinen kopierten Baustein nicht angeschaut und nicht gesehen das dort einige DBs fehlen.

Selbst wenn er einen nicht vollqualifizierten DB-Zugriff angewendet hätte und die DBs online vorhanden wären, bleibt die Frage nach dem Sinn. Er kopiert jeden In-Parameter in einen extra DB, verwendet aber im weiteren Verlauf des Bausteins nur die In-Parameter(z.B. L #ON) direkt. Die In-Parameter stehen also in einem DB, aber werden nicht weiter verwendet, zumindest nicht in den Bausteinen die er auf unsere Steuerung kopiert hat.

Die Besonderheit mit der Parameterübergabe als Pointer bei FCs ist mir zwar bekannt, allerdings habe ich nicht daran gedacht das es dabei einen Unterschied zwischen vollqualifizierten und nicht-vollqualifizierten DB-Zugriffen gibt.
Ich bin mir recht sicher das der Programmierer auch schon zu S5-Zeiten unterwegs war und vermutlich seine Programme auf die S7 übertragen hat und mit seinem "alten" System einfach weiter gearbeitet hat.
Nur Blöd das er sein System nicht komplett übernommen hat, mal ganz davon abgesehen das ich diesen Programmierstil(FC-interes beschreiben von In-Parametern und schwerer nachvollziehbare nicht vollqualifizierte DB-Zugriffe) garnicht schön finde.

Ich werde jetzt mal zu sehen das ich diese "DB-Spielereien" aus den Bausteinen entferne.