Step 7 [SCL] IN1, IN2, .., INX indirekt adressieren ?

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Oh, iss ja gar nicht so schlimm mit den Ressourcen. Ich hatte das irgendwie anders in Erinnerung. Aber ich finde es gut dass wir mal darüber gesprochen haben .

 

[JesperMP]

Warum kann man nicht den 'normalen' Verfahren verwenden, d.h. je 'Objekt' ein FB Aufruf mit ein IDB. Ob da 50-100 FB Aufrufe gibt mit je ein IDB, geht das programmieren einfach und schnell wenn man den Symbolik so erstellt hat das man den E/A Schnell durch suchen-und-ersetzen für die FB Aufrufe aktualisieren kann.

Logik durch indirekte Addressierung und Schleifen (egal welche Verfahren) finde ich problematisch. Wenn es funktioniert ist es gut, wenn da Probleme gibt ist es ein Alptraum.

Das es gibt viele gleichartige 'Objekte' von denselben Typ ist ja nichts spezielles. Genau dafür hat man FBs + IDBs.
Es ist wenig "Ressourcenfressend".
Es ist einfach zum debuggen.
Ist diese Idee mit "durchschleifen" dadurch gekommen weil der Programmierer zu faul ist die E/As einzutippen ?

 

[Flux]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mal ne ganz banale frage, wieso kann ich denn meine IN_OUTs (Slave, Kopfbst) nicht miteinander verbinden im CFC ?? {S7_link := 'true'}

Warum kann man nicht den 'normalen' Verfahren verwenden, d.h. je 'Objekt' ein FB Aufruf mit ein IDB. 8...9Ist diese Idee mit "durchschleifen" dadurch gekommen weil der Programmierer zu faul ist die E/As einzutippen ?

Ne, aber dann müsste ich jeden FB mit allen relevanten Signalen mit dem einen Treiberbaustein verbinden. Außerdem bräuchte ich nach wie vor eine Logik, die entscheidet welcher Slave nun senden/empfangen darf - das dezentral zu halten ist ein alptraum.
In meinem Konstrukt verbinde ich jeden Slavebaustein (der nur zur Slaveparametrierung und Sollwert/Messwert verschaltung dient) per UDT an einen Kopfbaustein, der zentral die Slaves verwaltet und nur einmal an die relevanten Signale des Treiberbaustein verbunden ist.

 

[Flux]

"Mal ne ganz banale frage, wieso kann ich denn meine IN_OUTs (Slave, Kopfbst) nicht miteinander verbinden im CFC ?? {S7_link := 'true'}"

Ich steh diesbezüglich grad echt aufm Schlauch

PS: PCS 7 V8.0.1.1 --> CFC V8.0.3 (der momentan aktuellste)

 

[Flux]

Inout mit inout verknüppeln geht nicht, war wohl eine fehlannahme. Habe nun eine andere Lösung gefunden

 

[Flux]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,
hab nun eine Lösung gefunden, bin aber mit der Art der Adressierung nicht zufrieden.

Lösung:
Global-DB (DB1, "DATA", enthält "Slave" (Array[1..100] of UDT)) anlegen. Aus FB lesend und
schreibend adressierbar per "DATA".Slave[Slave_ID]. ... / DB1.Slave[Slave_ID]. ...
Nun würde ich gerne den DB variabel halten, indem er von außen anparametriert wird. Mir ist
bisher nur folgender Weg bekannt: z.B. 'DB77' --> IN : BLOCK_DB --> DB_Var.
Leider kann ich dann nurnoch absolut über DB_Var.DBW[ID] durch die Datenstruktur navigieren

FRAGE: wie kann ich trotz 'DB-Platzhalter' (im FB) durch die UDT-Struktur im Global-DB per Index
navigieren ?

Gruß
Flux

 

[PN/DP]

Das Array aus dem übergebenen DB in eine gleichartige Struktur in TEMP umkopieren.
Oder halt das komplette Array als Array of UDT übergeben.
Oder das Array of UDT direkt in STAT des FB anlegen.

Harald

 

[Flux]

Hallo Harald,
danke für deine Antwort, habe noch ein Paar Fragen dazu:

Das Array aus dem übergebenen DB in eine gleichartige Struktur in TEMP umkopieren.

Im FB: TmpArr := DB_Var.Slave ? Wie gesagt, bei "Slave" meckert nun der Compiler, da der DB erst zur Runtime bekannt ist.

Oder halt das komplette Array als Array of UDT übergeben.

Ok, das wäre aus Sicht des Kopfbausteins: DBx.Slave --> IN_OUT: Slave : Array[1..100] of UDT

Aus Sicht des Slaves wäre es: DBx.Slave[1] --> IN_OUT: Slave : UDT

So?

Oder das Array of UDT direkt in STAT des FB anlegen.

Aus Sicht des Kopf-Bst. am einfachsten.
Aber wie schreiben die Slaves darein? Absolut wie in der Variante hierdrüber? Das Problem dabei ist, dass die Instanz-DBNr. des Kopf-FB jedesmal nach dem Übersetzen eine andere sein kann (PCS 7 halt)..

 

[Flux]

Zuviel Werbung?
-> Hier kostenlos registrieren

Mir ist noch eingefallen, dass wenn man IN : BLOCK_DB nimmt, man zwar nur auf die nackigen Bitdatentypen zugreifen kann (die UDT-Struktur also dahin ist), man die Struktur wiedergewinnen sollte, wenn man eine entsprechende Sicht (AT) auf den Datenbereich anwendet.

