Label interessantes nicht nachvollziehbares Verhalten

[vierlagig]

Zuviel Werbung?
-> Hier kostenlos registrieren

Guten Abend,

ist es nicht so, dass bei jedem neuem Bausteinaufruf die Lokaldaten neu beschrieben, bzw. verwendet werden können?
D.h: innerhalb eines Baustein's kann du Lx.x beliebig zuweisen und innerhalb abfragen.

Probleme entstehen bei:

Kolloision: bei einem Interrupt-Aufruf;


Oder: Adressierung? (was geschieht in den FC's)
sind diese multiinstanzfähig?
speicherindirekte Adressierung
registerindirekte Adressierung
Wird das AR2 gerettet? ; bzw. verwendet? (innerhalb der Bausteine)

Quintessenz: wenn das AR2 verändert wird, und nicht wiedergergestellt sind die Lokal-Stacks versaut. (Lx.x)

Guta Nacht
jb

deine bedenken sind

a) richtig
b) irrelevant

zu b) nach der bearbeitung des bausteins werden die lokaldaten durch den OUT oder IN/out neu initialisiert und müßten (theoretisch) einfach weiterverarbeitet werden können.

 

[vollmi]

Hallo René,
mich würden jetzt mal zwei Punkte interessieren:
1. Bei den Dutzend male, bei denen es geht, werden da auch Lokaldaten verwendet?
2. Ist der Ausgang des FB ein OUT oder ein IN/OUT?

Jap. Ich benutze die direkte Lokaldatenadressierung eigentlich als Labels. Also einfach um von einem Ausgang zum nächsten Eingang eines FBs zu verweisen. Ohne umständlich jedesmal jede Variable zu deklarieren.

Der Ausgang ist der Rückgabewert der Funktion

Ich merke grad ich hab immer von aufgerufenen FBs gesprochen sind aber sowohl FBs wie auch FCs in diesem Problemfall waren nur FCs beteiligt.

FUNCTION X_Y: REAL
(*Umwandlungsoperation*)
TITLE = 'REAL scalierung von X nach Y'
VERSION : '1.0'
KNOW_HOW_PROTECT
AUTHOR  : vor
NAME    : X_Y
FAMILY  : data

(*X umskalieren nach Y*)
(*X1 nach Y1, X2 nach X2, X wird in Bereichen X1 und X2 begrenzt*)
(*Negative sowie Positive Lineare und Werte sind erlaubt*)
{S7_tasklist:='false';
 S7_blockview:='small'}

VAR_INPUT
   X: REAL; 
  X1: REAL;
  X2: REAL;
  Y1: REAL;
  Y2: REAL;
END_VAR

VAR_TEMP
 LIM_X_UG: REAL;
 LIM_X_OG: REAL;
 LIMIT_R: REAL;
 END_VAR

(*Eingang X wird Limitiert*)
 BEGIN
  IF X1 < X2 THEN
     LIM_X_UG:= X1;
     LIM_X_OG:= X2;
  ELSIF X2 < X1 THEN 
     LIM_X_UG:= X2;
     LIM_X_OG:= X1;
  END_IF;   

(*Eingang X wird Limitiert*)
LIMIT_R:=LIMIT(Mn:=LIM_X_UG, IN:=X, Mx:=LIM_X_OG); 

(*Umrechnung des limitierten X Wertes*)
X_Y:=((Y2-Y1)/(X2-X1)*LIMIT_R+(Y2-(Y2-Y1)/(X2-X1)*X2));
END_FUNCTION

Im Netzwerk hat das dann so ausgesehen

      CALL  "X_Y"
       X      :=LD10
       X1     :=0.000000e+000
       X2     :=1.000000e+002
       Y1     :=0.000000e+000
       Y2     :=2.700000e+004
       RET_VAL:=LD0


      CALL  "PAW_OUT"
       IN     :=LD0
       RET_VAL:="PAW352"
       INT_OUT:=LW20

Der IN des PAW_OUT ist übrigens auch ein VAR_IN

mfG René

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Dein Problem ist vielleicht gar kein Step7-Problem?

Hallo vollmi,

kann es sein, daß Du, als Du das beschriebene Problem hattest, schlicht durch einen Tippfehler das falsche LD
benutzt hast?
Im Eröffnungsposting schreibst Du, der FB2 hat LD0 als IN und LD10 als OUT.
In Deinem Programmcode in #22 hat der FC "X_Y" LD10 als IN und LD0 als OUT.


Übrigens sind Deine Bausteine in #22 keine FB (wie im Eröffnungsposting behauptet), sondern FC.
Wenn Du hier qualifizierte Antworten zu komplizierten Problemen bekommen willst, dann solltest Du Dein Problem
auch EXAKT beschreiben.

