TIA Array of Bool [0..7] ist 2 Byte groß, AT Operator kann nicht angewendet werden

timau · 1 April 2022

Hallo liebe Leute,

ich versuche folgendes:
ein KP8-Panel liefert über Profinet
1 WORD Eingang (8 Bools für Tasten, 8 Bools für DI)
1 DWORD Ausgang (3x8 Bools für RGB Zuweisung, 1x8 Bools für DO)

Jetzt wollte ich das symbolisch lesbarer machen und habe einen UDT für Eingänge und einen UDT für Ausgänge erstellt.
Dabei habe ich die Bools in Arrays organisiert.
Nun dachte ich dass ich bei Eingängen 2 Arrays [0..7] of BOOL am Ende eine Gesamtgröße des UDT von 2 BYTE hätte.
Das ist leider nicht so, da das System für jedes Array immer mind. 2 Byte veranschlagt, auch für eines [0..1].
Damit ist das UDT dann 4 Byte groß und passt natürlich nicht mehr in mein WORD. Daran scheitert dann auch der AT Operator.

Bei Beckhoff hätte ich einfach das Alignment auf 1 Byte geändert oder eine UNION benutzt und das Problem wäre gelöst.

--> Fällt jemandem hier etwas besseres ein als einen eigenen "Konverter-FC" zu schreiben mit dem ich mir die einzelnen Stellen rauspicke und ins WORD schreibe?

Viele Grüße,
Timo

MFreiberger · 1 April 2022

Moin timau,

ja, das ist so. JEDE Variable "verbraucht" eine gerade Anzahl an Bytes. Bei Variablen, die kleiner als ein Byte sind, sind das dann mind. 2 Byte (Bool, Array[0..7] of Bool, Byte, sint, usint, ...).

Du könntest ein Array[0..15] of Bool erstellen. Oder kein UDT, sondern einfach zweit Byte in einer Struktur.

VG

MFreibreger

PN/DP · 1 April 2022

timau schrieb:
1 WORD Eingang (8 Bools für Tasten, 8 Bools für DI)

Deklariere das doch einfach als das was es ist: ein Struct mit 16 einzelnen Bool
Warum sollen die Bits ein Array sein? Schreibfaul

?

Harald

DOD666 · 1 April 2022

Was ist wenn du die in ein strukt legst in dem du für Key und digitalIn wieder ein strukt machst und die alle bools als einzelnes Symbol hast?

Gruß
Jens

Thomas_v2.1 · 1 April 2022

PN/DP schrieb:
Deklariere das doch einfach als das was es ist: ein Struct mit 16 einzelnen Bool
Warum sollen die Bits ein Array sein? Schreibfaul ?

Und wie kann man auf die Struct mit 16 einzelnen Bools dann per Index zugreifen?

PN/DP · 1 April 2022

Thomas_v2.1 schrieb:
Und wie kann man auf die Struct mit 16 einzelnen Bools dann per Index zugreifen?

Wo steht denn daß er auf die 8 Tasten (mit sehr wahrscheinlich verschiedenen Funktionen) per Index zugreifen muß? Ist das neuerdings üblich, daß man auf alle Digitaleingänge von SPS per Index zugreift? Da kann man die Symbolik auch gleich ganz weglassen, wenn die Symbolik auch nur aus Nummern besteht.

Harald

hucki · 1 April 2022

PN/DP schrieb:
Ist das neuerdings üblich, daß man auf alle Digitaleingänge von SPS per Index zugreift? Da kann man die Symbolik auch gleich ganz weglassen, wenn die Symbolik auch nur aus Nummern besteht.

Der Index kann ja auch eine Konstante sein und durch deren Namen dann doch noch "sprechend" werden.

Thomas_v2.1 · 1 April 2022

PN/DP schrieb:
Wo steht denn daß er auf die 8 Tasten (mit sehr wahrscheinlich verschiedenen Funktionen) per Index zugreifen muß? Ist das neuerdings üblich, daß man auf alle Digitaleingänge von SPS per Index zugreift? Da kann man die Symbolik auch gleich ganz weglassen, wenn die Symbolik auch nur aus Nummern besteht.

