Step 7 indirekt auf Eingänge eines FC´s zugreifen

H

HelmiMUC

Level-1
Beiträge
95
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ist es möglich, indirekt auf die Eingänge eines FC´s zuzugreifen?
Ich möchte einen Baustein basteln, der die FC-Eingänge auf Merker umlädt und das am besten indirekt
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Larry Laffer schrieb:
Erklär mal etwas ausführlicher.
Was willst du so erreichen ?
Zum Vergrößern anklicken....

einfaches Beispiel:
Ich hab acht FC-Eingänge und diese möchte ich auf ein Merkerbyte schreiben (1:1)

Dies möchte ich aber nicht mit 8 Zuweisungen machen
Code: 
U Eingang1
= Merker1
U Eingang2
= Merker2
//usw.

sondern in einer Schleife - die 8 Durchläufe hat und sich bei jedem Durchlauf
den jeweiligen Eingang auf ein Merker-Bit schreibt

In einem FB ist das ja problemlos möglich (die Eingänge liegen ja in der Instanz und
haben eine Adresse) - aber in einem FC?
 
Diese vermeintlich "clevere" Schweinerei wird immer wieder angefragt, doch es geht nicht in einem FC.
Mache die 8 einzelnen Zuweisungen, das ist effizienter als die umständliche Adressrechnerei und Schleifenbehandlung und obendrein sogar noch gut lesbar und von jedermann verstehbar. :cool:

Willst Du wirklich in dem FC direkt auf Merkerbits schreiben?!? Oder doch besser die 8 Bits in ein FC-internes Byte sammeln und dann das Byte über einen FC-Out zurückgeben? Dann kopiere die Bits über eine Struktur in TEMP. Das geht sogar sauber symbolisch.

Welches Step7 und welche CPU willst Du verwenden?

Harald
 
Dass es auch andere Wege gibt, ist mir klar
normalerweise pointere ich das durch und gut ist (Schweinerei ist es nur, wenn man es nicht versteht)
Habs aber gerade mal selbst im FC ausprobiert
ein P##Eingang geht nicht (wird rot markiert)

habs in S7 V5.5 und einer 319 gemacht
 
Zuviel Werbung?
-> Hier kostenlos registrieren
HelmiMUC schrieb:
Dass es auch andere Wege gibt, ist mir klar
normalerweise pointere ich das durch und gut ist (Schweinerei ist es nur, wenn man es nicht versteht)
Habs aber gerade mal selbst im FC ausprobiert
ein P##Eingang geht nicht (wird rot markiert)
Zum Vergrößern anklicken....
Exakt das kommt davon wenn man die eigenen Schweinereien nicht versteht, wenn man keine Ahnung hat von dem was man eigentlich tut. :ROFLMAO:

Ein P##Eingang geht doch, z.B. "L P##Eingang" - nur liefert das möglicherweise nicht das was Du erwartest. Außerdem funktioniert das unterschiedlich, je nachdem was für einen Aktual-Parameter man dem FC übergibt. Nur einmal testen und denken es ist gut, ist nicht genug. Also besser: vergiss es.

Als Anregung für eine tatsächlich funktionierende "Schweinerei" siehe mal hier den Code für den umgekehrten Weg von Word zu Bit. Sollte für Dich ja einfach zu ändern sein.

Harald
 
HelmiMUC schrieb:
Das Beispiel hinkt - das greift auf den Local-Bereich indirekt zu und nicht auf Eingänge
Zum Vergrößern anklicken....
Ach, hast Du Schwierigkeiten, das Beispiel passend zu Deiner Aufgabe zu ändern? Du, der normalerweise sowas einfach "durchpointert und gut ist"? Du enttäuschst mich. :roll:

Nochmal: es ist in einem FC nicht möglich, indiziert auf die Eingangsparameter zuzugreifen. Deshalb besteht die Lösung Deiner Aufgabe darin, die Eingänge zunächst in eine Temp-Bit-Struktur zu kopieren und zum symbolischen Lesen der Struktur als Byte oder Word indirekt auf die Temp-Struktur zuzugreifen.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
PN/DP schrieb:
Ach, hast Du Schwierigkeiten, das Beispiel passend zu Deiner Aufgabe zu ändern? Du, der normalerweise sowas einfach "durchpointert und gut ist"? Du enttäuschst mich. :roll:
Zum Vergrößern anklicken....
Erklär mir bitte den Zynismus den du damit an den Tag legst?

