CoDeSys: Mehrere Programme in einem Projekt verwalten

[Klimamensch]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich schreibe momentan in eine einzige Projektdatei mehrere Einzelprogramme, die je nach Bedarf abgearbeitet werden sollen. Es handelt sich dabei um verschiedene Regelstrategien ein und derselben Anlage. Ich habe alle Regelstrategien in ein Projekt gepackt, da mir so das Arbeiten z.B. bei der Visualisierung leichter fällt.
Ich möchte nun folgendes machen:
Wenn ein bestimmter Wert auf "TRUE" steht soll eine bestimmte Regelstrategie abgearbeitet werden, während alle anderen "passiv" sind. Ich habe schon versucht dies mit dem Taskkonfigurator zu lösen, allerdings ohne Erfolg.

Hat jemand eine Idee wie ich dieses Problem lösen kann?

Vielen Dank im Voraus.

 

[DaHauer]

Hallo,

das mit verschiedenen Tasks zu lösen ist mit Kanonen auf Spatzen schießen.
Es wäre ja auch denkbar, dass Du ein zentrales PRG verwendest, in dem du die anderen PRGs bedingt aufrufst.

so etwa:

IF Bedingung1 THEN
    PRG1();
ELSIF Bedingung2 then
    PRG2();
END_IF

Grundsätzlich sind viele Wege machbar, aber da Du schon Einzelprogramme (PRG) hast, scheint mir das am einfachsten.

Hoffe das hilft Dir erst mal weiter.

cheers

 

[Klimamensch]

Zuviel Werbung?
-> Hier kostenlos registrieren

Danke für die Antwort. Leider scheint dieser Ansatz bei mir nicht zu funktionieren. Wenn ich den Code von oben verwende und auf meine Programme anwende, werden alle anderen Programme trotzdem abgearbeitet, so als würde das Programm die Bedingungen ignorieren.

 

[DaHauer]

poste am besten mal dein projekt dann ist es leichter drüber zu reden.

 

[RobiHerb]

Sollte funktionieren ...

Danke für die Antwort. Leider scheint dieser Ansatz bei mir nicht zu funktionieren. Wenn ich den Code von oben verwende und auf meine Programme anwende, werden alle anderen Programme trotzdem abgearbeitet, so als würde das Programm die Bedingungen ignorieren.

Wenn ein PRG so wie beschrieben abgearbeitet wird, obwohl es eigentlich nicht sein dürfte, ist ein Fehler in der Aufruflogik.

Im Programm, das nicht aufgerufen werden sollte, einen Breakpoint setzen und nachsehen, wer das PRG aufruft (notfalls mit Single Step).

Nebenbemerkung: Ich verstehe die IEC Norm so, dass ganau ein Programm in einem Projekt existiert. Das Programm ruft dann Funktionen oder FunktionsBlöcke jweils mit Parametern auf, aber nie andere Programme. (Ausnahmen verschiedene Tasks etc.)

Das mag für viele nur ein Schönheitsproblem sein, aber ohne Parameter Übergabe bekommt man auch gleich noch viele globale VAR und andere Nachteile mit ins Projekt hinein.

 

[DaHauer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo RobiHerb,

CoDeSys erlaubt es ja mit PRGs zu arbeiten, ob es sinnvoll ist oder der Übersichtlichkeit hilft sei mal dahin gestellt.

Wenn ein PRG in einem PRG gerufen werden soll, muss es so funktionieren, es sei denn der TE hat seine diversen PRGs schon in verschiedenen Tasks gesteckt und vergessen die Tasks wieder zu löschen.

Aber ich sehe das ähnlich wie Du, dass bei der Verwendung von PRGs Zurückhaltung angebracht ist. In einem FB oder einer Funktion lassen sich Sachen einfach besser kapseln und man verdreckt sich nicht die hoffentlich spärlich eingesetzten globalen Variablen ;-)

ein Feedback vom TE würde Klarheit bringen ;-)


cheers

 

[Klimamensch]

Hallo,

Danke nochmals für die Antworten. Ich habe mich nun dagegen entschieden mehrere Programme in einem Projekt zu verwenden, da so das Programm auf eine Datengröße anschwillt, die bei der Übertragung zur DDC zu viel Zeit kostet. Bin Anfänger und muss daher öfter Daten transferieren, um Dinge auszuprobieren.

Bei Gelegenheit werde ich es noch mal mit Breakpoints setzen versuchen, um zu klären, von wo das Programm ausgeführt wird.

 

[StructuredTrash]

Ein PRG kann doch genauso INPUT/OUTPUT-Variablen haben wie ein FB. Ich sehe deshalb keine Notwendigkeit, beim Einsatz von PRG's mehr globale Variablen zu verwenden als bei FB's. Entscheidend ist für mich nur, ob ich eine POU mehrfach instanzierbar haben will/muss oder nicht.