TIA Drehrichtungsumkehr mit Impulssignal

Moo · 2 November 2017

Hallo,

ich stehe mal wieder vor einem Problem das ich nicht richtig gelöst bekommen. Problem ist folgendes. Ich habe ein Signal, das durch eine Puls und eine Pauseneit variabel definiert ist. Jeweils bei einem neuen Puls soll sich die Drehrichtung eines Motor ändern, also von Links auf Rechts und umgekehrt. Im Anhang ein Diagramm wie ich das gerne hätte, dummerweise krieg ich es nicht hin. Ich habe schon etliches probiert mit irgendwelchen Stromstossschaltungen etc.. Hat jemand villeicht einen Tipp?

Heinileini · 2 November 2017

möö schrieb:
.... irgendwelchen Stromstossschaltungen ...

Was heisst "irgendwelche"?
Flanke von EingangsSignal auf StromStossDingsbums.
AusgangsSignal von StromStossDingsbums UND EingangsSignal auf RechtsLauf.
Negiertes AusgangsSignal von StromStossDingsbums UND EingangsSignal auf LinkssLauf.

PS: wenn Exklusiv-Oder verfügbar: Flanke auf den einen Eingang von XOR, Ausgang von XOR auf den anderen Eingang von XOR - fertig ist ein StromStossDingsbums. Den Ausgang von XOR natürlich auf ein "langlebiges" Bit legen - temporäres genügt nicht.

M-Ott · 2 November 2017

Wenn Du einen funktionierenden Stromstoßschalter nimmst, funktioniert es bestimmt. SuFu: Stromstoßschalter
Wenn Du auf AWL umschaltest, siehst Du vielleicht selbst, warum Dein Stromstoßschalter nicht funktioniert.

RONIN · 2 November 2017

M-Ott schrieb:
Wenn Du auf AWL umschaltest, siehst Du vielleicht selbst, warum Dein Stromstoßschalter nicht funktioniert.

