TIA Temporäre Variablen im selben Baustein

SPS_Stefan

Level-2
Beiträge
22
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo zusammen,

habe kein Thema gefunden welches mein Problem beschreibt. Falls ich es übersehen habe @ Admin: bitte verschieben. Danke

Ich nutze TIA 14 mit einer 1511 1 PN

Ich deklariere eine Temp Variable (Bool) Resete diese im ersten Netzwerk.
Weiße sie im zweiten Netzwerk zu und frage diese dann im selben Netzwerk nochmals ab. In der zweiten Abfrage ist sie Null, jedoch im Netzwerk 3 hat sie den richtigen Status.
Mach ich das mit Merkern, DB Adressen oder statischen Variablen des FB ist es wie es sein soll.

Siehe Bild Bild 1.JPG

Danke für eure Hilfe!

Grüße Stefan
 
Am Ende von Netzwerk 8 ist die Variable auf true weil du ihr diesen Wert zuweist, und diesen Zustand besitzt sie auch noch in Netzwerk 9.
Die Zustände sind überall logisch aus der Verknüpfung abzuleiten.

Wenn du deine KOP-Schaltung in Hardware umsetzen würdest, dann erwartest du dass ein Schließerkontakt eines Schützes schließt bevor die Spule angesteuert wird.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo und danke für eure Antworten!

Ich habe ein Step 7 V5 Programm zur Migration erhalten. Aussage Kunde war "läuft so nichts ändern, außer Fehler von TIA!"

Ursprünglich war es so, dass die neue #Temp Zylinder öffnen/ausfahren der direkte Ausgang A0.x war. Dieser wurde wie im Bild im selben Netzwerk nochmals abgefragt, TIA bringt die Warnung das Ausgänge nicht abgefragt werden sollen.
Daher Temp VAR initiallisiert ==> Zugewiesen ==> auf Ausgang geschrieben.
 
Ja, aber da hast du eben ein anderes Verhalten. Der Ausgang hate den Zustand vom vorigen Zyklus, deine Temp Var ist immer 0. Dann nimm einen Merkel oder ein Bit in einem DB oder falls dein Baustein ein FB ist, eine Statische Variable!
 
Danke für deine Antwort.

Wie von PN/DP bereits gesagt funktioniert es mit keiner Variablen so.

Wenn ich es richtig verstanden habe wird die Zuweisung erst am Ende des Netzwerks erfolgen. (nicht am Ende des Bausteins)

Somit ein neuer Denkansatz...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du kannst nicht einfach irgendwas programmieren, nur damit die Warnungen weg sind oder von Siemens etwas empfohlen wird. Wenn du deine Variante mit den Temp-Variablen die du dort initialisierst genauso mit einer Stat Variable programmierst, dann funktioniert es eben genauso wenig, weil du dann den Zustand vom letzten Zyklus wieder entfernst.

Das mit der Warnung wenn eine Out-Variable eines FBs gelesen wird ist meiner Meinung nach auch völliger Nonsense. Ich sehe keinen Grund warum das zu Problemen führen sollte. In SCL erhältst du diese Warnung seltsamerweise auch nicht.

Viel merkwürdiger finde ich etwas anderes was ich bei deinem Screenshot sehe:
In dem Netzwerk 7 wo es eine Rücksetzanweisung ohne Bedingung gibt. In Step7 war das überhaupt nicht möglich. In KOP sieht das gemalt mit der "Leitung" nach links noch einigermaßen verständlich aus, wenn die Variable dann immer zurückgesetzt wird. Ich habe aber mal probiert was TIA daraus macht wenn ich so ein KOP-Netzwerk in FUP umschalte. Dann habe ich eine Rücksetzanweisung mit unbelegtem Eingang, was sogar erlaubt ist. Und wenn das Programm ausgeführt wird, dann wird dieser unbelegte Eingang einfach so als "true" angenommen. Dafür sehe ich jetzt keinen logisch zwingenden Grund.
 
Und wenn das Programm ausgeführt wird, dann wird dieser unbelegte Eingang einfach so als "true" angenommen. Dafür sehe ich jetzt keinen logisch zwingenden Grund.

ich kenns von anderen Systemen so. Unbelegte Eingaenge von UND Gliedern sind true, von ODER Gliedern false. So als waeren sie nicht da. Was Aehnliches haben sich die TIA Entwickler vielleicht auch gedacht.

@TE wenn es nicht auf zyklusgenaue Abarbeitung ankommt nimm ne statische Variable aber ohne Zuweisung am Anfang. Oder ignoriere die Warnung vom TIA...
 
Danke für deine Antwort.

Wie von PN/DP bereits gesagt funktioniert es mit keiner Variablen so.

Wenn ich es richtig verstanden habe wird die Zuweisung erst am Ende des Netzwerks erfolgen. (nicht am Ende des Bausteins)

Somit ein neuer Denkansatz...

wenn Du im ersten Netzwerk false setzt funktioniert es nicht. Ohne das erste Netzwerk funktionierts mit nen Merker so wie frueher in Step 7 Classic.

Ich wuerd aber weiterhin den Ausgang abfragen und die Warnung ignorieren. Der Kunde will es doch so...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ich kenns von anderen Systemen so. Unbelegte Eingaenge von UND Gliedern sind true, von ODER Gliedern false. So als waeren sie nicht da. Was Aehnliches haben sich die TIA Entwickler vielleicht auch gedacht.

Nur an dem unbeschalteten Eingang des R (oder S) steht dann "..." und nicht "true" oder "false". Wobei das ja bei "EN"-Parameter in FUP ähnlich ist, unbeschaltet wird der FB trotzdem aufgerufen.
Und die Dokumentation zu S/R sagt eindeutig, dass die Anweisung nur ausgeführt ist wenn das VKE am Boxeingang "1" ist. Bei einer SR Box mit unbeschaltetem R1 Eingang wird die Variable ja auch nicht pauschal zurückgesetzt nur weil der Eingang unbeschaltet ist.
Also ich habe es ausprobieren müssen was passiert, denn es könnte ja auch sein, dass die Anweisung nicht ausgeführt wird. Und das ist eigentlich ein schlechtes Zeichen wenn bei der Programmierung etwas ausprobiert werden muss.
 
TIA bringt die Warnung das Ausgänge nicht abgefragt werden sollen.
Wenn Du nicht den Output zurückliest sondern stattdessen ein Zwischenbit aus Static verwendest und am Ende an den Output kopierst, dann ist das für TIA OK:
Code:
                 #StaticBit
                 +--------+
  #EinBedingung  |   SR   |     #Output
-------| |-------|S      Q|-------( )
                 |        |
  #AusBedingung  |        |
-------| |-------|R       |
                 +--------+
oder als Selbsthaltung:
Code:
  #EinBedingung     #AusBedingung   #StaticBit   #Output
-------| |-------+------|/|-------------( )--------( )
                 |
   #StaticBit    |
-------| |-------+

PS: Warum Siemens in KOP/FUP das =/S/R ohne Vorverknüpfung bei der S7-1200/1500 eingeführt hat verstehe ich nicht (vielleicht damit man durch die eingesparten Klicks vieeel schneller programmieren kann? ;)). Bei S7-300/400 ist es aber auch in TIA ein Fehler.

Harald
 
Zurück
Oben