Step 7 MicroWIN - TEMP Variablen und OUT Ausgänge - SIEMENS Hinweis.

thomasdeldiaz

Level-1
Beiträge
47
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo SPS Forum Mitglieder,

Ich bin zurzeit beim Programmieren von einer SPS S7-200. Habe schon ganz viel über die TEMP Variablen in den SBRs gelesen und im Internet recherchiert. Es kam aus, dass am bestens die TEMP überhaupt nicht verwenden und eine STAT Variablen einsetzen. Auf die Weise habe ich über V Variablen einige, für mich so genante, interne Merkers erzeugt - zum beispiel Int_M_01 --> V1000.0 und mittels der Int Merkers die Netzwerke in SBR verknüpft. Nun bin ich an folgenden Hinweis von SIEMENS gestoßen - sehe LINK: https://support.industry.siemens.co...ariablentypen-out-oder-temp-verwende?lc=de-WW

Wie ich das verstanden habe, angeblich es können auch einige Probleme bei den internen L Variablen von OUT auftreten. Nach SIEMENS Empfehlung man sollte am Anfang des OBs eine Subroutine einsetzen die die alle Ls auf gewissen Stand setzt - vorzugsweise auf FALSE meiner Meinung nach - sehe auch die Bilder. Eventuell alle über IN/OUT durchlassen.

SPS-01.PNG

SPS-02.jpg

Könnte mir jemand das klären, ob die alle OUTs am Anfang auf FALSE bzw. TRUE gesetzt werden sollen ?

Was mit den TEMP Variablen gibt es ein gewissen Beispiel wo man die einsetzen könnte ?

MfG,

T-Mack
 
Die Outs der SBRs verhalten sich wie Temps.
Das heisst, sie müssen in jedem Zyklus als erstes (neu) beschrieben werden, bevor man lesend auf sie zugreift. Egal, ob innerhalb oder außerhalb der SBR. Ansonsten ist ihr Zustand undefiniert. Das kann unter gewissen Umständen wie im Zyklus vorher sein, muss aber nicht.
S(et) und R(eset) z.B. schreiben nicht jeden Zyklus. Daher muss dort entweder InOut oder eine globale Variable verwendet werden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Temps kann man problemlos für Zwischenergebnisse verwenden.
Also in jedem Zyklus der Temp erst einen Wert zuweisen und mit diesem Wert noch im gleichen Aufruf der SBR weiter arbeiten funktioniert.
Erfolgt jedoch eine Beendigung der SBR, in der die Temp deklariert ist, so wird sie wieder zum Überschreiben frei gegeben und somit ist ihr Wert bis zum nächsten Aufruf der SBR bzw. genauer bis zum nächsten Beschreiben der Temp undefiniert.
 
Hallo Hucki,

Danke für deinen Aufklärung.

Könntest du sich bitte die folgende Bilder anschauen, und eventuell beurteilen ob diese SBR korrekt gemacht wurde ?


SPS-3.PNG

SPS-4.PNG


Ich möchte noch was fragen:

Also wenn ich es gut verstanden habe, ein Zyklus innerhalb der SBR bedeutet der Programmablauf in diesem Fall von Netzwerk #1 bis Netzwerk #2, und anschließend wieder alles von Vorn, heißt Zyklus #2, #3, usw. ... ???

Die SBR wird permanent aufgerufen mit SM0.0, also TEMPS behalten ihre Zustände. Wenn wir nun den SM0.0 rausnehmen würden, dann werden die TEMPS verloren gehen, heißt möglicherweise überschrieben von einer anderen SBR ???

MfG,

T-Mack
 
Zuletzt bearbeitet:
Die Temp-Variable in Bild 1 ist richtig verwendet, weil sie zuerst (im NW1) beschrieben und danach erst (NW2) gelesen wird. Dabei spielt es keine Rolle, ob die SBR in jedem Zyklus oder nur bei Bedarf aufgerufen wird.

Stell Dir folgenden Ablauf vor:
1. Alle Eingänge der SPS erfassen
2. Den Programmzettel Main abarbeiten
3. Alle Ausgänge lt. Programm setzen

