TIA TIA V13 TOF als Multiinstanz

C7633

Level-1
Beiträge
224
Reaktionspunkte
13
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo

Ich habe einen TOF als Multinistanz in einem Baustein angelegt.
Dieser Schaltet sofort durch

tVyUwj3kDqEAAAAASUVORK5CYII=


tVyUwj3kDqEAAAAASUVORK5CYII=
tiatimer.JPG

Und geht auch nicht mehr auf false.

Wenn ich den Timer mit einem DB beschalte funktioniert es.
Das hilft mir aber wenig, da ich den "Hauptbaustein" multiinstanzfähig haben möchte.

Was mache ich falsch?
 
Ich meine so einen Bug auch gehabt zu haben. Hab dann testhalber mal den et beschaltet und seit dem lief es ^^
Hört sich komisch an - war aber so.
 
@: Howard: Das hat leider nicht geholfen

@PN/DP: echte CPU 1512 C-1

Wenn jemandem was einfällt, ich wäre dankbar
 
Hatte auch dieses Problem mit den IEC-Timern.
Meines Erachtens liegt es am AWL-Netzwerk(Wird vermutlich nicht richtig übersetzt).
Habe den Timer dann in einem SCL-Netzwerk aufgerufen, und siehe da es hat funktioniert :confused:.

THIS
 
Warum schreibst du an den IN den den #... .IN? Schön ist das nicht. Kannst du dir nicht temporäre oder statische Variablen dafür anlegen wenn du eh schon im FB bist?

Du rufst den Timer immer auf oder liegt der in einer Schleife die du nicht zyklisch ausführst?

Was für eine CPU hast du denn eigentlich verbaut? Ist bei ner 300er die direkte Verschaltung von Timern in TIA nicht ohnehin untersagt? Zumindest in einer der älteren Versionen gab es da immer Bugs beim Compilieren oder SW Laden, meine das wurde dann mal verriegelt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es ist zwar ziemlich überflüssig bis sinnfrei, einen Eingang einer Instanz mit sich selbst zu beschalten, doch das kann/darf kein Problem sein.

Das vom TE verwendete Programm
Code:
U "test"
= #tof_MP.IN

CALL  #tof_MP
   IN :=#tof_MP.IN
   PT :=#timeval
   Q  :=#O_ComActiv
   ET :=
entspricht funktionell diesem
Code:
CALL  #tof_MP
   IN :="test"
   PT :=#timeval
   Q  :=#O_ComActiv
   ET :=

Wie ist O_ComActiv deklariert? Ist das ein Output? Was ist da außen angeschaltet?

Kannst Du mal diese Programmvariante probieren und beobachten, ändert sich da was?
Code:
CALL  #tof_MP
   IN :="test"
   PT :=#timeval
   Q  :=
   ET :=

U #tof_MP.Q
= #O_ComActiv

Harald
 
Das vom TE verwendete Programm
Code:
U "test"
= #tof_MP.IN

CALL #tof_MP
IN :=#tof_MP.IN
PT :=#timeval
Q :=#O_ComActiv
ET :=
entspricht funktionell diesem
Code:
CALL #tof_MP
IN :="test"
PT :=#timeval
Q :=#O_ComActiv
ET :=

Sollte man meinen. Aber in der Simulation läuft es nicht bzw. kommt das verhalten vom TE

Benutzt ma:

Code:
U "test"
= #tof_MP.IN

wird der Ausgang nie zurückgesetzt. Selbst wenn "test" wieder 0 ist.

Schleift man es über eine Variable oder legt "test" direkt an den IN des Timers, funktioniert es.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Code:
CALL #tof_MP
   IN :="test"
   PT :=#timeval
   Q :=#O_ComActiv
   ET :=
Du meinst diese Variante funktioniert also im Gegensatz zu der Variante mit dem Anschalten von #tof_MP.IN?

Harald
 
Zuletzt bearbeitet:
Die 1500er IEC-Timer verhalten sich doch etwas anders. Das sind keine normalen FBs mehr, sondern wenn auf IN oder OUT (PT und ET meine ich auch) zugegriffen wird, dann wird direkt der Timer-Baustein aufgerufen. Quasi wie eine Getter-Methode bei C#. Darum kann man auch mit einem TON keinen Blinktakt mehr programmieren, indem NOT TON.Q auf TON.IN zurückgeführt wird. Da hat es aber letztendlich eine logische Erklärung.

Bei diesem TOF-Problem sehe ich aber zur Zeit noch nicht wie damit das Verhalten zu erklären ist, ich denke man das hängt irgendwie damit zusammen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Version 1 funktioniert eben nicht. Dort bleibt der Ausgang gesetzt.
Version 2 funktioniert.
Unglaublich. Was hat Siemens sich dabei gedacht? Ist das nun ein Systemverhalten der IEC-Timer oder einfach nur ein Compiler-Bug?

Passt dann ja ganz gut zu den anderen Merkwürdigkeiten im Verhalten der Siemens-"IEC"-Timer, wie daß man Q und ET nicht beobachten kann wenn man sie nicht explizit im Programm abfragt und das konfuse Reset-Verhalten...

Harald
 
Wird der TOF vielleicht nur aufgerufen "bei Änderung" des Eingangszustands - also wenn sich der aktuelle Wert des IN vom außen angeschalteten Wert unterscheidet?

Harald
 
Die 1500er IEC-Timer verhalten sich doch etwas anders. Das sind keine normalen FBs mehr, sondern wenn auf IN oder OUT (PT und ET meine ich auch) zugegriffen wird, dann wird direkt der Timer-Baustein aufgerufen. Quasi wie eine Getter-Methode bei C#. Darum kann man auch mit einem TON keinen Blinktakt mehr programmieren, indem NOT TON.Q auf TON.IN zurückgeführt wird. Da hat es aber letztendlich eine logische Erklärung.

Bei diesem TOF-Problem sehe ich aber zur Zeit noch nicht wie damit das Verhalten zu erklären ist, ich denke man das hängt irgendwie damit zusammen.



blinktakt.JPG

Meinst du diese Art Blinktakt? Das geht aber immernoch.
Wichtig ist nur, den .Q vor dem Timer abzufragen. Danach erzeugt er wie von dir angemerkt keinen Takt


Gruß

Chris
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo

Vielen Dank für die Antworten.
Ich habe gestern dann Feierabend gemacht, ich probiere das gleich aus.

Warum ich die Variable mti sich selber geschaltet habe?
Das habe ich bei S7 immer getan.
Bei großen Programmen wird es übersichtlicher, und man kann mit "GeheZurLokalenVerwendung" viel leichter suchen, wenn mal was nicht tut.
 
Wenn man mit temporären Variablen für In und Q schafft funktioniert das.
Tsja wieder typisch Siemens.
Wir sind kompatibel zu S7.
Dinge versprechen, die sie gar nicht halten können :sw4:

Wenn ich auf die SPS/Drives gehe, ziehe ich Sicherheitsschuhe an, damit ich die Helden auch kräftig ins Schienbein treten kann.
 
Und wenn man IN gar nicht beschaltet - funktioniert das?
Code:
U "test"
= #tof_MP.IN

CALL  #tof_MP
   IN :=
   PT :=#timeval
   Q  :=#O_ComActiv
   ET :=

Harald
 
Zurück
Oben