Letztendlich habe ich ein UDT für OUT und eins für IN erstellt, um darüber zu kommunizieren - hat den Vorteil, dass man die Verbindung der beiden Bausteine einfacher nachvollziehen kann (Randleistensprung).


Danke für alle Antworten!

Flux

 

[larry]

Wenn man IN_OUT braucht dann muß man selbstverständlich IN_OUT benutzen - egal was es kostet.

Meinen Vergleich habe ich gebracht, weil Du behauptet hast, das ressourcenfressende Vergrößern des Programmcodes gäbe es nur bei KOP/FUP/AWL aber nicht bei SCL. Und das ist leider nicht korrekt.



Im FB egal ob Zugriff auf IN/OUT/STAT oder TEMP: 4 Byte
Zugriff auf eine Variable in einem UDT an IN_OUT: 26 Byte bei SCL-Quelle bzw. 42 Byte bei KOP/FUP/AWL-Quelle
Auch deshalb ist es oft sinnvoll, UDT zur Verarbeitung zuerst von IN_OUT in TEMP zu kopieren.

Codegröße ermitteln:
- SCL Quelle übersetzen
- den erzeugten Baustein in einen anderen Bausteine-Ordner kopieren
- da den Baustein öffnen - man sieht den erzeugten AWL-Code
- den Baustein einmal speichern --> Bausteingröße wird nun 2 Byte größer als das SCL-Compilat
- diese Bausteingröße merken --> als Bausteingröße_vorher
- nun den interessierenden Code löschen oder auskommentieren
- den Baustein speichern --> Bausteingröße_vorher minus Bausteingröße_jetzt entspricht dem Bedarf des Codes

Harald

Thank you for your detailed explanation, I already understand the efficiency when comparing the code size
I'm going to follow the steps you said to learn more about code size

 

[larry]

Wenn man IN_OUT braucht dann muß man selbstverständlich IN_OUT benutzen - egal was es kostet.

Meinen Vergleich habe ich gebracht, weil Du behauptet hast, das ressourcenfressende Vergrößern des Programmcodes gäbe es nur bei KOP/FUP/AWL aber nicht bei SCL. Und das ist leider nicht korrekt.



Im FB egal ob Zugriff auf IN/OUT/STAT oder TEMP: 4 Byte
Zugriff auf eine Variable in einem UDT an IN_OUT: 26 Byte bei SCL-Quelle bzw. 42 Byte bei KOP/FUP/AWL-Quelle
Auch deshalb ist es oft sinnvoll, UDT zur Verarbeitung zuerst von IN_OUT in TEMP zu kopieren.

Codegröße ermitteln:
- SCL Quelle übersetzen
- den erzeugten Baustein in einen anderen Bausteine-Ordner kopieren
- da den Baustein öffnen - man sieht den erzeugten AWL-Code
- den Baustein einmal speichern --> Bausteingröße wird nun 2 Byte größer als das SCL-Compilat
- diese Bausteingröße merken --> als Bausteingröße_vorher
- nun den interessierenden Code löschen oder auskommentieren
- den Baustein speichern --> Bausteingröße_vorher minus Bausteingröße_jetzt entspricht dem Bedarf des Codes

Harald

How can I use STEP7 to check how many bytes of this code size?

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

How can I use STEP7 to check how many bytes of this code size?

 

[larry]

Anhang anzeigen 83272

Anhang anzeigen 83269

Thanks for your help, I found it

 

[PN/DP]

How can I use STEP7 to check how many bytes of this code size?

 

[larry]

Zuviel Werbung?
-> Hier kostenlos registrieren

SCL "frisst" in dem Fall zwar tatsächlich etwas weniger Ressourcen als AWL, frisst aber auch. Um die Adressberechnung zum UDT-Member an INOUT kommt auch SCL nicht herum. (mal abgesehen von möglichen Compiler-Optimierungen bei Folge-Zugriffen auf andere Variablen des selben INOUT-UDT)

Wird der UDT an IN eines FB übergeben, dann benötigt SCL genau wie AWL 4 Byte Programmcode für den Zugriff auf eine INT-Variable aus dem UDT.
Wird der UDT an INOUT eines FB übergeben, dann benötigt AWL 42 Byte Programmcode, SCL benötigt "ressourcensparend" nur 26 Byte.

Harald

You said that the size of the code is 42 bytes for INOUT, and the size of IN or OUT and TEMP is 4 bytes, and I did an experiment and found that the size of MC7 matches?

 

[PN/DP]

Write an instruction like A #XS_Status.Bool1 and save, then you will see that the code size increases by 42 bytes.
"MC7" is the pure code size of the instructions ("machine code S7").
"Work Memory Requirement" is the memory requirement of the block with a block header or frame for managing the block in the working memory (for dynamic loading and deleting of the block). I guess the header/frame size is 36 or 38 bytes (check: save an empty block without code).

PS: Would it make sense if you post further questions in your own thread?

 

[larry]

Write an instruction like A #XS_Status.Bool1 and save, then you will see that the code size increases by 42 bytes.
"MC7" is the pure code size of the instructions ("machine code S7").
"Work Memory Requirement" is the memory requirement of the block with a block header or frame for managing the block in the working memory (for dynamic loading and deleting of the block). I guess the header/frame size is 36 or 38 bytes (check: save an empty block without code).

PS: Would it make sense if you post further questions in your own thread?

According to what you said, I tried it, it was indeed 42 bytes or 4 bytes, thank you very much for your help, and I learned another exciting question