In 2. steht bei Dir - SBR aufrufen
Mit dem Aufruf werden alle lokalen Variablen der SBR angelegt, dann deren Netzwerke abgearbeitet und zum Schluss die Ergebnisse an die (In-)Out-Variablen, die am Aufruf der SBR angegeben sind, übergeben. Danach wird die SBR beendet und es werden alle! lokalen Variablen der SBR zum Überschreiben frei gegeben. Wenn jetzt also noch was im Main folgt, sind diese also nicht mehr verfügbar. Auch wenn Du die SBR im gleichen Zyklus noch ein 2. mal aufrufst, müssen alle Variablen der SBR neu geschrieben werden.

Also auch wenn Du die SBR mit dem SM0.0 in jedem Zyklus aufrufst, wird sie trotzdem jedesmal neu gestartet und wieder beendet.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die SBR wird permanent aufgerufen mit SM0.0, also TEMPS behalten ihre Zustände.
Nein, TEMPs behalten ihren Zustand NICHT!, weil sie nach Abarbeitung dieser SBR auch in anderen SBR für andere Zwecke benutzt werden (können), was diese SBR aber nicht weiß. Deshalb bei jedem Durchlauf davon ausgehen, daß völlig unbekanntes/unvorhersehbares in den TEMPs steht und zuerst unbedingt selber etwas bestimmtes in die TEMPs schreiben.
Ob andere SBR die TEMPs benutzen ist völlig unabhängig davon, ob diese SBR aufgerufen wird. Umgekehrt kann diese SBR nicht wissen, wie die TEMPs von anderen SBR benutzt wurden.

Die als IN oder IN_OUT bezeichneten Variablen müssen nicht auf TEMP-Variablen umkopiert werden. Die werden bei jedem Aufruf der SBR erneut mit den außen angelegten Werten beschrieben und können in der SBR sofort gelesen/benutzt werden.

Harald
 
Wofür überhaupt der Aufwand?

Du beschreibst im Baustein das V0.0 als absolute Adresse.
Das wiederum schließt eine Mehrfach-Verwendung des Bausteins aus, und somit braucht man auch keine Schnittstelle.
 
Hallo Hucki und PN/DP,

Es ist nun bisschen mehr klar geworden.

Was passiert mit OUT Variablen, ist das OK wie ich es auf dem Bild 1 zugeordnet habe ?

Danke,

T-Mack
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja, das ist okay.

Um den von MSB angesprochenen Mangel zu beheben, musst Du noch eine INOUT-Variable anlegen, diese am Flipflop im NW2 verwenden und den V0.0 dann beim Aufruf der SBR an den neuen Schnittstellenparameter legen.
Somit hast Du die globale Speicherung aus der SBR heraus geführt, was die SBR mehrfach nutzbar macht.
 
Hallo Hucki,

Diese Problem haben wir auf dem Forum schon berührt.

Es lässt sich leide nicht auf die Weise lösen - über IN/OUT Variable - sehe Bilder.

SPS-5.PNG

SPS-6.PNG

Es lässt sich zwar eine V Variable an die IN/OUT Schnittstelle zu zuweisen, aber in der SBR tritt ein Fehler auf - roter Kreis.

Man muss unter die Umstände direkte Adressierung vornehmen.

MfG,

T-Mack
 
Hallo Hucki,

Noch eine Bitte. Könntest du eventuell ein Beispiel schildern wo man die TEMP Variablen nicht verwenden soll ? Das ist nun ganz interessant für mich. Man spricht beispielsweise manchmal von Flankenauswertung.

MfG,

T-Mack
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Tagsüber hab ich nur manchmal kurz Zeit, übers Handy ins Forum zu schauen. Daher geht das jetzt hier nicht.
Heut abend werd ich mal schauen, dass ich Dir was zeigen kann.
 
