TIA FC-Bausteinschnittstelle Byte deklariert, Bit-Zugriff

Krumnix

Level-3
Beiträge
1.454
Reaktionspunkte
190
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo.

Hab TIA v13 und möchte einem FC ein paar Signale übergeben. Da es recht "viele" sind, dachte ich mir, zwecks übersicht, das ich sie als Byte übergebe.
Hab also in der Bausteinschnittstelle 4 Eingangswörter als Byte deklariert.

Bei Step7 hab ich dann immer diese auf eine Temp-Variable umkopiert und dann z.B. L#0.0 geschrieben.
Bei TIA ändert er das automatisch auf %L0.0 um.

Beim Übersetzen merkert er aber, das
1. absolute Zugriffe nicht schön sind und
2. Einen Typkonflikt an der Stelle, wo ich %L0.0 geschrieben habe.

Die im Handbuch beschriebene Version mit #TempVar.%x1 funktioniert nicht, da meine SPS dies nicht unterstüzt.

Jemand noch andere Ideen? Ich will nicht 32 Einzeleingänge anlegen -.-
 
300/400 Cpu?

In SCL könntest du mit AT-Sicht arbeiten.

In AWL könntest du mit nem Pointer auf ein Array of Bool (oder struct) im Temp arbeiten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
WinAC RTX :)
SCL wollte ich vermeiden, da Instandhalter den Baustein auch verstehen sollen. Und da gibt es leider zu viele bei uns, die das nicht können.
Array hab ich schon versucht, muss ich aber von Extern an den Baustein auch als Array übergeben. D.H. ich muss alle DBs nochmal anfassen und von Typ Byte auf Array of Bool umstellen.
Viel Arbeit, wenns anders möglich wäre :)

Ich will das wieder von Step7 haben!:grin:
 
Array hab ich schon versucht, muss ich aber von Extern an den Baustein auch als Array übergeben. D.H. ich muss alle DBs nochmal anfassen und von Typ Byte auf Array of Bool umstellen.
Nö, so war es nicht gemeint.

Code:
//B_IN => Byte am IN
//B_IN_ARRAY => Array[0..7] of Bool in Temp (Könnte auch eine Struktur sein)

L     P##B_IN_ARRAY
LAR1                        //Pointer auf Array
L     #B_IN
T     LB [AR1,P#0.0]   //Byte kopieren
Sofern TIA das noch ohne zu meckern akzeptiert.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also die "alte" Version funktioniert. Man muss nur die Compiler-Warnungen umstellen, das er auch übersetzt. Zwar hab ich dann 32 Warnungen, aber die Fehler wegen Typkonflikt sind weg.
Jetzt muss es nur noch in der Steuerung laufen, das kann ich aber erst morgen testen...
 
Info: Funktioniert!


z.B.:
#IN_R #IN_1 %L0.0
|----| |------|/|----------( )

Aber das halte ich wirklich für die denkbar schlechteste Lösung!
Unübersichtlich und tatsächlich auch gefährlich, wenn später noch jemand lokale Variablen deklariert, gibt es u.U. Überschneidungen und böse Effekte.
Warum legst du nicht eine Struktur an, die du dann in einem DB definierst. Diese Struktur kannst du im FC in der IN-, OUT- oder noch besser INOUT-Schnittstelle einfügen und beim Aufruf des FC antragen.
Gefüllt wird diese Struktur dann genauso, wie du das oben zeigst, nur nicht auf Lokaldaten, sondern auf den DB. Das wäre m.E. nach viel sauberer, verständlicher und auch für jeden nachvollziehbar.
Im FC kannst du dann mit den Elementen der Struktur arbeiten.
 
Jungs, nicht aufregen :)
Ich muss eine alte Version nutzen, da 60% unser Anlagen noch S5 sind und somit die Instandhalter das gewöhnt sind.
Es bringt mir nix, wenn ich was top modernes und optimales einsetze, wo nachher nur 2-3 Leute das verstehen.
Ich hab keine Lust Nachts angerufen zu werden, wenn die Anlage steht, nur weil ich es "sauber" programmiert habe.
Dann sterbe ich lieber diesen Tot :)
 
Ach, regt sich doch keiner auf.
Aber vielleicht solltest du deine Instandhalter mal ein wenig mitnehmen und schulen oder so, denn sonst machst du in 10 Jahren noch solche leckeren Konstrukte. :ROFLMAO:
 
Zurück
Oben