Harald

Bla bla bla, nichts muss. Nur er hat es so, warum das dann immer gleich schreibfaul, zu blöd, zu modern ist, will mir nicht einleuchten.

Ralle · 2 April 2022

Thomas_v2.1 schrieb:
Bla bla bla, nichts muss. Nur er hat es so, warum das dann immer gleich schreibfaul, zu blöd, zu modern ist, will mir nicht einleuchten.

Was los @Thomas_v2.1, konntest du nicht einschlafen???

timau · 4 April 2022

Guten Morgen und danke für eure Antworten,
an die genannten Ansätze hatte ich auch gedacht, klar gehen die technisch alle. (einfach alles in ein Array,..Sub-Structs mit Bools,..
Und ja natürlich darf man das wenn man mag schreibfaul nennen, ich hätte jetzt eher gesagt ich versuche den Code kurz und automatisiert zu halten.
Für die Eingänge ginge das das mit den zwei Sub-Structs auch, da brauche ich keinen Index.
Bei den Ausgängen (seht ihr im Screenshot) ist es beim KP8 so, dass jede Taste beleuchtet werden kann, die Farbe setzt sich über drei Farbanteile zusammen.
Durch die drei Arrays (Red, Green, Blue) kann auf Taste 0 mit dem der Array Position Zugriff [0] zugegriffen werden etc. Dadurch ist der Code über eine übersichtliche For-Schleife abgehandelt. Im Ergebnis sehe ich übersichtlich anhand des Index welche Anteile tatsächlich geschaltet wurden.
Wenn ich hier z.B. ein Array [0..31] nutze könnte ich mit Offsets arbeiten, habe dann aber auch wieder 3xFarben + 1xDO gemischt.

Anmerkung: Bei anderen Systemen könnte ich das lösen, ich hatte gehofft dass es bei TIA vielleicht auch einen Weg gibt. Ansonsten muss ich halt einen der Kompromisse oben wählen oder mir einen Konverter Baustein schreiben und mehr tippen

.

Für die die es der Vollständigkeit halber interessiert, bei Beckhoff wäre das Sichtwort "Alignment" https://infosys.beckhoff.com/index.php?content=../content/1031/tc3_plc_intro/3539428491.html&id= .

Viele Grüße,
Timo

timau · 4 April 2022

DOD666 schrieb:
Was ist wenn du die in ein strukt legst in dem du für Key und digitalIn wieder ein strukt machst und die alle bools als einzelnes Symbol hast?

Gruß
Jens

Hi Jens, das geht leider nicht ganz auf, war jetzt mein Versuch mit Verlust des Index, aber auch hier gilt dass jede Variable, wohl auch jedes Sub-Struct mind. 2 Byte groß ist

DOD666 · 4 April 2022

OK, dachte bei einem Strukt würden die da nicht eingreifen.

MFreiberger · 4 April 2022

Moin timau,

ja, mit den KP8 habe ich mich auch etwas auseinandergesetzt bzw. geärgert.

Unsere Lösung sieht folgendermaßen aus:

Für jedes KP8 gibt es eine FC. Die E/As haben wir für die Eingänge als Array[0..7] of Bool angelegt; die Ausgänge als Array[0..31] of Bool (wobei natürlich die Indizes folgendermaßen vergeben sind: 0..7 = rd (rot), 8-15 = gn (grün) und 16-23 = bl (blau). Das sind ja zunächst einmal die E/A-Bereiche, die ein KP8 zur Verfügung stellt.

In einem (optimierten) DB haben wir für jedes KP8 ein Array[0..7] of UDT angelegt. Die UDT enthält drei boolsche Variablen (rd, gn, bl).

Die Bits in dem DB werden später im Programm "bespaßt und folgendermaßen den Ausgängen zugewiesen:

Code:

FOR #i := 1 TO 3 DO
    FOR #j := 0 TO 7 DO
        CASE #i OF
            1: // rot zuweisen
                #k := #j;
                "Output_KP8_1".COLOR_rgb[#k] := "DB".KP8_1.COLOR_rgb[#j].rd; // erste KP8; falls weitere folgen, ist eine weitere Zeile erforderlich
            2: // grün zuweisen
                #k := #j + 8;
                "Output_KP8_1".COLOR_rgb[#k] := "DB".KP8_1.COLOR_rgb[#j].gn; // erste KP8; falls weitere folgen, ist eine weitere Zeile erforderlich
            3: // blau zuweisen
                #k := #j + 16;
                "Output_KP8_1".COLOR_rgb[#k] := "DB".KP8_1.COLOR_rgb[#j].bl; // erste KP8; falls weitere folgen, ist eine weitere Zeile erforderlich
        END_CASE;
    END_FOR;
END_FOR;

Aber jetzt muss ja noch im DB die "richtige" Farbe angewählt werden. Dazu haben wir den Farben Werte zugewiesen, die dem Dualcode der Ausgänge zu den Farben entspricht:
0 = AUS (0000b)
1 = rot (0001b)
2 = grün (0010b)
3 = gelb (0011b)
4 = blau (0100b)
5 = -
6 = -
7 = weiß (0111b)

Dazu haben wir einen weiteren DB, in dem die Farbwerte als Bytevariablen deklariert sind. Jede Taste hat dabei zwei Farben (Grund- und Blinkfarbe) jeweils als Array[0..7] of Byte, ein Array[0..7] of Bool "FlashActiv", ein Array[0..7] of Bool "operable" und je ein Array[0..7] of Bool für jede der drei Farben.

Jetzt muss der Programmierer beim Einsatz eines KP8 folgendes programmieren:
Je nach Zustand:
Basisfarbe, Blinkfarbe, blinkenAktiv

Dann wird jede Taste folgendermaßen ausgewertet:
operable = Basisfarbe <> 0 or blinkenAktiv

Dann wird das Tastsignal nur dann einem Funktionssignal zugeordnet und übergeben, wenn operable = true ist.

-----------------------

So. Warum der ganze Aufwand?
- weil es zu oft vorkam, dass eine Taste beleuchtet war, aber sich bei der Betätigung nichts tat
- oder umgekehrt: die war nicht beleuchtet und der Bediener wusste nicht, dass da eine Funktion hinter aktiv ist.
- weil das programmieren der Farben besonders beim Blinken oder Farbwechseln zu kruden, undurchsichtigen Logikverschaltungen führte, die Niemand mehr durchblickt hat (besonders: wann muss welches Bit aktiv sein, um welche Farbe zu erhalten; besonders schlimm bei Falbkombinationen, die Blinken sollten!).

Diese Programmierung ist tatsächlich entstanden, um den Programmierern und Inbetriebnehmern im Feld die Arbeit zu erleichtern.
Beispiel (mehr braucht dann nicht mehr für einen Taster programmiert werden):

Kurze Erläuterung:
Basisfarbe = 0
Blinkfarbe = 0

Wenn der Schlüsselschalter auf AUTO => Basisfarbe = 2 (grün)
Wenn der Schlüsselschalter auf MANU => Basisfarbe = 7 (weiß)

Weder AUTO noch MANU aktiv => Blinken aktiv
========
Also Schlüsselschalter aus => Basisfarbe = 0 und Blinken aktiv => Taster nicht bedienbar bzw. funktionslos
Schlüsselschalter auf AUTO => Basisfarbe = 2 und Blinken aktiv => Taster blinkt grün und ist bedienbar (einschalten der Betriebsart "AUTO")
Schlüsselschalter auf AUTO und eingeschaltet => Basisfarbe = 2 und Blinken nicht aktiv => Taster dauergrün, Anzeige eingeschaltet

VG

MFreiberger

TIA Array of Bool [0..7] ist 2 Byte groß, AT Operator kann nicht angewendet werden

timau

Level-2

MFreiberger

Level-3

PN/DP

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

DOD666

Level-2

Thomas_v2.1

Level-3

PN/DP

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

hucki

User des Jahres 2014

Thomas_v2.1

Level-3

Ralle

Super-Moderator , User des Jahres 2006-2007

timau

Level-2

timau

Level-2

DOD666

Level-2

MFreiberger

Level-3

Similar threads

Wir schützen deine Privatsphäre