Sonstiges FUP-Ausgang mehrfach verwenden

M_a-r_k-u_s

Level-1
Beiträge
7
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Geht das, dass man einen Ausgang eines FUP-Bausteins, z.B. eines Timers, mehrfach verwendet. Also der Ausgang soll z.B. als Eingang eines AND Gatters und eines OR Gatters verwendet werden. Habe noch keine Möglichkeit gefunden, wie das gehen könnte.

Gruß
Markus
 
Ja dies ist möglich. Du kannst hierfür in FCs temporäre Variablen verwenden (der Wert dieser Variablen wird jedoch nach der Abarbeitung des Bausteins nicht gespeichert), man verwendet TEMP-Variablen deswegen eher um Zwischenergebnisse in einem FC/FB zu verwalten. Weiters kannst du hierfür auch einen Merker verwenden, wovon jedoch viele abraten. Wenn du einen FB verwendest und das Ergebnis des Ausgangs dauerhaft gespeichert werden soll, solltest du eine STAT-Variable verwenden. Lies dir hierzu Dokumente wie
https://www.automation.siemens.com/doconweb/pdf/SINUMERIK_SINAMICS_04_2010_D/S7P.pdf?p=1
http://www.global.hs-mittweida.de/~ifa/www-d/Ausbildungsportal/s7manual/s7gsv5_a/s7gsv51a.pdf

durch.

mfg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Beim zum Beispiel der Timer kannst du am ODER / UND Gatter den Timernummer als Variable eingeben.
Bei TIA kannst du die Timer.Q als Variable nehmen.

Sonnst musst du über zwischenvariablen arbeiten.

Als projektier tipp
Hänge deine eigene FC's aber nicht über die ENO Schnittstelle an einander.
Ruf die untereinander auf.

Bram
 
Beim zum Beispiel der Timer kannst du am ODER / UND Gatter den Timernummer als Variable eingeben.
Bei TIA kannst du die Timer.Q als Variable nehmen.

Sonnst musst du über zwischenvariablen arbeiten.

AUFPASSEN!!!

Wenn man mehrfach im Programm einen Timer abfragt U T ... oder in TIA U Timer.Q so können diese Abfragen im SPS Zyklus schon mal unterschiedliche Ergebnisse liefern: Also bei der Abfrage am Anfang des Programms ist der Ausgang noch false, später im Programm, aber im gleichen Zyklus, schon true.
Wenn man das mehrfach benötigt, sollte immer ein Merker oder eine statische Vriable am Ausgang des Timers dran hängen.

Grüße Tom
 
AUFPASSEN!!!

Wenn man mehrfach im Programm einen Timer abfragt U T ... oder in TIA U Timer.Q so können diese Abfragen im SPS Zyklus schon mal unterschiedliche Ergebnisse liefern:

Das gilt NUR für S7 Timer (U T11). Nicht für die IEC Timer (Timer.Q ist ein Ausgang eines IEC Timers). IEC Timer können ihren Zustand erst bei erneutem Aufruf des TimerFBs ändern. Mit Timer.Q fragt man aber nur die Instanz ab.

mfG René
 
Das gilt NUR für S7 Timer (U T11). Nicht für die IEC Timer (Timer.Q ist ein Ausgang eines IEC Timers). IEC Timer können ihren Zustand erst bei erneutem Aufruf des TimerFBs ändern. Mit Timer.Q fragt man aber nur die Instanz ab.
Da solltest du jetzt aber aufpassen, mit TIA und S7-1500 und imho auch S7-1200 ist diese deine Aussage (leider) falsch.
Da läuft ein IEC-Timer sogar weiter, obwohl er gar nicht mehr aufgerufen wird.
Auch so eine gaaaanz toooolllllle Neueuerung, sozusagen eine Innovation vom Marktführer ;)
 
Angeblich soll es bestimmte 300er geben wo das Abfragen auf Timer.Q auch problematisch sein soll, dort habe ich das noch nicht beobachten. Bei der 1200/1500 ist es das auf jeden Fall.
Siehe:
http://www.sps-forum.de/simatic/63330-seltsames-verhalten-der-ton-timer-bei-der-s7-1200-a.html

Macht die IEC-Timer wieder etwas unpraktisch, da immer eine extra Variable für den Ausgang benötigt wird.

Hallo thomas,

ist das das noch immer aktuell?
ich sehe das du mit die v11 das geprüft hast.

bram
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Macht die IEC-Timer wieder etwas unpraktisch, da immer eine extra Variable für den Ausgang benötigt wird.

Ich konnte das bisher nicht nachvollziehen. Den Timer direkt auf sich selbst zurückzuführen mache ich aber auch in Step7 nicht.
Aber direkt die Instanz abzufragen ging bisher absolut ohne Probleme. Wobei ich zugeben muss, bei der 1500er habe ich erst einige Testprogramme gemacht noch nichts was ins Feld ging.

Mich stört da eher das S7 Zeiten in FUP jetzt designmässig an die IEC Timer angeglichen wurden obwohl das überhaupt keinen Sinn macht. Denn eine Abfrage U T11.Q ist ja nicht möglich das wird immernoch als U T11 abgefragt.

mfG René
 
Ich konnte das bisher nicht nachvollziehen. Den Timer direkt auf sich selbst zurückzuführen mache ich aber auch in Step7 nicht.
Aber direkt die Instanz abzufragen ging bisher absolut ohne Probleme. Wobei ich zugeben muss, bei der 1500er habe ich erst einige Testprogramme gemacht noch nichts was ins Feld ging.
Natürlich geht das, du solltest nur im Hinterkopf haben, wenn du das n-mal im Zyklus machest, das Timer.Q nicht unbedingt den ganzen Zyklus lang den gleichen Zustand haben muss.
Der S7-1200/1500 IEC Timer ist vom Verhalten her also weniger ein FB sondern eher ein IEC-S5-Timer.
 
