Grundsätzlices zum Aufbau von FC's und FB's
Hallo @All
Und der Weg zur Hölle ist mit guten Vorsätzen gepflastert...
Das ist mir so in den Sinn gekommen, als ich über den Stand des Projektes nachgedacht habe. Ich hab diesen Satz dann auch gleich für meine Signatur übernommen und wir werden sehen, ob uns der Teufel überhaupt haben will.
"Gemeinsamkeiten C <-> Step7" ist vielleicht nicht unbedingt die passende Überschrift für diesen Thread aber ich belasse es dabei.
Mein Antrieb zu diesem Projekt war u.a., das ich mich über SCL geärgert habe, dass ja von Siemens so vollmundig an PASCAL angelehnt wurde aber nicht einmal das mindeste einhält, was man hätte erwarten können. Es gibt z.B. in AWL die Möglichkeit einen Wert vom Typ TIME in den AKKU zu laden und diesen dann ganz ungeniert als ein DINT zu betrachten, das ist auch zulässig, da TIME in Wahrheit tatsächlich vom Typ DINT ist. In SCL also einer Variablen vom Typ DINT den Wert einer Variablen vom Typ TIME zuweisen zu können, gelingt in SCL nicht mit den in PASCAL jedoch vorgesehen Möglichkeiten, als da wäre:
Code:
WERT1 : DINT;
WERT2 : DINT;
WERT1 := (DINT)WERT2;
Hier meldet der Übersetzer einen Fehler, weil die Anlehnung an PASCAL soweit nun doch nicht vorhanden ist. Jetzt wollte ich aber nicht ein besseres SCL mit strikterer Implementierung von Eigenschaften aus PASCAL entwickeln, da AWL von PASCAL noch weiter entfernt ist, dagegen aber ein Teil der AWL-Sprachmittel aus C entlehnt worden sind. So war es für mich nahe liegend, einen S7-C-Compiler entwickeln zu wollen.
Nun gibt es aber doch gewaltige Unterschiede zwischen einer SPS-Anwendung und einer Anwendung für z.B. einen PC.
Stackzugriffe - bei einer SPS nicht anwendbar
Wenn eine in C geschriebene Anwendung z.B. auf dem PC ausgeführt wird, dann wird Maschinencode auf dem uP des PC's abgearbeitet, Maschinencode, der z.B. vom C-Compiler errichtet wurde. Ein realer uP hat viele Register, die teilweise für bestimmte Aufgaben hergenommen werden können und arbeitet bei der Ausführung von Funktionen mit einem Stack. Wer schon einmal in Assembler programmiert hat, weiss, was ich damit meine, da bei der Programmierung in Assembler die Stackversorgung bzw. Stackentsorgung zu Fuß erstellt werden muss. Bei der Programmierung in C ist das nicht erforderlich, da dies der Compiler automatisch in den Maschinencode einfügt.
Bei einer SPS-Anwendung gibt es keinen Zugriff auf den Stack, der sich aus der Anwendung direkt ergibt, obwohl der physische uP einer SPS sicher mit einem Stack hantiert. Eine Funktion, die in C z.B. wie folgt aufgerufen würde
Code:
a = meine_funktion (b,c,d);
hat in Step7 mit einem FC - hier durch
meine_funktion symbolisch adressiert - Ähnlichkeiten, ich vermeide damit bewusst den Ausdruck der Vergleichbarkeit. In C würden die Parameter
b,c,d des o.g. Beispiels vor der Ausführung der Funktion auf den Stack geladen, erst danach wird in die Funktion gesprungen, als vorletzte MC-Anweisung bei der Ausführung der Funktion (also noch innerhalb der Funktion selbst) wird das Funktionsergebnis auf den Stack geladen und dann erfolgt die letzte MC-Anweisung
return, was den Rücksprung auf die der Absprungstelle folgenden Befehlsdresse bewirkt, die dort vorhanden MC-Anweisung holt sich das Funktionsergebnis vom Stack, danach wird der Stackrahmen korrigiert, das er den Bedingungen vor dem Aufruf der Funktion entspricht. Diese bei einem "gewöhnlichen" uP geübte Handhabung ist bei einem S7-C-Compiler
nicht anwendbar, da AWL (MC7-Code) dafür nicht vorgesehen ist.
Die Ähnlichkeit eines C-Funktionsaufrufes gemäß dem o.g. Beispiel zu einem
Step7-FC-Konstrukt ist zwar gegeben aber ANSI-C lässt eine Veränderung der Parameter, die einer Funktion bei deren Aufruf übergeben werden nicht zu. In den o.g. Beispiel würden die Parameter
b,c,d bei der Ausführung als
Step7-FC in der Schnittstelle als
VAR_INPUT definiert. Würde der
Step7-FC zusätzlich noch in der Schnittstellenbeschreibung die Definitionen für
VAR_OUTPUT oder gar noch
VAR_IN_OUT aufweisen, wird das Dilemma gegenüber ANSI-C sofort sichtbar. (Anm. In PASCAL wäre eine Ähnlichkeit zu
VAR_IN_OUT gegeben, wenn die Parameter mit dem Zusatz
var übergeben würden.)
Es muss daher eine Lösung gefunden werden, wie die Schnittstellenbeschreibung in C gecodet werden könnte. Nach meiner Meinung müssen wir "Strict-ANSI-C" eben an solchen Punkten verlassen. Folgend werde ich auf die Gemeinsamkeiten von
Step7-FC und
Step7-FB eingehen, die speziellen Betrachtungen zu einem
Step7-FB-Konstrukt lasse ich hier vorerst einmal beiseite.
Somit dürfte klar sein, das wir in Step7
nicht ein Stackmodell aus ANSI-C übernehmen können, egal was die S7-CPU im tiefsten Inneren tatsächlich ausführt, da der von unserem S7-C-Compiler übersetzte Code nur den MC7-Code repräsentiert, der von Natur aus ein gemäß ANSI-C verwendbares Stackmodell ausschließt!
Wie wird die Parameterübergabe konform zu Step7 gestaltet?
In C gibt es
generell nur Funktionen. Eine C-Funktion hat immer
einen Rückgabewert. Für C-Funktionen, die keinen
anwendbaren Rückgabewert liefern, wird in C der Prototyp wie folgt definiert:
Code:
void eine_Funktion (void);
Bezogen auf C handelt es sich hier um eine Funktion, die ausschließlich mit globalen Variablen hantiert, wenn diese Funktion einen Sinn machen soll. Übertragen auf Step7 geraten wir nun hier schon in einen Konflikt! Bei der Siemens-Terminologie wird unterschieden zwischen
Step7-FC bzw.
Step7-FB! (Anm. ich lasse die Siemens-spezifischen Unterschiede zwischen
Step7-FC bzw.
Step7-FB erst einmal außer Betracht.) Mein Vorschlag wäre, den S7-C-Prototypen für einen
Step7-FC so zu definieren:
Code:
void eine_Funktion (void);
und mit einem definierten Rückgabewert (hier z.b.
long):
Code:
long eine_Funktion (void);
wobei
long für
DINT bezogen auf AWL steht. (Anm. mit
typedef oder mit
#define kann sich ja jeder, der es möchte,
DINT als Substitut für
long anlegen usw.usf.)
Gemäß diesem Modell wäre die in C übliche in Klammern eingeschlossene Parameterübergabe hinter der Nennung des Bezeichners (hier in dem Beispiel
eine_Funktion) ohne zusätzliche Informationen nicht mehr anwendbar! Dieses wäre auch mit keinen Nachteilen verbunden, da wir uns ohnehin eine andere Art der Parameterübergabe, welche die Anforderung von Step7 erfüllt, überlegen müssen.
Es fehlt noch die Definition des Prototypen, der später in einen
Step7-FB übersetzt werden soll:
Code:
void ein_Funktionsbaustein (void);
Formal sind nun die Prototypen für einen
Step7-FC ohne Rückgabewert und für einen
Step7-FB gleich! Das stellt aber kein Problem dar. Woher nimmt nun der S7-C-Compiler die Information, ob es sich um eine
Step7-FC oder um einen
Step7-FB her, den es zu übersetzen gilt?
Im einem S7-Projekt kann in der Symboltabelle für jeden Baustein ein Symbol angelegt werden, so würde z.B. entweder die Assoziation
eine_Funktion =
FC 102 oder
ein_Funktionsbaustein =
FB 306 bestehen. Die Anforderung an unseren S7-C-Compiler besteht also darin, sich die Informationen aus dieser S7-Symboltabelle zu holen! ANSI-C schreibt vor, dass Symbole keine Zeichen enthalten dürfen, die für C-Operatoren verwendet werden. Dummerweise lässt der Symboleditor in Step7 z.B. die Eingabe des "-"Operators zu! Wenn wir mit einem gängigen PP arbeiten wollen, würde sich diese schlechte Angewohnheit verbieten! Mein Vorschlag wäre, sich bei der Erstellung der Symboltabellen im S7-Projekt auf die Zeichen zu beschränken, die auch üblicherweise zur Symboldefinition unter ANSI-C zugelassen sind.
Wenn wir an diesem Punkt angekommen sind, dann können wir die in C übliche Parameterübergabe nach ANSI-C nicht mehr konform anwenden! Doch wie könnte sich eine Parameterübergabe gestalten, welche die Anforderungen an Step7 erfüllt? Übersetzten wir einen AWL-Baustein als AWL-Quelle, so findet sich die Lösung. Anders als im AWL-Editor (den ich besonders liebe, da Siemens seit Jahren dessen Macken nicht beheben will!) sehen wir in einer AWL-Quelle die Schnittstellenbeschreibung. Mein Vorschlag wäre, die
VAR_INPUT,
VAR_OUTPUT und
VAR_IN_OUT als Schlüsselwörter in unseren S7-C-Compiler einzuführen. (Anm. in Step7 gibt es noch weitere Teile der Schnittstellenbeschreibung, auf die ich hier an dieser Stelle vorerst noch nicht eingehen will.) So könnte z.B. der Prototyp für einen
Step7-FC aussehen, der von unserem S7-C-Compiler erwartet würde:
Code:
long eine_Funktion (VAR_INPUT Boolean flag1, Boolean flag2, long wert1,
VAR_OUTPUT Boolean flag3, Boolean flag4);
Damit hätte diese Schreibweise noch eine Nähe zu ANSI-C, würde aber unseren S7-C-Compiler mit den notwendigen Informationen versorgen. Die in der AWL-Quelle übliche Abgrenzung mit
VAR_END wäre somit völlig überflüssig, da der Geltungsbereich von z.B.
VAR_INPUT sich über alle nachfolgenden Parameter erstreckt, bis er durch ein anderes Schlüsselwort wie
VAR_OUTPUT oder
VAR_IN_OUT aufgehoben wird. Der Geltungsbereich endet grundsätzlich, wenn die Parameterliste mit einer runden Klammer abgeschlossen wird. Ob wir nun diese Schlüsselwörter mit den v.g. Begriffen bezeichnen, was zumindest eine Nähe zu einer AWL-Quelle herstellt oder ob andere kürzere Begriffe verwendet werden, ist schlussendlich eine Frage des Geschmacks. Ich persönlich würde
vin,
vout und
vio bevorzugen, weil das etwas lästige Tipparbeit einsparen würde, diese Schlüsselwörter sollten lediglich nicht mit ANSI-C kollidieren.
Welche Besonderheiten sind bei Schnittstellen-Parametern noch zu beachten?
Haben wir es bisher mit Formalien zu tun gehabt, die auf dem Verständnis des direkten Vergleichs von Gemeinsamkeiten zwischen AWL und C-Prototypen abgestellt waren, so gelangen wir nun zu einem Kapitel über Informationen, welche auch nicht im weitesten Sinne etwas mit der Logik eines Prozesses zu tun haben, der mit einer SPS-Anwendung kontrolliert werden soll.
Nachstehend zeige ich zwei Ausschnitte aus einer Schnittstellenbeschreibung, der erste Ausschnitt stammt aus einer SCL-Quelle und der zweite Ausschnitt aus der AWL-Quelle des gleichen Bausteins.
Code:
VAR_INPUT
SEL01 {S7_visible:= 'true'} : BOOL := 0; // to select output 1
SEL02 {S7_visible:= 'true'} : BOOL := 0; // to select output 2
SEL03 {S7_visible:= 'true'} : BOOL := 0; // to select output 3
SEL04 {S7_visible:= 'true'} : BOOL := 0; // to select output 4
SEL05 {S7_visible:= 'false'}: BOOL := 0; // to select output 5
SEL06 {S7_visible:= 'false'}: BOOL := 0; // to select output 6
END_VAR
Code:
VAR_INPUT
SEL01 { S7_visible := 'true' }: BOOL ; //to select output 1
SEL02 { S7_visible := 'true' }: BOOL ; //to select output 2
SEL03 { S7_visible := 'true' }: BOOL ; //to select output 3
SEL04 { S7_visible := 'true' }: BOOL ; //to select output 4
SEL05 { S7_visible := 'false' }: BOOL ; //to select output 5
SEL06 { S7_visible := 'false' }: BOOL ; //to select output 6
END_VAR
Auf den ersten Blick erscheint der Unterschied kaum merkbar, mich hat das auch völlig überrascht, als ich die AWL-Quelle des Bausteins erzeugt hatte. Aber das ist es nicht, worauf ich hinaus will. Wir sehen in geschweiften Klammern z.B.
{S7_visible:= 'true'}. Hierbei handelt es sich um eine
Objekteigenschaft eines Schnittstellenparameters, der z.B. in CFC benötigt wird.
{S7_visible:= 'true'} entspricht ohnehin der Default-Einstellung, die ggf. mit
{S7_visible:= 'false'} überschrieben werden kann. In CFC wird ein Baustein grafisch präsentiert und ein Schnittstellenparameter, dessen
S7_visible-Attribut auf
false eingestellt ist, wird in CFC nicht dargestellt.
Wo jetzt die Objekteigenschaften eines Schnittstellenparameters gespeichert werden, entzieht sich im Augenblick meiner Erkenntnis. (Das wäre mal eine Frage an Rainer, da ja wohl in seiner Umgebung schon weitere Erkenntnisse vorliegen könnten!) Im AWL-Editor sind diese Objekteigenschaften wie folgt erreichbar:
- einen Schnittstellenparameter anwählen und rechte Maustaste drücken
- es erscheint ein Dialog mit der Überschrift
Eigenschaften - Variable
- den Reiter
Attribute auswählen.
Für unseren S7-C-Compiler sind die Attribute wohl nicht relevant, für die Einbindung in ein bestehendes S7-Projekt dürften jedoch die Beschreibungen dieser Attribute nicht unter den Tisch fallen gelassen werden. Wie in dem vorherigen Abschnitt bereits dargestellt, sollte die C-spezifischen Parameterdefinitionen im Prototyp ausreichend befriedigt sein. Wie aber sollen die Beschreibungen der Attribute berücksichtigt werden? Sollte man sich an das Konzept anlehnen, was in AWL oder SCL praktiziert wird? Nach meiner Ansicht sollte man dies nicht tun, wir sollten das von mir bereits vorgestellte Prototyp-Konzept beibehalten, weil dies am ehesten noch eine Nähe zu ANSI-C darstellt. Die Lösung wäre ein weiteres Schlüsselwort
pattr einzuführen. Die Anwendung würde dann aber nicht innerhalb der Definition des Prototyps erfolgen sondern innerhalb der Definition der Funktion im C-File. Dies könnte dann so aussehen:
Code:
void eine_Funktion (VAR_INPUT Boolean SEL01, Boolean SEL02, Boolean SEL03,
Boolean SEL04, Boolean SEL05, Boolean SEL04,
VAR_OUTPUT Boolean flag3, Boolean flag4)
{
pattr SEL01 (S7_visible true, 0, 'to select output 1'),
SEL02 (S7_visible true, 0, 'to select output 2'),
SEL03 (S7_visible true, 0, 'to select output 3'),
SEL04 (S7_visible true, 0, 'to select output 4'),
SEL05 (S7_visible false, 0, 'to select output 5'),
SEL06 (S7_visible false, 0, 'to select output 6');
if (SEL01 && SEL02) .....
}
Natürlich muss an diesem Konzept noch gefeilt werden, denn es ist durchaus möglich, das für einen Schnittstellenparameter mehr als nur ein Attribut zugeordnet werden kann. In dem v.g. Beispiel werden dem Parameter
SEL01 das Attribut
S7_visible, die Default-Einstellung 0 für die Parameterversorgung bei "unbeschaltetem" Zustand und der Kommentartext zugewiesen. Der Geltungsbereich der Attributdefinitionen beginnt mit dem Schlüsselwort
pattr und endet mit einem Semikolon. Die Definitionen von Attributen für einen Schnittstellenparameter beginnen mit der Nennung des Bezeichners, gefolgt von einer (-Klammer und wird durch eine )-Klammer abgeschlossen, innerhalb des Klammerpaares werden die Attribute durch Kommata getrennt. Folgt der Attributdefinition eines Schnittstellenparameters eine Attributdefinition für einen weiteren Schnittstellenparameter, so wird diese durch ein Komma abgetrennt, sonst wird die gesamte Attributdefinition durch ein Semikolon abgeschlossen.
Wenn wir auf einen "fertigen" CPP (C-preprocessor) aufsetzten wollen, beginnen sicher hier die Schwierigkeiten. Wir müssen dann dort einen entsprechenden Anteil nachrüsten, der sich dieser zusätzlichen Definitionen annimmt, welche ja nicht unbedingt in einem normalen CPP von Hause aus anzutreffen sein werden.
Da zwangsläufig in AWL
jeder Parameter versorgt werden muss, mag er in der AWL-Quelle ohne die Default-Einstellung für die Parameterversorgung daherkommen. Wenn ein solcher Baustein in einen CFC-Plan eingebaut wird, dann werden die "unverdrahteten" Eingänge mit der Defaultversorgung beschaltet, auch die "unsichtbaren" Parameter! Wer etwas tiefer in CFC eingestiegen ist, wird feststellen, dass diese Versorgung auf Datenstellen eines Instanzdatenbausteins erfolgen, was ich hier aber nicht weiter ausführen will, da dies im CFC-Konzept von Hause aus erledigt wird.
Unterschiede zwischen Step7-FC und Step7-FB
Bis hierhin wären rein oberflächlich betrachtet einige Gemeinsamkeiten bei
Step7-FC und
Step7-FB vorhanden. Dem ist aber nicht so! Die bisher behandelten Typen der Schnittstellenparameter weisen aus der Sicht der Syntax scheinbare Gemeinsamkeiten auf. Der wesentliche Unterschied ist aber vorhanden und dürfte damit sicher auch Auswirkungen auf den zu erzeugenden MC7-Code haben.
Ein
Step7-FC kommt ohne Instanzdatenbaustein aus! Aber wo werden die Schnittstellenparameter für die Ausführung der Funktion hinterlegt? Laut Siemens werden diese auf einem Stack gespeichert! Ob dieser Stack jedoch mit einem Stack herkömmlicher Art vergleichbar wäre, entzieht sich derzeit meiner Erkenntnis. Die Anwendung dieses eigentümlichen Stacks ist auch die Erklärung dafür, dass ein
Step7-FC keine statischen Variablen halten kann, was einen wesentlichen Unterschied zu einem
Step7-FB ausmacht. Aus der Sicht der AWL-Codierung sind die Unterschiede bezüglich der Ein- und Ausgabeparameter im Hinblick auf einen
Step7-FB nur in bestimmtem Umfang relevant, im Hinblick auf den zu erzeugenden MC7-Code wird es wahrscheinlich notwendig sein, hier tiefere Erkenntnisse zu gewinnen.
Ein weiterer wesentlicher Unterschied zwischen einem
Step7-FC und einem
Step7-FB besteht darin, dass nur der
Step7-FC einen Rückgabewert liefern kann! Wenn also ein
Step7-FC noch in etwa eine Konformität zu ANSI-C hat, dann ist dies bei einem
Step7-FB schon nicht mehr gegeben!
Ein Step7-FB darf konform zu Step7 keinen Rückgabewert liefern! Dies hat beachtliche Konsequenzen bei einer Programmierung in S7-C! Wir werden diesbezüglich das noch in einem anderen Rahmen diskutieren müssen.
Der gravierendste Unterschied zwischen einem
Step7-FC und einem
Step7-FB besteht aber darin, dass die Anwendung eines
Step7-FB immer mit einem Instanzdatenbaustein einhergeht! Deshalb noch einmal: Aus der Sicht der AWL-Codierung sind die Unterschiede bezüglich der Ein- und Ausgabeparameter im Hinblick auf einen
Step7-FC nur in bestimmtem Umfang relevant, im Hinblick auf den zu erzeugenden MC7-Code wird es sicher notwendig sein, hier tiefere Erkenntnisse zu gewinnen.
Aber anders als ein
Step7-FC kann ein
Step7-FB mit statischen Variablen ausgestattet werden. Der Vergleich zu ANSI-C hinkt aber etwas. Wird unter ANSI-C innerhalb einer Funktion eine statische Variable definiert, so verliert diese Variable nach Verlassen der Funktion
nicht ihre Gültigkeit, kann aber von anderen Funktionen, die im gleichen C-File definiert werden,
nicht gesehen werden, d.h. eine unter ANSI-C innerhalb einer Funktion definierte statische Variable hat nur innerhalb der Funktion, in der sie definiert worden ist, ihren Geltungsbereich! Eine in einem
Step7-FB definierte statische Variable hat
generell globalen Charakter, da diese Variable eine Datenstelle in einem Instanzdatenbaustein adressiert! Hier sollte nun überlegt werden, wie die Syntax zur Definition einer statischen Variable unter S7-C für einen
Step7-FB formuliert werden sollte. Man könnte, wenn man nicht zu kleinlich ist, das von ANSI-C vorgehaltene Schlüsselwort
static anwenden - ich hätte dagegen nichts einzuwenden. Gleichzeitig wird man aber dabei unterscheiden müssen, ob es auch statische Variablen geben soll, deren Geltungsbereich sich modulweit erstrecken soll und die ggf. mit einer
extern-Referenz angesprochen werden könnte. Aber diesen Punkt möchte ich vorerst an dieser Stelle nicht weiter vertiefen.
Statische Variablen eines
Step7-FB werden daher von dem S7-C-Compiler automatisch als Schnittstellenparameter zwischen den Step7-Schlüsselwörtern
VAR und
VAR_END platziert.
Lokale Variablen in Step7-FC und Step7-FB
Ich denke, dies ist eigentlich der simpelste Teil der Definitionen unter S7-C und könnte völlig konform zu ANSI-C erfolgen, d.h. ANSI-C-konforme lokale Variablen werden von dem S7-C-Compiler automatisch als Schnittstellenparameter zwischen den Step7-Schlüsselwörtern
VAR_TEMP und
VAR_END platziert.
Definitionen der Bausteinköpfe für Step7-FC und Step7-FB
Eine Definition eines Bausteinkopfes kann als SCL-Quelle wie folgt aussehen:
Code:
FUNCTION_BLOCK FB813
NAME : 'RADIOBTN'
AUTHOR : 'HL'
FAMILY : 'XYZ'
VERSION : '1.0'
{S7_tasklist := 'OB100'; S7_m_c := 'false'; S7_blockview := 'big'}
Als AWL-Quelle sieht der gleiche Bausteinkopf wie folgt aus:
Code:
FUNCTION_BLOCK FB 813
TITLE =
{ S7_m_c := 'false'; S7_blockview := 'big'; S7_tasklist := 'OB100' }
AUTHOR : HL
FAMILY : XYZ
NAME : RADIOBTN
VERSION : 1.0
Wobei ich mir aber die Bemerkung nicht verkneifen kann, das Siemens hier schon für eine Inkonsistenz gesorgt hat. In SCL ist hinter dem Schlüsselwort
HEADER der Titeltext einzutragen, in dem Beispiel wird
HEADER nicht verwendet, deshalb wird im AWL-Quelltext hinter
TITLE = kein Text angezeigt!
Um die Konformität zu Step7 zu erreichen, wäre es notwendig, wie schon bei den Attributen zu den Schnittstellenparametern, eine (oder mehrere) zusätzliche Methode
in S7-C einzuführen. Soweit die in AWL verwendeten Schlüsselwörter mit ANSI-C nicht kollidieren (ich hab das i.A. nicht geprüft) könnte das dann wie folgt aussehen:
Code:
void eine_Funktion (VAR_INPUT Boolean SEL01, Boolean SEL02, Boolean SEL03,
Boolean SEL04, Boolean SEL05, Boolean SEL04,
VAR_OUTPUT Boolean flag3, Boolean flag4)
{
title 'Auswertung von Radiobuttons';
fattr (S7_m_c false, S7_blockview big, S7_tasklist OB100);
author 'HL';
family 'XYZ;
name 'RADIOBTN';
version '1.0';
pattr SEL01 (S7_visible true, 0, 'to select output 1'),
SEL02 (S7_visible true, 0, 'to select output 2'),
SEL03 (S7_visible true, 0, 'to select output 3'),
SEL04 (S7_visible true, 0, 'to select output 4'),
SEL05 (S7_visible false, 0, 'to select output 5'),
SEL06 (S7_visible false, 0, 'to select output 6');
if (SEL01 && SEL02) .....
}
Ausblick
Damit möchte ich erst einmal für den heutigen Beitrag den Ausflug in die Betrachtungen, wie man in S7-C eine Konformität zu Step7 erreichen könnte, beenden. Sicher wird man an den einzelnen Abschnitten noch feilen müssen, denn mir ist jetzt schon bewusst, dass in meinen Ausführungen noch nicht alles angesprochen worden ist, d.h. meine Ausführungen sind sicher noch unvollständig. Ich verstehe meinen Beitrag als Grundlage zur weiteren Diskussion und als Anregung für alle, das ihr hier eure Ergänzungen aus eurer Sicht beitragen solltet.
In meinem nächsten Beitrag werde ich mich damit beschäftigen, welche Parametertypen bei den in S7-C programmierten Funktionen konform zu ANSI-C vs.
Step7-FC bzw.
Step7-FB überhaupt angewendet werden können. Dies wird einen erheblichen Einfluß auf die verwendbaren Typen bei den Schnittstellenparametern haben. Wenn dieses Thema geklärt ist, dann ergibt sich sicher eine neue Sichtweise, welche ANSI-C-konformen C-Konstruktionen auch in S7-C gecodet werden können.
Gruß Barnee