Deine Beiträge hier und Dein Programm zeigen, daß Du offensichtlich nicht allzu viel Wert auf Exaktheit legst.
Das geht bei der Begriffswahl los (LABEL ist die Bezeichnung für eine Sprungmarke und nicht für eine Variable),
setzt sich bei Flüchtigkeitsfehlern in Kommentaren fort ("X1 nach Y1, X2 nach X2"; was sind "Negative sowie
Positive Lineare" ?, hat aber keinen Einfluß auf das Programm) und geht sogar weiter in nicht exaktem Programmcode:

(*Eingang X wird Limitiert*)
 BEGIN
  IF X1 < X2 THEN
     LIM_X_UG:= X1;
     LIM_X_OG:= X2;
  ELSIF X2 < X1 THEN 
     LIM_X_UG:= X2;
     LIM_X_OG:= X1;
  END_IF;

Die Fallunterscheidung ist nicht korrekt bzw. nicht vollständig.
Wenn X1=X2 ist, dann bekommen LIM_X_UG und LIM_X_OG keine Zuweisung.
(Klar, Du kannst nun gegenhalten: "Das kommt NIE vor, daß X1=X2 ist".)

Aber Hauptsache, der simple Baustein ist KNOW_HOW_PROTECT. Dann sieht ja niemand diese Schlampereien.

Jap. Ich benutze die direkte Lokaldatenadressierung eigentlich als Labels. Also einfach um von einem Ausgang zum
nächsten Eingang eines FBs zu verweisen. Ohne umständlich jedesmal jede Variable zu deklarieren.

Das ordentliche Deklarieren der verwendeten Lokaldaten ist nicht umständlich, sondern dauert nur ein paar Sekunden!
Dann sollte es für Step7 auch kein Problem sein, die von Dir verwendeten Lokaldaten exakt zu erkennen und nicht für
interne Zwecke zu verwenden. Die Step7-Editor-Warnung "Die Lokaldaten werden schon absolut verwendet ..." ist
nicht als allgemeine Belästigung des Programmierers gedacht, sondern gibt den Hinweis, daß die undeklarierte
Verwendung der Lokaldaten mit der verborgenen MC7-internen Verwendung der Lokaldaten kollidiert.

Das erste was ich ändern würde:
Keine Zugriffe auf LD ... sondern Lokaldaten symbolisch deklarieren und die verwenden.

*ACK*

Falls der Code mit den CALLs der FB (FC) im OB1 steht: LD0 und LD10 sind hier schon verwendet.
Wenn Du den ursprünglichen Inhalt der OB1-Lokaldaten nicht brauchst, dann hat Deine unkonventionelle absolute
Verwendung der Lokaldaten keinen Einfluß auf Dein Programm. Aber es ist einfach nur "quick and dirty".

Der Programmierer, der später mal Änderungen an Deinen Programmen vornehmen soll, der kann mir jetzt schon leid tun.

Gruß
Harald

 

[vollmi]

kann es sein, daß Du, als Du das beschriebene Problem hattest, schlicht durch einen Tippfehler das falsche LD benutzt hast?

Nein ich hab das nur nachher diverse male umgebogen um den Fehler reproduzieren zu könne. Ohne Erfolg.

Deine Beiträge hier und Dein Programm zeigen, daß Du offensichtlich nicht allzu viel Wert auf Exaktheit legst.
Das geht bei der Begriffswahl los (LABEL ist die Bezeichnung für eine Sprungmarke und nicht für eine Variable),

Naja stimmt schon. Ich komme halt aus einer anderen SPS Ecke und da sind Label einfach nur benannte Verbindungen, keine Sprünge. Ich weiss Siemens ist was anderes und man darf auf keinen fall ungenau beschreiben. Trotzdem denke ich ist den meisten klar was ich mit Label gemeint habe als ich sie mit LD etc. deutlich gemacht habe.

Setzt sich bei Flüchtigkeitsfehlern in Kommentaren fort ("X1 nach Y1, X2 nach X2"; was sind "Negative sowie
Positive Lineare" ?, hat aber keinen Einfluß auf das Programm) und geht sogar weiter in nicht exaktem Programmcode:

Na ich mach wenigstens Kommentare rein. Auch wenns eigentlich nur für mich ist. Ich könnts ja auch ganz sein lassen wie 90% der Programmierer die ich kenne.

Negative bzw Positive Lineare umrechnung soll nur verdeutlichen das man sowohl 0.0-100.0 nach 0.0-100.0 als auch 0.0-100.0 nach 100.0-0.0 umskalieren kann.

Aber Hauptsache, der simple Baustein ist KNOW_HOW_PROTECT. Dann sieht ja niemand diese Schlampereien.

Das hab ich halt mit der Ursprungsquelle mitkopiert und nicht verändert. Da die Quellen aber eh immer beim Programm dabeibleiben ist das ja auch nicht weiter schlimm. Und jeder sieht die Schlamperei und kanns besser machen. Wenn er denn die Zeit dafür findet.

interne Zwecke zu verwenden. Die Step7-Editor-Warnung "Die Lokaldaten werden schon absolut verwendet ..." ist
nicht als allgemeine Belästigung des Programmierers gedacht, sondern gibt den Hinweis, daß die undeklarierte
Verwendung der Lokaldaten mit der verborgenen MC7-internen Verwendung der Lokaldaten kollidiert.

Diese Meldung kommt aber NUR wenn man Lokaldaten deklariert. Ich habe diese Meldung zuvor noch NIE gesehen. Eben weil ich die sonst nicht deklariere.

mfG René