TIA Sel_R in FB (Umschalten zw. Temp_Variable und IN_Variable) möglich?

[TIA_TESTER]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe eine Frage zum Umgang mit FB´s...

Kann ich an einem SEL_R (Wortverknüpfung) zwischen einem Internen Wert der von einer in der Schnittstelle als temp definierten Variable und einer in der schnittstelle IN definierten (und natürlich im aufrufenden fb verschalteten) variable umschalten oder kann ich in einem Netzwerk nur Interne ODER Externe Variablen verschalten. ?


Wenn ich nach außen verschalte so zeigt er mir beim beobachten nicht den Wert an sondern P#DB1.DBX2.0 REAL ? Das ist der bereich im Instanz-DB, schon klar aber müsste es nicht "...DBD2" heißen?

Dann hab ich in der Hilfe nichts gefunden zu den Farben und umrandungen der funktionen/anweisungen während dem Beobachte. Kann mir das jemand erklären:

Grün umrandet: Wird bearbeitet
Blau gestrichelt umrandet: Wird nicht bearbeitet da EN beschaltet aber nicht 1
Scale, Unscale und eben der SEL sind IMMER grau hinterlegt ? Was bedeutet das?

Vielen Dank schonmal,

Mfg T

 

[HelleBarde]

Hi T

Was für eine PLC hast du denn eine 300, 400, 1200, 1500. Jede ist büschen anders.

Du kann verschalten was da ist. Wenn du in deinem FB lokale Variablen aus deiner Schnittstelle hat, dann kannst du mittels #inputsoundso verschalten und die globalen stehen als "dbname".dbvariable zur Verfügung.

Aus P#DB1.DBX2.0 REAL lesi ich, dass du entweder ein 1500 mit standard Zugriff oder eine 300/400 verwendest. P#DB1.DBX2.0 REAL ist ein ANY Pointer der auf eine REAL ziegt die in DB1.DBD2 liegt. allns klor, min jung?

zu den Farben: Das TIA Portal unterscheidet 5 Farben.
satte durchgezogene grüne Linien stehen für gerade beobachtetes TRUE
satte gestrichlte blaue Linien stehen für gerade beobachtetes FALSE
blass durchgezogene grüne Linien stehen für gewesenes beobachtetes TRUE
blass gestrichlte blaue Linien stehen für gewesenes beobachtetes FALSE
graue Linien kommen da wo noch nie was beobachtet wurde oder nichts beobachtet werden kann.

Wenn die Boxen grau bleiben, dann zumeist weil das ENO nicht angeschlossen ist. Scheinbar denkt S wenn dir das ENO egal ist, dann ist dir der Zustand der Box egal. Und irgendwie hat das auch Logik. Andererseits gibt es jedoch viele Situationen wo das ENO nicht angeschlossen ist, aber die Box trotzdem bunt wird. Das ist von Box zu Box verschieden und scheint auch noch vom Datentyp abzuhängen. seufz.

Der zweite Grund warum ganze Netzte grau bleiben sind Sprünge. Wenn man immer drüber spring, dann kann eben nichts beobachtet werden. Das scheint bei dir aber nicht der Fall zu sein, wenn das EN grün ist.

Kontakte und Spulen haben die Farbe des Operanden.
Boxen haben die Farbe des ENO bzw Q bzw OUT Ausgangs.
Die Farbe der Linien sagt etwas über ein Signal aus. Dieses entsteht aus der Verknüpfung.


Beispiel:

a +---------+ b
|----||----|EN ENO|----(R)

Von der Stromschiene kommt sattes grün, weil die immer TRUE ist. Das Wesen einer Stromschine.
der Kontakt hat die Farbe von a. Ist a true, dann ist der Kontakt grün. Ist a false, dann ist der Kontakt blau.
Die Linie zwischen Kontakt und Box ist das Verknüpfungsergebnis der UND-Verknüpfug von a mit TRUE, also a. Wenn a false ist, dann blau sonst grün.
Das geht nun so ins das EN.
Das ENO und die Box haben den gleichen Wert. ENO := EN and "erfolgreiche Boxausführung".
Die Linie zwischen ENO und Spule ist gleich ENO.
Die Spule zeigt den Wert von b. Da ich hier eine R-Spule genommen habe ist der false wenn von links ein true rein kommt.
Wenn a ber false war, dann ist auch EN und damit ENO false und damit wird b auch nicht zurück gesetzt und damit kann die Spule selbst grün bleiben.

Das spannende ist was der große S unter "erfolgreiche Boxausführung" versteht. Bei ADD und anderer Mathe ist das "kein Überlauf". Bei einen Anwenderbaustein, musst du den Programmierer desselben fragen.