Könntest du eventuell ein Beispiel schildern wo man die TEMP Variablen nicht verwenden soll ? Das ist nun ganz interessant für mich. Man spricht beispielsweise manchmal von Flankenauswertung.
Ja, da hast Du Dir ein sehr gutes Beispiel herausgesucht.
Eine positive Flanke liegt vor, wenn der Zustand in diesem Zyklus 1 ist, während er im letzten noch 0 war. Bei einer negativen ist es genau umgekehrt - aktuell 0 und im vorigen 1. Die eingebauten Flankenmerker machen den Vergleich und speichern dann den aktuellen Zustand des Prüflings für die nächste Prüfung in ihrem fest adressierten Flankenmerker.
Da man diese eingebaute Flankenerkennung in einer SBR, die mehrfach aufgerufen werden soll, nicht nutzen kann (weil der Flankenmerker dafür variabel adressierbar sein müsste), muss man sich dort selbst was programmieren:

1. positive Flankenerkennung:


2. negative Flankenerkennung:


Auf die Zustandsmerker #FM1 und #FM2 wird erst lesend und danach erst schreibend zugegriffen. Diese lokalen Variablen müssen also ihren Zustand über die Beendigung des SBR-Aufrufs in diesem Zyklus bis zum SBR-Aufruf im nächsten Zyklus speichern, um dann den Zustand des Eingangs vom letzten Zyklus mit dem Zustand im aktuellen Zyklus vergleichen zu können. Die SBR selbst kann das nicht, da sie kein "Gedächtnis" (=Instanzdatenbaustein) hat. Deshalb muss man dafür INOUT-Variablen verwenden, die ihren Zustand beim Beenden der SBR über die SBR-Schnittstelle an globale Variablen außerhalb der SBR übergeben (=OUT) und beim Aufruf der SBR im nächsten Zyklus von diesen wieder zurück übernehmen (=IN).

Die Ergebnisse der Flankenauswertung werden dagegen zuerst zugewiesen, bevor sie in weiteren Netzwerken der SBR verarbeitet werden sollen. Da sie nicht über die Beendigung der SBR hinaus benötigt werden, weil beim nächsten Aufruf der SBR eine neue Flankenauswertung erfolgt, können diese Variablen temporär sein:








Diese Problem haben wir auf dem Forum schon berührt.

Es lässt sich leide nicht auf die Weise lösen - über IN/OUT Variable - sehe Bilder.
Ja, das Problem hatten wir schon.
Und auch die Lösung dazu, nämlich das SR-FlipFlop in ein Netzwerk für das S(etzen) und eins für das R(ücksetzen) zu zerlegen:



In Deinem Beispiel kommt dann noch ein Netzwerk zum Zuweisen des Ausgangs hinzu:





Etwas Erstaunliches hab' ich dabei noch festgestellt. Schaltet man das (von Dir gepostete) SR-Netzwerk mit der globalen Adressierung in AWL um, dann kann man die globale Variable durch eine lokale InOuT-Variable ersetzen, ohne das MicroWin anschließend bei der Übersetzung meckert:




Allerdings darf man dann keinesfalls wieder auf FUP/KOP zurückschalten. Sonst ist die Fehlermeldung sofort wieder da und auch beim Zurückschalten auf AWL wird "Netzwerk unzulässig" angezeigt.
Was beim Laden dieser AWL-Variante in die CPU passiert, hab' ich allerdings noch nicht getestet.
 
Hallo Hucki,

Vielen, vielen Dank für die beide Beispiele.

Das ist sehr nett von dir, dass du sich so viel Mühe gibst, um das ganze jemanden zu erklären.

Ich habe heute mein Kopf schon bei dem Programmieren zerbrochen, aber morgen früh werde ich gleich alles analisieren und unter die Lupe nehmen.

Ich wünsche dir schönes Wochenende.

Bis dann...

T-Mack
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Hucki,

:ROFLMAO: ICH HABE GERADE ERLEUCHTUNG ERLEBT :-D !!!

Es ist nun so simpel !!!

Also es ist mir jetzt vollkommen klar wofür die TEMPs dienen und wann soll man die einsetzen.

Du bist ein SPS GURU :ROFLMAO: :TOOL:

Bis dann... und Nochmals danke...

T-Mack
 
Zurück
Oben