PN/DP schrieb:
Nochmal: es ist in einem FC nicht möglich, indiziert auf die Eingangsparameter zuzugreifen. Deshalb besteht Deine Lösung darin, die Eingänge zunächst in eine Temp-Bit-Struktur zu kopieren und zum symbolischen Lesen der Struktur als Byte oder Word indirekt auf die Temp-Struktur zuzugreifen.
Zum Vergrößern anklicken....
Auch wenn du jetzt etwas genervt erscheinen willst:
Ich habe ja geschrieben, dass es bestimmt verschiedene Wege gibt - ich fragte ja nach dem indirekten Abfragen von Eingängen und nicht die des Temp-Bereichesgefragt
 
wie gesagt, wer Zynismus an den Tag legt, sollte ihn auch belegen!
Und falls man des Lesens mächtig ist: In meinem zweiten Post steht: "einfaches Beispiel" und mag mit der reelen Aufgabenstellung
wenig bis nichts zu tun haben!

Und manchmal ist es einfacher mit wenigen Zeilen Code ein Problem zu lösen, als sich mit vielen Zeilen Code Freunde zu machen!
 
es scheint trotz FC zu gehen:

Code: 
VAR_INPUT
  Eingang_1 : BOOL ; 
  Eingang_2 : BOOL ; 
  Eingang_3 : BOOL ; 
  Eingang_4 : BOOL ; 
  Eingang_5 : BOOL ; 
  Eingang_6 : BOOL ; 
  Eingang_7 : BOOL ; 
  Eingang_8 : BOOL ; 
END_VAR
VAR_TEMP
  LoopCount : INT ; 