Das sind mann so die Grundzüge des Ganzen.

'n schönene Tach auch
HB

 

[TIA_TESTER]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi T

Was für eine PLC hast du denn eine 300, 400, 1200, 1500. Jede ist büschen anders.

Eine 3xxSC (VIPA)

Du kann verschalten was da ist. Wenn du in deinem FB lokale Variablen aus deiner Schnittstelle hat, dann kannst du mittels #inputsoundso verschalten und die globalen stehen als "dbname".dbvariable zur Verfügung.

Die Grundlegende Vorhergehensweise bei FB´s mit schnittstelle war mir klar. Wollt nur wissen ob ich an einer operation (bsp. UND) eine Interne und eine Globale variable abfragen darf. Aber das geht.

Frage zu verschaltungen allgemein: Wenn ich ein Real-Wert mit einem anderen Addiere und das Ergebnis auf < oder > vergleichen will, interessiert mich in erster Linie nicht das Zwischenergebnis der addition sondern nur das ergebnis des Vergleichs. ->

Ich kann nicht den Real Ausgang des ADD Bausteins an einen Eingang des CMP bausteins verschalten.
Ich muss das Zwischenergebniss zwingend in einer TEMP/Static Variable ablegen und mir im nächsten Netzwerk wieder abrufen?

Ich komm eigentlich von CFC zu TIA,... da war das alles ein wenig anders und auf den ersten Blick einfacher zu handeln

Aus P#DB1.DBX2.0 REAL lesi ich, dass du entweder ein 1500 mit standard Zugriff oder eine 300/400 verwendest.

Wie gesagt ist eine 3xxSC (Vipa) im einsatz die als 313C projektiert wird.

P#DB1.DBX2.0 REAL ist ein ANY Pointer der auf eine REAL ziegt die in DB1.DBD2 liegt. allns klor, min jung?

P# ist also Pointer? DB1.DBX2.0 gibt das erste Bit an ab dem mein Wert REAL beginnt? Richtig so?

zu den Farben: Das TIA Portal unterscheidet 5 Farben.
satte durchgezogene grüne Linien stehen für gerade beobachtetes TRUE
satte gestrichlte blaue Linien stehen für gerade beobachtetes FALSE
blass durchgezogene grüne Linien stehen für gewesenes beobachtetes TRUE
blass gestrichlte blaue Linien stehen für gewesenes beobachtetes FALSE
graue Linien kommen da wo noch nie was beobachtet wurde oder nichts beobachtet werden kann.

Wenn die Boxen grau bleiben, dann zumeist weil das ENO nicht angeschlossen ist. Scheinbar denkt S wenn dir das ENO egal ist, dann ist dir der Zustand der Box egal. Und irgendwie hat das auch Logik. Andererseits gibt es jedoch viele Situationen wo das ENO nicht angeschlossen ist, aber die Box trotzdem bunt wird. Das ist von Box zu Box verschieden und scheint auch noch vom Datentyp abzuhängen. seufz.

Der zweite Grund warum ganze Netzte grau bleiben sind Sprünge. Wenn man immer drüber spring, dann kann eben nichts beobachtet werden. Das scheint bei dir aber nicht der Fall zu sein, wenn das EN grün ist.

Kontakte und Spulen haben die Farbe des Operanden.
Boxen haben die Farbe des ENO bzw Q bzw OUT Ausgangs.
Die Farbe der Linien sagt etwas über ein Signal aus. Dieses entsteht aus der Verknüpfung.


Beispiel:

a +---------+ b
|----||----|EN ENO|----(R)

Von der Stromschiene kommt sattes grün, weil die immer TRUE ist. Das Wesen einer Stromschine.
der Kontakt hat die Farbe von a. Ist a true, dann ist der Kontakt grün. Ist a false, dann ist der Kontakt blau.
Die Linie zwischen Kontakt und Box ist das Verknüpfungsergebnis der UND-Verknüpfug von a mit TRUE, also a. Wenn a false ist, dann blau sonst grün.
Das geht nun so ins das EN.
Das ENO und die Box haben den gleichen Wert. ENO := EN and "erfolgreiche Boxausführung".
Die Linie zwischen ENO und Spule ist gleich ENO.
Die Spule zeigt den Wert von b. Da ich hier eine R-Spule genommen habe ist der false wenn von links ein true rein kommt.
Wenn a ber false war, dann ist auch EN und damit ENO false und damit wird b auch nicht zurück gesetzt und damit kann die Spule selbst grün bleiben.