Das geht in TIA nicht mehr.
Grundsätzlich ist die Logik die der TE programmiert hat nicht falsch (da er #Toggle und nicht #SR für die Verknüpfung vor dem SR-Baustein nimmt).
Das würde durchaus so funktionieren, wenn der Baustein sich nur sein Ergebnis merken könnte.

Da sowohl "#SR" als auch "#Toggle" im FC-TEMP als temporäre Variablen deklariert sind, wird deren Zustand nicht gespeichert und ist am Ende des Bausteindurchlaufs weg.
#SR" als auch "#Toggle" haben (je nach Gegebenheit) am Bausteinbeginn entweder den Wert "FALSE" oder gar einen zufälligen Wert.

Damit diese Logik funktioniert müssten beide Werte über den Zyklus hinweg gespeichert werden. Beim FC geht das nur mit INOUT.
Am besten du schaust dir "Stromstoßschalter"-FAQ hier im Forum an. Diese Logikvarianten kommen auch mit einem Bit aus dass du über den Zyklus hinweg speichern musst.

Moo · 2 November 2017

Irgendwelche Lösungsvorschläge? In meinem Projekt läuft es nicht, in einem leeren TIA Projekt wo nur mein "Wechsler" vorhanden ist, funktionert es nun?

Heinileini · 2 November 2017

RONIN schrieb:
... Damit diese Logik funktioniert müssten beide Werte über den Zyklus hinweg gespeichert werden. Beim FC geht das nur mit INOUT. ...

Muss man denn bei FCs auch die FlankenMerker auf INOUTs legen? Oder gibt's FP und FN auch nicht mehr bei TIA?
Zwei "langlebige" Bits werden schon benötigt: eins für den FlankenMerker und eins für den Ausgang des StromStossTogglers.

PN/DP · 2 November 2017

möö schrieb:
In meinem Projekt läuft es nicht, in einem leeren TIA Projekt wo nur mein "Wechsler" vorhanden ist, funktionert es nun?

Weil dann die vom FC benutzten temporären Variablen nicht durch andere Bausteine mit-benutzt werden und deshalb beim nächsten FC-Durchlauf glücklicherweise immer noch die Werte vom Durchlauf vorher drin liegen.

PS: Eine S7-300/400 muß man nicht mit TIA programmieren...

Harald

Moo · 2 November 2017

Aber als FB funktioniert es auch nicht, solangsam dreh ich durch.

PS: Eine S7-300/400 muß man nicht mit TIA programmieren... :wink:

Wie meinst das?

PN/DP · 2 November 2017

Heinileini schrieb:
Muss man denn bei FCs auch die FlankenMerker auf INOUTs legen? Oder gibt's FP und FN auch nicht mehr bei TIA?

Ja, muß man (*). Auch FP und FN brauchen "langlebige" Flankenmerker.

(*) Man kann natürlich im FC auf globale Variablen zugreifen, doch dann verliert man die Möglichkeit den FC mehrfach aufzurufen, weil dann jede Aufruf-"Instanz" die selben globalen Ressourcen benutzt.

Harald

Heinileini · 2 November 2017

PN/DP schrieb:
Ja, muß man (*). Auch FP und FN brauchen "langlebige" Flankenmerker.

(*) Man kann natürlich im FC auf globale Variablen zugreifen, doch dann verliert man die Möglichkeit den FC mehrfach aufzurufen, weil dann jede Aufruf-"Instanz" die selben globalen Ressourcen benutzt.

Harald

Also, wenn FC, dann FlankenMerker und ToggleBit auf INOUTs legen und eventuell am ResetEingang sparen, dessen Relevanz mir nicht so ganz einleuchten will und dessen Verhalten auch nirgends vom TE gefordert/beschrieben wurde (nur beiläufig erwähnt).

PN/DP · 2 November 2017

möö schrieb:
Aber als FB funktioniert es auch nicht, solangsam dreh ich durch.

Hast Du die Toggle- und SR-Variablen nach Static verschoben oder liegen die immer noch in TEMP? TEMP funktioniert auch in FB nicht, TEMP kann sich in keinem Baustein etwas kontrolliert/sicher bis zum nächsten Durchlauf merken.

möö schrieb:
PS: Eine S7-300/400 muß man nicht mit TIA programmieren...

Zum Vergrößern anklicken....

Wie meinst das?

Verrate uns doch mal bitte, welche CPU Du programmierst. Eine S7-1500 wird es ziemlich sicher nicht sein, weil da hat Siemens für die unbekümmerten Programmierer dafür gesorgt, daß temporäre Variablen bei jedem Aufruf mit Defaultwerten initialisiert werden. Da würde auch Dein "leeres" Projekt mit nur dem FC nicht funktionieren.

Harald

Moo · 2 November 2017

Jetzt habe ich das nochmal geändert, FC mit "Datenbaustein"funktionert aber auch nicht. Bibliotheksfähig muss er nicht sein.
Der Reset soll einfach verhindern, wenn die Anwendung ausgeschaltet ist, das warum auch immer irgendein Signal aus der schaltung kommt.

Dieser Togglebaustein ist eigentlich nur ein Unterprogram von einem anderen FC welcher dann im OB 1 aufgerufen.

Warum schaltet den der obere UND Baustein nicht durch? Signale sind doch da???

Eine S7 313C

PinkPanther32 · 2 November 2017

weil dein #sr immer noch vom Typ temp ist und damit nicht gespeichert wird.
Nimm einen Merker oder ein Bit im DB.

PN/DP · 2 November 2017

möö schrieb:
Warum schaltet den der obere UND Baustein nicht durch? Signale sind doch da???

Wie Du an der blauen Linie nach dem [P] sehen kannst sind nicht alle Signale am Eingang des UND "da" (also TRUE) und deshalb ist das UND auch nicht TRUE.
Am Ausgang des [P] ist das VKE nur 1 Zyklus lang TRUE, was Du nur mit sehr viel Glück beobachten kannst.

Dein #SR ist immer noch in TEMP - deshalb wird Dein FC generell nicht funktionieren. Was ist eigentlich so schwer daran, die Flankenmerker und das #SR in IN_OUT zu verschieben und beim FC-Aufruf mit globalen Variablen zu beschalten?

Harald

Moo · 2 November 2017

Dein #SR ist immer noch in TEMP - deshalb wird Dein FC generell nicht funktionieren. Was ist eigentlich so schwer daran, die Flankenmerker und das #SR in IN_OUT zu verschieben und beim FC-Aufruf mit globalen Variablen zu beschalten?

Vielen Dank erstmal an alle! Das ganze soll für ein Technikerprojekt sein und der betreuende Lehrer will auf gar keinen Fall irgendwelche IN_OUT irgendwo sehen, weil er der Meinung ist, das ist Murks. Er argumentiert dann immer mit irgendeiner DIN ... Das selbe mit der Verwendung von Merkern, weil irgendwo Siemens wohl geschrieben haben soll, man soll das nicht verwenden...

Heinileini · 2 November 2017

PN/DP schrieb:
... Was ist eigentlich so schwer daran, die Flankenmerker und das #SR in IN_OUT zu verschieben und beim FC-Aufruf mit globalen Variablen zu beschalten? ...
Harald

Ja, wenn dieser FC-Aufruf in einem anderen FC (!) mit globalen Variablen beschaltet werden kann, warum kann der FC dann nicht direkt die globalen verwenden?

PN/DP · 2 November 2017

Heinileini schrieb:
Ja, wenn dieser FC-Aufruf in einem anderen FC (!) mit globalen Variablen beschaltet werden kann, warum kann der FC dann nicht direkt die globalen verwenden?

Wenn der FC selber direkt auf globale Variablen zugreift, dann verwendet jeder FC-Aufruf die selben globalen Variablen - da würde z.B. nur der erste Aufruf eine Flanke erkennen. Wenn die Variablen in die IN_OUT-Parameter gelegt werden dann kann man den FC parametrisiert mit verschiedenen Variablen aufrufen:

Code:

           +-----------+
           | FC_Toggle |
           |           |
      E0.1-|IN_Taster  |
DB1.DBX0.1-|IO_SR      |
           +-----------+

           +-----------+
           | FC_Toggle |
           |           |
      E0.2-|IN_Taster  |
DB1.DBX0.2-|IO_SR      |
           +-----------+

           +-----------+
           | FC_Toggle |
           |           |
      E0.3-|IN_Taster  |
DB1.DBX0.3-|IO_SR      |
           +-----------+

Harald

PN/DP · 2 November 2017

möö schrieb:
Das ganze soll für ein Technikerprojekt sein und der betreuende Lehrer will auf gar keinen Fall irgendwelche IN_OUT irgendwo sehen, weil er der Meinung ist, das ist Murks.

Dann erkläre dem Lehrer daß die Aufgabe so mit einem FC nicht lösbar ist, weil für die Aufgabe ein Gedächtnis nötig ist! und weil ein FC sich nichts merken kann und nur über die Hilfskonstruktion eines IN_OUT (oder getrenntem OUT und IN) außerhalb des FC etwas merken und beim nächsten Aufruf weiterverwenden kann. "Normale" IN und OUT dürft Ihr verwenden? Dann kannst Du es so lösen (so wäre es aber wirklich Murks!):

Code:

           +-----------------+
           |    FC_Toggle    |
           |                 |
      E0.1-|IN_Taster        |
DB1.DBX0.1-|IN_SR      OUT_SR|-DB1.DBX0.1
           +-----------------+

Im FC müsste am Anfang #IN_SR in die lokale #SR-Variable kopiert werden und am Ende die lokale #SR-Variable in #OUT_SR kopiert werden.
OUT_SR: ist das was der FC speichern will
IN_SR: hier wird der gespeicherte Wert dem FC wieder zur Verfügung gestellt

Wenn ein Baustein sich auch selber etwas merken können soll, dann geht das nur mit FB (Function Block), da kann man die zu merkenden Sachen in den lokalen Instanz-Variablen (Static) speichern. Dem FB muß man dann "unauffällig" beim Aufruf einen Speicherbereich mitgeben, den er für die Instanz verwenden soll: entweder einen Instanz-DB oder einen Multiinstanz-Speicherbereich innerhalb eines anderen DB.

Harald

Heinileini · 2 November 2017

PN/DP schrieb:
Wenn der FC selber direkt auf globale Variablen zugreift, dann verwendet jeder FC-Aufruf die selben globalen Variablen - da würde z.B. nur der erste Aufruf eine Flanke erkennen. Wenn die Variablen in die IN_OUT-Parameter gelegt werden dann kann man den FC parametrisiert mit verschiedenen Variablen aufrufen:

Ja, logisch. Aber was hat der TE denn mit ...

möö schrieb:
... Bibliotheksfähig muss er nicht sein. ...

... gemeint? Hatte das so gedeutet, dass er an "seinen" FC nicht den Anspruch stellt, dass er in einer Anwendung mehrfach benutzt wird, also nicht "FC-konform" sein muss.
Ich dachte er wolle nur klären, wie man die Funktionalität realisieren kann, ohne dabei auf die feinen Unterschiede der verschiedenen "Verpackungen" einzugehen.
Das kommt davon, wenn die einzelnen zu beachtenden Randbedingungen erst so nach und nach im Laufe des Thread herausgemeisselt werden.

JoopB · 3 November 2017

Hier ein beispiel mit ein FB , Wenn Sie ein FC braucht mussen alle STAT variable in dass INOUT bereich gesets wurde, In ihre erste bild habe Sie merkers fur die FP gebraucht aber wenn Sie diese FC meerder x in das prgramm brauch geht das nicht gut da diese merker meerder x angestuurd wurde.

TIA Drehrichtungsumkehr mit Impulssignal

Level-1

Level-3

Level-3

Level-3

Level-1

Level-3

User des Jahres 2011-2013; 2015-2017; 2020-2022

Level-1

User des Jahres 2011-2013; 2015-2017; 2020-2022

Level-3

User des Jahres 2011-2013; 2015-2017; 2020-2022

Level-1

Level-2

User des Jahres 2011-2013; 2015-2017; 2020-2022

Level-1

Level-3

User des Jahres 2011-2013; 2015-2017; 2020-2022

User des Jahres 2011-2013; 2015-2017; 2020-2022

Level-3

Level-2

Anhänge

Similar threads

Wir schützen deine Privatsphäre