Input Parameter überschreiben

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es liegt auch dran das die Programme mittlerweile so komplex sind, da sie in ganzem nicht mehr
zu überblicken sind.
Zu den umtrieben in AWL, vor 20 Jahren also S5 Zeiten, war auch noch nicht das möglich was heute
mit S7 alles so gemacht werden kann.

 

[bike]

Es liegt auch dran das die Programme mittlerweile so komplex sind, da sie in ganzem nicht mehr
zu überblicken sind.

Oder überblickt werden will?
Das Problem liegt schon daran, dass der Programmcode MS/DOS noch von einem Menschen zu lesen ist, so ist es bei Win$ in keiner Weise mehr möglich.
Es wird etwas geschrieben, nach dem Motto wird schon gut gehen und wenn nicht dann gibt es ein Servicepack.
Diese Denke ist inzwischen auch im Maschinen- und Anlagenbau angekommen.
Es geht uns so, dass wir liefern müssen, obwohl es noch nicht fertig ist.
Dann wird ein oder mehrere Patches gebaut und hinterher geschickt.
Leider ist das so.


bike

P.S: wenn ich einen Wunsch hätte, dann den, dass ich nie mit TIA und / oder Win8 programmieren oder arbeiten muss. Man darf träumen.

 

[sablitos]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der FB_1 ist im MAIN instanziiert, also dazu gedacht, vom MAIN aus aufgerufen zu werden. Dementsprechend kann er auch nur mit Variablen gefüttert werden, die dem MAIN zugänglich sind. Das Verwursten dieser Variablen ist doch ebenfalls Aufgabe von MAIN. Warum steht dann der Code in einer Funktion und nicht direkt im MAIN?

Das Beispiel was ich hier gegeben habe ist stark vereinfacht, es geht um ein ziemlich kompliziertes Kommunikationsprotokoll, die Funktion FC_1 soll Exception-Telegramme generieren und bearbeiten (und viel mehr) und der FB_1 ist eine Display-Schnittstelle, bei manchen Telegramme soll die Funktion FC_1 paar Inputs von FB_1 aktualisieren. Die Funktion FC_1 kann also überall im Programm aufgerufen werden und nicht nur in Main.

 

[RobiHerb]

Das Beispiel was ich hier gegeben habe ist stark vereinfacht, es geht um ein ziemlich kompliziertes Kommunikationsprotokoll, die Funktion FC_1 soll Exception-Telegramme generieren und bearbeiten (und viel mehr) und der FB_1 ist eine Display-Schnittstelle, bei manchen Telegramme soll die Funktion FC_1 paar Inputs von FB_1 aktualisieren. Die Funktion FC_1 kann also überall im Programm aufgerufen werden und nicht nur in Main.

Wie ich schon weiter oben geschrieben habe geht das "well behaved" nur per VAR_IN_OUT. (nur FB soweit ich weiss)

Der Weg über Pointer in Funktionen (FC) ist ebenfalls möglich aber nicht erste Sahne. Und wie Du schon schreibst, komplex und von überall aufgerufen, da ist Chaos angesagt, wenn ein neues Telegramm ggf. ein Telegramm im Sendebuffer überschreibt etc.

Der Weg ginge dann am Besten über eine Warteschlange (FiFo/Queue) und ein kontrolliertes Zentrales Abarbeiten im Hauptprogram Zyklus (eigene Status Maschine für die Telegramm Bearbeitung).

Und dann nochmal der Hinweis, es gibt Bücher. z.B. "Design Patterns" von Gramma etc. Erscheint erst einmal total abgehoben für eine SPS aber über die Zeit merkt man, das ist eine Goldgrube.

Für die prinzipielle SPS Problematik: Heinrich Lepers "SPS Programmierung nach IEC", obwohl für Beginner geschrieben auch voller Schätze beim erneuten Lesen.

 

[Larry Laffer]

@sablitos:
Vielleicht noch einmal als Rekapitulation :
Du kannst ggf. auf die Schnittstelle eines FB (auch per Pointer oder Adressieren der Instanz oder was auch immer) draufschreiben was du willst - es wird erst dann bearbeitet, wenn der FB aufgerufen wird ... und es wird dann mit den Übergabe-Parametern gearbeitet, die dann an der Schnittstelle stehen. Du solltest vielleicht wirklich noch einmal überlegen, was du so erreichen willst und warum du es meinst nur so erreichen zu können ...

Gruß
Larry

 

[StructuredTrash]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Beispiel was ich hier gegeben habe ist stark vereinfacht, es geht um ein ziemlich kompliziertes Kommunikationsprotokoll, die Funktion FC_1 soll Exception-Telegramme generieren und bearbeiten (und viel mehr) und der FB_1 ist eine Display-Schnittstelle, bei manchen Telegramme soll die Funktion FC_1 paar Inputs von FB_1 aktualisieren. Die Funktion FC_1 kann also überall im Programm aufgerufen werden und nicht nur in Main.

Wenn Die FC_1 von überall her aufgerufen wird, selbst aber Variablen des MAIN manipuliert, baust Du Dir damit eine ewige Stolperfalle. Und wie schon Larry Laffer sagt, kann es passieren, dass die INPUT-Variablen des FB_1 mehrmals aktualisiert werden, bevor er aufgerufen wird. Wäre das in Deinem Sinn? Wenn die Gesamtstruktur schon so aussehen muss, würde ich den FB_1 global anlegen und jedesmal aus der FC_1 heraus aufrufen.

 

[sablitos]

Wenn die Gesamtstruktur schon so aussehen muss, würde ich den FB_1 global anlegen und jedesmal aus der FC_1 heraus aufrufen.

Ich weiß dass die ideale Lösung für sowas ist immer global zu deklarieren, das Problem ist dass globalen Variablen zu viel Speicher brauchen. ( ich arbeite mit einem BC- mit 32 KB :-( )

Und wie schon Larry Laffer sagt, kann es passieren, dass die INPUT-Variablen des FB_1 mehrmals aktualisiert werden, bevor er aufgerufen wird

das sollte kein Problem sein, es ist eigentlich genau so gewollt. Wie ich schon erwähnte geht es bei FB_1 um eine Display-Schnittstelle und in diesem bestimmten Display-Fenster soll sowas wie 'Last-ErrorID', 'Last-Device' usw. gezeigt werden. also es 'muss' eigentlich mehrmals aktualisiert werden.