Das spannende ist was der große S unter "erfolgreiche Boxausführung" versteht. Bei ADD und anderer Mathe ist das "kein Überlauf". Bei einen Anwenderbaustein, musst du den Programmierer desselben fragen.

Das sind mann so die Grundzüge des Ganzen.

Danke für die Ausführliche erklärung der Farben, kann es bei Multiinstanzen kommen das das ganze nicht "beobachtbar" wird? Kann ich nicht eine bestimmte Instanz eines FB´s beobachten? oder sehe ich immer nur einen Mischmasch aus allen instanzen?

'n schönene Tach auch

Danke dir auch und vielen Dank für die Super Erklärung! Gruß T

HB

Text im Zitat!

 

[hucki]

Text im Zitat!

Nicht so schön, weil man Dich dann nicht mehr einfach zitieren kann, um darauf zu antworten.
Besser an den betreffenden Stellen des Zitats per Hand ein [ / Q U O T E ] einfügen, Deine Antwort schreiben und den Rest des Zitates dann wieder mit [ Q U O T E ] beginnen (dann natürlich ohne die Leerzeichen). Diese Tags kann man sich ja auch einfach vom Anfang/Ende kopieren.

@admins,
gibt's da vlt. 'ne Möglichkeit, so 'ne Unterbrechung des Zitats über ein Icon zu automatisieren?

Ich kann nicht den Real Ausgang des ADD Bausteins an einen Eingang des CMP bausteins verschalten.
Ich muss das Zwischenergebniss zwingend in einer TEMP/Static Variable ablegen und mir im nächsten Netzwerk wieder abrufen?

In FUP/KOP musst Du zwischenspeichern, in AWL/SCL nicht unbedingt.

 

[HelleBarde]

Hi

Bei einer CPU von S sieht man immer nur Daten aus einer Ausführung.
Bei einer CPU von S kann man über die Aufrufumgebung auswählen, dass eine spezielle Instanz beobachtet werden soll.
Ob das beim Plagiat auch geht -- vermutlich nicht. Die Vipa die ich vor Jahren mal in den Fingern hatte war eine riesige Enttäuschung.

Forcen war freigeschaltet hat aber nicht funktioniert. Beobachten mit Aufrufumgebuing wurde nicht unterstützt. Haltepunkte auch nicht.

Ist ein paar Jahre her, vielleicht sind sie ja heute besser, aber ne CPU mit Lüfter, der im Schaltschrank nach drei Monaten regelmäßig ausfällt -- macht keinen Kunden froh.


Das man in KOP/FUP keine nicht Booleschen Werte verdrahten kann finde ich auch schade. Aber was CFC für einen Code absetzt ist nicht viel besser. Zugegeben es sieht besser aus, aber es läuft viel langsamer. Jeder Draht liegt als Wert in eine DB. Da dauert der Zugriff deutlich länger als der in die TEMP Sektion. Und mit jeder neuen CPU von S wird das besser. siehe
http://www.sps-forum.de/simatic/67616-awl-kop-oder-fup-new-post.html

Aber du verwendest ja keine CPU von S, VIPA macht das bestimmt schneller.

'n schön' Tach auch
HB

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Frage zu verschaltungen allgemein: Wenn ich ein Real-Wert mit einem anderen Addiere und das Ergebnis auf < oder > vergleichen will, interessiert mich in erster Linie nicht das Zwischenergebnis der addition sondern nur das ergebnis des Vergleichs. ->

Ich kann nicht den Real Ausgang des ADD Bausteins an einen Eingang des CMP bausteins verschalten.
Ich muss das Zwischenergebniss zwingend in einer TEMP/Static Variable ablegen und mir im nächsten Netzwerk wieder abrufen?

Ich komm eigentlich von CFC

Da krieg ich auch immer die Kriese, wenn ich anstatt CFC mal was in FUP machen muss... Aber das ist leider alles so...

@Hellebarde
PS: Und schade das es auch im Sooo Super tollen TIA immer noch so ist
:sm19:

 

[TIA_TESTER]

Da krieg ich auch immer die Kriese, wenn ich anstatt CFC mal was in FUP machen muss... Aber das ist leider alles so...

@Hellebarde
PS: Und schade das es auch im Sooo Super tollen TIA immer noch so ist
:sm19:

Danke für dein Mitgefühl!

Wenn ich die Wahl habe ob ich mich abquäle und für jedes Zwischenergebnis eine Variable definier oder das Programm das irgendwo reinpackt. dann wähle ich klar die Variante das es das Programm für mich erledigt, und solang das nicht verarbeitet werden muss ist es mir egal wo es am ende liegt, hauptsache die Sache läuft

Gruß T