ist das das noch immer aktuell?
ich sehe das du mit die v11 das geprüft hast.

Das ist auch mit der aktuellen V13 SP Blub Update Bla noch so. Wenn sich da was ändern würde, dann müsste das wohl in der Firmware geschehen.
Auch wenn Siemens in ihren Bildchen was anderes zeigen, nach meiner Erkenntnis wird sehr vieles erst in der Steuerung in ausführbaren Code übersetzt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Natürlich geht das, du solltest nur im Hinterkopf haben, wenn du das n-mal im Zyklus machest, das Timer.Q nicht unbedingt den ganzen Zyklus lang den gleichen Zustand haben muss.
Der S7-1200/1500 IEC Timer ist vom Verhalten her also weniger ein FB sondern eher ein IEC-S5-Timer.

Das wär aber echt krass. Denn IEC Timer sind ja nach Norm an den Task gebunden in dem sie aufgerufen wurden. Oder gibts sowas auch bei anderen Steuerungen dass die getrennt ablaufen.

Wer sagt mir denn dann dass ein Zugriff auf eine Instanz sonst überhaupt Zyklusgerechte Ergebnisse liefert.

Wenn ich am Anfang des OB1 Zyklus einen FB aufrufe mit einem OUT. Können dann FB.OUT an verschiedenen Stellen im Programm auch unterschiedliche Zustände haben obwohl der FB nur einmal aufgerufen wird?

mfG René
 
Die IEC-Norm ist bezüglich Timer äußerst dürftig, denn dort sind eigentlich nur die Timingdiagramme festgelegt. Von Instanzen oder wie die Timerwerte intern gespeichert werden ist dort nicht die Rede. Z.B. dass die Siemens Timer bei PT:=T#0s überhaupt nicht durchschalten und bei Codesys direkt ist nicht festgelegt. Rein intuitiv würde ich das Codesys Verhalten für logischer halten, denn keine Verzögerung ist für mich 0s. Wahrscheinlich ist beim Verfassen der Norm niemand auf die Idee gekommen das anders zu interpretieren.

Bei Siemens scheint man nach Lücken zu suchen, um sich offiziell IEC-Konformität aufs Fähnchen schreiben zu können, aber trotzdem maximale Unkompatibilität zu anderen IEC-Steuerungen zu gewährleisten. Wäre ja auch zu schön, wenn man beispielsweise die Oscat-Bibliothek direkt auf allen angeblichen IEC-Steuerungen verwenden könnte.
 
Also Siemens schreibt dazu wörtlich im Buch des Hand:
Die Aktualisierung der Anweisungsdaten geschieht sowohl bei einem Aufruf der Anweisung
als auch bei einem Zugriff auf die Ausgänge Q oder ET.
Das mit T#0ms ist bei den neuen jetzt wohl auch kein Thema mehr, dafür hat man jetzt ja Spezialitäten wie "PT" oder auch "RT" ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Da läuft ein IEC-Timer sogar weiter, obwohl er gar nicht mehr aufgerufen wird.
Auch so eine gaaaanz toooolllllle Neueuerung, sozusagen eine Innovation vom Marktführer ;)
Der S7-1200/1500 IEC Timer ist vom Verhalten her also weniger ein FB sondern eher ein IEC-S5-Timer.
:icon_eek: Oha.... Gut zu wissen. Danke. Da werden sich aber ein paar Leute (möglicherweiser auch ich) freuen wenn mal ein konvertiertes Programm deswegen Blödsinn macht...

Die IEC-Norm ist bezüglich Timer äußerst dürftig, denn dort sind eigentlich nur die Timingdiagramme festgelegt. Von Instanzen oder wie die Timerwerte intern gespeichert werden ist dort nicht die Rede. Z.B. dass die Siemens Timer bei PT:=T#0s überhaupt nicht durchschalten und bei Codesys direkt ist nicht festgelegt. Rein intuitiv würde ich das Codesys Verhalten für logischer halten, denn keine Verzögerung ist für mich 0s. Wahrscheinlich ist beim Verfassen der Norm niemand auf die Idee gekommen das anders zu interpretieren.
Kann ich nur zustimmen. Wahrscheinlich hat ein Siemens-Programmierer einen Weg für einen Reset-Eingang gesucht und glaubte besonders schlau zu sein.
Den fehlenden Reset-Eingang finde ich vor allem beim Impulstimer schade. Steht darüber nichts in der Norm?

Das mit T#0ms ist bei den neuen jetzt wohl auch kein Thema mehr, dafür hat man jetzt ja Spezialitäten wie "PT" oder auch "RT" ...
Stimmt T#0ms ist echt kein Problem mehr, habs grad im Simulator ausprobiert. Wird beim konvertieren auch jene freuen die irgendwo ein T#0ms als Reset verwendet haben.
Man kann den TP und TOF aber anscheinend (mal abgesehen von der Funktion "Timer rücksetzen") auf zurücksetzen in dem man T#0ms auf des ST-Wert (Startzeit) schreibt.

@MSB: Was meinst du mit den Besonderheiten von PT oder RT?
 
Also Siemens schreibt dazu wörtlich im Buch des Hand:

Das mit T#0ms ist bei den neuen jetzt wohl auch kein Thema mehr, dafür hat man jetzt ja Spezialitäten wie "PT" oder auch "RT" ...

Danke für die Aufklärung das ist mir im Handbuch garnicht aufgefallen. Da sehe ich wieder, ich sollt einfach meine Raffel halten statt Blödsinn zu verzapfen.

Aber das ist auf jedenfall etwas das ich in meinen Konvertierten Programmen ändern muss.

mfG René
 
Zurück
Oben