END_VAR
BEGIN
NETWORK
TITLE =
      L     P##Eingang_1; 
      LAR1  ; 
      L     B [AR1,P#0.0]; 
      T     MB   520; 
END_FUNCTION

jedenfalls kommen meine Eingänge richtig im MB520 an
Wie sicher das ganze ist, muss ich noch rausfinden
 
wer sagt, dass die Eingänge, die aussen am FC angegeben werden, auch bit-aufsteigend sind?
und wer sagt, dass das nur Eingänge sind und nicht auch Merker-Bit oder DB-Bits sind?

Aber um das Thema abzuschließen:
Es geht doch Eingänge eines FC´s indirekt anzusprechen
(was ja meine eigentliche Frage war)
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
HelmiMUC schrieb:
wer sagt, dass die Eingänge, die aussen am FC angegeben werden, auch bit-aufsteigend sind?
und wer sagt, dass das nur Eingänge sind und nicht auch Merker-Bit oder DB-Bits sind?
Zum Vergrößern anklicken....
Auß einem relativ simplen Grund, weil du letzten Endes die Adresse des Außen angelegten Operanden ins AR1 lädst,
womit dein Code bereichsübergreifend schon mal gar nicht funktionieren kann, und falls an Ein1 etwas anderes als "Bit0" steht, geht die Kiste auf Stop.

Was wiederum heißt, das dein Code einem normalen L / T entspricht, Ein2-8 sind absolut bedeutungslos, die könntest du genau so gut auch löschen, ohne die geringste Auswirkung auf deinen Schnipsel.

Also wer sagt, das dein Code das was du da von dir gibst überhaupt gewährleisten kann ...
 
Zuletzt bearbeitet:
HelmiMUC schrieb:
es scheint trotz FC zu gehen:

Code: 
VAR_INPUT
  Eingang_1 : BOOL ; 
  Eingang_2 : BOOL ; 
  Eingang_3 : BOOL ; 
  Eingang_4 : BOOL ; 
  Eingang_5 : BOOL ; 
  Eingang_6 : BOOL ; 
  Eingang_7 : BOOL ; 
  Eingang_8 : BOOL ; 
END_VAR
VAR_TEMP
  LoopCount : INT ; 
END_VAR
BEGIN
NETWORK
TITLE =
      L     P##Eingang_1; 
      LAR1  ; 
      L     B [AR1,P#0.0]; 
      T     MB   520; 
END_FUNCTION

jedenfalls kommen meine Eingänge richtig im MB520 an
Wie sicher das ganze ist, muss ich noch rausfinden
Zum Vergrößern anklicken....
:ROFLMAO:
Soll ich mich nochmal "zynisch" selber zitieren, bzgl. man sollte verstehen was man tut und daß nur einmal testen nicht reicht? ;)

HelmiMUC schrieb:
wer sagt, dass die Eingänge, die aussen am FC angegeben werden, auch bit-aufsteigend sind?
und wer sagt, dass das nur Eingänge sind und nicht auch Merker-Bit oder DB-Bits sind?

Aber um das Thema abzuschließen:
Es geht doch Eingänge eines FC´s indirekt anzusprechen
(was ja meine eigentliche Frage war)
Zum Vergrößern anklicken....
Vielleicht solltest Du hier nicht nur trotzig geheimnisvoll 'rumtönen sondern auch mal wirklich testen, was Du da behauptest. Also mal mit verschiedenen nicht aufsteigenden Eingangsbelegungen und gemischt aus den Bereichen E, A, M, L, DBX und evtl. Konstante testen. Vielleicht beobachtest Du auch mal Deinen Code und besonders was das "L P##Eingang_1" ergibt?

Wie schon mehrmals gesagt: es geht nicht. Höchstens als zufällig funktionierende Schweinerei.

Von mir aus können wir das Thema nun abschließen. :cool:

Harald
 
PN/DP schrieb:
Also mal mit verschiedenen nicht aufsteigenden Eingangsbelegungen und gemischt aus den Bereichen E, A, M, L, DBX und evtl. Konstante testen. Vielleicht beobachtest Du auch mal Deinen Code und besonders was das "L P##Eingang_1" ergibt?
Zum Vergrößern anklicken....
Das hatten wir doch schon x-mal.
Hier in dem Beitrag (#9) hatte ich sogar Screenshots gepostet was man wirklich bekommt wenn man versucht indirekt auf FC-IN/OUT zuzugreifen...
http://www.sps-forum.de/simatic/740...ung-auf-bzw-out-schnittstelle-eines-fc-s.html
@HelmiMUC: Sieh dir die Screenshots mal an, dann weißt du worauf PN/DP und MSB so pochen...

Nachdem du das gelesen hast sehen wir uns nochmal deinen Vorschlag an....
HelmiMUC schrieb:
es scheint trotz FC zu gehen:
Code: 
VAR_INPUT
  Eingang_1 : BOOL ; 
  Eingang_2 : BOOL ; 
  Eingang_3 : BOOL ; 
  Eingang_4 : BOOL ; 
  Eingang_5 : BOOL ; 
  Eingang_6 : BOOL ; 
  Eingang_7 : BOOL ; 
  Eingang_8 : BOOL ; 
END_VAR
VAR_TEMP
  LoopCount : INT ; 
END_VAR
BEGIN
NETWORK
TITLE =
      L     P##Eingang_1; 
      LAR1  ; 
      L     B [AR1,P#0.0]; 
      T     MB   520; 
END_FUNCTION
Zum Vergrößern anklicken....
1. Wenn an Eingang_1 was anderes als X.0 steht, hast du ein Problem - MSB schrieb's ja schon

HelmiMUC schrieb:
wer sagt, dass die Eingänge, die aussen am FC angegeben werden, auch bit-aufsteigend sind?
und wer sagt, dass das nur Eingänge sind und nicht auch Merker-Bit oder DB-Bits sind?
Zum Vergrößern anklicken....
2. Beide Vorgaben werden leider nicht erfüllt... Immer aufsteigend.... E/A/M/DB mischen ist auch nicht (siehe Punk 3 und 4)....

3. Wenn an Eingang_1 (Baustein in AWL aufgerufen) ein E0.0 steht und an Eingang_2 ein M0.0 dann bekommst
du mit dem Lade-Befehl das EB0. M0.0 verlierst du. Du würdest dabei auch wirklich auf EB0 zugreifen​
4. Der selbe Fall wie 2. (Funktion in FUP aufgerufen) heißt dass du den Inhalt von E0.0 und M0.0 als erste 2 Bits bekommen würdest....
Du würdest auch nicht direkt auf EB0 oder MB0 zugreifen, sondern auf Lokaldaten der Aufrufumgebung...​

Wie du siehst ist das brandgefährlich, ein FC der seine "Funktion" ändert nur weil man ihn in FUP oder AWL aufruft, sowas darf's nicht geben!

Die einzige, wirklich einzige, Lösung ist der einzelne, bitweise Zugriff...
Wenn du die 8 IN-Bits z.B. als gesammeltes Byte weitergeben willst, kann man schon FC-intern über Temps in ein wenig "indirekt" arbeiten.


silverfreaky schrieb:
:ROFLMAO: Also das verstehe ich auch nicht.Mit einer Kanone auf einen Spatz geschossen. :ROFLMAO:
Zum Vergrößern anklicken....
Wobei der Schuss in dem Fall wohl meist nach hinten los gehen wird..
 
Zuletzt bearbeitet:

Similar threads

J
Step 7 Kein Wert nach Open-DB
Antworten
8
Aufrufe
519
PN/DP
PN/DP
J
TIA Simulierbarkeit eines FC nicht aktivierbar
Antworten
11
Aufrufe
474
Michitronik
M
S
TIA AWL Probleme mit LD Zugriff in FC bei TIA V17
Antworten
14
Aufrufe
628
StallionP51
S
B
TIA Indirekt auf mehrere DB`s zugreifen bei unterschiedlichen Array Längen
Antworten
19
Aufrufe
1K
Max Huber
M
M
LOGO Siemens LOGO mehrere Eingänge gegenseitig sperren
Antworten
12
Aufrufe
767
hucki
hucki
Zurück
Oben