Strukturierter Programmaufbau COEDESYS 2

[Passion4Automation]

Zuviel Werbung?
-> Hier kostenlos registrieren

Servus,

ich momentan dabei das Projekt für eine Gebäudeautomatisierung zu schreiben.
Ich mache das unter CODESYS 2 mit einer 750 881.

Mir stellen sich von der Struktur her einige Fragen.
PLC_PRG ist obligatorisch ist mir klar, ruft hr alle Unterprogramme aus dem PLC_PRG auf oder kann ich aus Unterprogrammen auch noch weitere PLC_PRG aufrufen, als das Programm weiter verschachteln?
Hab das mal versucht aber es kam dann ein Übersetzungsfehler.

Also ich hätte z.B. Für jedes Geschoss ein PLC_PRG für die Rolladen, ein PLC_PRG für Beleuchtung und Steckdosen usw.

Sollte man mit mehreren Globalen Var Tebellen arbeiten?

Es ist doch eigentlich vom SPS Zyklus her auch wichtig wenn ich z.B. ein PLC_PRG habe das ganz am Anfang vom Zyklus durchlaufen wird, das die dazugehörigen Globalen varibalen auch ganz am Anfang der Tabelle stehen, verstehe ich das richtig.
Deswegen meine ich das es sinnvoll is für jedes PLC_PRG eine Tabelle anzulegen.

Das Projekt hat 10 Analogkanäle und eine Dali_karte, ca 100 DI und DO. Ich finde es schon wichtig das man sich da etwas mit dem Zyklus befasst. Es gibt ja noch die Möglichkeiten mit den TASKS.

Ich würde mich über Antworten praxiserfahrenen USern freuen.


Danke.

 

[Blockmove]

Du treibst zuviel Aufwand.
Bei einer so geringen Anzahl von E/A und Funktionalitäten reicht ein Anwender-PLC_PRG.
Anstelle von Unterprogrammen nimmt man FBs.
Eine mögliche Gliederung ist z.B.

• PLC_PRG
  • FB Global
    • FB Kalender (Feiertage, Urlaub)
    • FB Präsenz
  • FB Keller
    • FB Raum A
      • FB Licht
      • FB Heizung
      • FB ...
    • FB Raum B
      • ...
  • FB Erdgeschoß
    • ...

Erfahrungsgemäß hast zwischen den einzelnen Funktionen (Heizung, Licht, ...) viele Abhängigkeiten.
Daher ist es schlichtweg einfacher dies in einem PLC_PRG zu handeln.

Zykluszeit ist - wenn du ordentlich programmierst - kein Thema

 

[GLT]

Zuviel Werbung?
-> Hier kostenlos registrieren

PLC_PRG darf es nur 1mal geben.

Teile, die nicht ständig durchlaufen werden müssen, kann man zwar ebenfalls hier aufrufen - schöner ist es, wenn Du das über Tasks machst.

 

[oliver.tonn]

PLC_PRG ist nicht obligatorisch, Du kannst es auch löschen und ein PRG mit einem anderen Namen nehmen, allerdings musst Du dieses dann selber in der Taskkonfig eintragen. Bei PLC_PRG geschieht das per default.

Von irgendwas mit Internetzugang gesendet.

 

[holgermaik]

Hallo.
Da du in Codesys neu bist mal ein paar allgemeine Sachen.:razz:

Wann benutzt man Task's bzw. PLC_PRG:

Ein mittleres Programm (bei einem 881) hat eine Zykluszeit von ca. 15ms bis 30ms. (je nach Größe und Programmierstil)
Wenn ich also Aufgaben habe die eine Zykluszeit deutlich darunter verlangen oder so sehr langsam sind, dass sie deutlich darüber liegen muss ich mich mit Task beschäftigen

Werden keine Task definiert und ist das Programm PLC_PRG vorhanden, wird dieses abgearbeitet.

oder kann ich aus Unterprogrammen .... weiter verschachteln

Du kannst aus Programmen und Unterprogrammen weitere Programme aufrufen.
Dies dient lediglich der Übersichtlichkeit. Dem Controller ist das egal. Anders sieht es bei FB und Functionen aus.

Sollte man mit mehreren Globalen Var Tebellen arbeiten?

Auch das dient nur der Übersichtlichkeit des Programmierers. Dem Controller ist das egal.

Es ist doch eigentlich vom SPS Zyklus her auch wichtig wenn ich z.B. ein PLC_PRG habe das ganz am Anfang vom Zyklus durchlaufen wird, das die dazugehörigen Globalen varibalen auch ganz am Anfang der Tabelle stehen, verstehe ich das richtig.

Dem Controller ist das egal in welcher Reihenfolge du die Variablen definierst.

Das Projekt hat 10 Analogkanäle und eine Dali_karte, ca 100 DI und DO

Das sind eher wenige I/O und bedürfen keiner Sonderbehandlung.

Wie Blockmove schon schreibt, macht es schon Sinn bestimmte Sachen in FB zu packen und diese dann mehrfach zu verwenden.

Holger

 

[RobiHerb]

Zuviel Werbung?
-> Hier kostenlos registrieren

V3

Du treibst zuviel Aufwand...

Eine mögliche Gliederung ist z.B.

• PLC_PRG
  • FB Global
    • FB Kalender (Feiertage, Urlaub)
    • FB Präsenz
  • FB Keller
    • FB Raum A
      • FB Licht
      • FB Heizung
      • FB ...
    • FB Raum B
      • ...
  • FB Erdgeschoß
    • ...

Erfahrungsgemäß hast zwischen den einzelnen Funktionen (Heizung, Licht, ...) viele Abhängigkeiten.

Das ganze schreit förmlich nach Codesys V 3.x !

Vererbung etc. macht hier echt Sinn!

 

[Blockmove]

Das ganze schreit förmlich nach Codesys V 3.x !

Vererbung etc. macht hier echt Sinn!

In Vererbung sehe ich bei sowas einfachen ehrlich gesagt keinen großen Vorteil.
Für einen Einsteiger sowieso nicht. Hier würde ich eher sagen: "Keep ist simple"
Ich würde hier ganz normale FBs verwenden.

Gruß
Blockmove

 

[holgermaik]

mit einer 750 881.

Das ganze schreit förmlich nach Codesys V 3.x !

Jetzt musst du nur noch erklären wie du eine V3.x Runtime auf den Controller bekommst!

Holger

 

[Passion4Automation]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo an alle, vielen Dank,

Vererbung kenne ich in der Theorie, aber noch to much.

@ Blokemove: Dann hat mir jemand Quatsch erzählt, mir wurde gesagt das zum Beispiel der DaliFB der eingebunden wird damit die Wago mit der 647 kommunizieren kann, immer in einem PLC_PRG laufen muss. Habs grad getestet, läuft auch im FB der aus dem Hauptprogramm aufgerufen wird.

Ok zur Struktur:

Dann brauche ich ja wie bei TIA und Step nur PLC_PRG (OB1) und dann unterteile ich in FB,s und da könnte ich wieder Fb,s einfügen.

Dann sehe ich das eigentlich so. Für jeden Raum der nicht gerade nur ein Licht hat einen FB, da kommt ja ganz schön was zusammen, aber es ist dann strukturiert. Für die Wetterstation, die Sonnenstandsberechnung, die Präsenz könnte ich ja dann einen FB Global anlegen, wo z.B. auch der Zentral alles aus Taster verarbeitet ist.

Erklärst du dir den Vorteil das du die Heizung ERR das Licht und die Steckdosen pro Raum in einem FB schreibst so, weil man dann weniger Globale Variablen braucht?
Damit ich das auch richtig verstehe: Der FB z.B. Beleuchtung Flur soll den Programmcode enthalten und darin kann ich dann wieder FB,s einfügen z.B. selbsgeschriebene die ich mehrmals benötige?


Zykluszeit:
Ich weiß das die SPS bei meiner Menge nicht so viel zu tun hat, ausser vielleicht bei der Sonnenstandberechnung un den 20 Dali Teilnehmern und teilweise KLR, aber mir ist es wichtig die Systematik zu verstehen, was ich nicht so ganz verstanden habe ist: Worauf muss ich beim programmieren eigentlich achten damit ich die Zykluszeit nicht negativ beeinflusse???
Das mit Tasks ist klar, aber mal ohne Task, einfach nur mit PLC_PRG.


Danke für Eure Unterstützung.

 

[Passion4Automation]

Hallo Holgermaik;

Du kannst aus Programmen und Unterprogrammen weitere Programme aufrufen.
Dies dient lediglich der Übersichtlichkeit. Dem Controller ist das egal. Anders sieht es bei FB und Functionen aus.

Wie meinst du das, weil es bei FB und Funktionen anders aussieht?

Danke .

 

[holgermaik]

Funktionen führen normalerweise einen Code aus und geben das Ergebnis aus. danach kehren sie zur nächsten Codezeile nach ihrem Aufruf zurück.

Codezeile..
X:=Deinefunktion(datenvorgabe);
Codezeile danach
....

Das Programm führt also "Deinefunktion" mit dem Parameter "datenvorgabe" aus und schreibt das Ergebnis in X. Anschließend arbeitet der Controller die Codezeile danach ab.
Es wäre also ungünstig innerhalb der Funktion "Deinefunktion" weiter zu schachteln mit Bausteinen die nicht zum Ausführen der Funktion nötig sind.

Anders als Blockmove benutze ich FB eher sparsamer und dann meistens als Multiinstanz. In dem Fall muss man auf Schachtelung besonders achten. (Ist genau wie Siemens Multi FB)

Holger

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo an alle, vielen Dank,

Vererbung kenne ich in der Theorie, aber noch to much.

@ Blokemove: Dann hat mir jemand Quatsch erzählt, mir wurde gesagt das zum Beispiel der DaliFB der eingebunden wird damit die Wago mit der 647 kommunizieren kann, immer in einem PLC_PRG laufen muss. Habs grad getestet, läuft auch im FB der aus dem Hauptprogramm aufgerufen wird.

Für DALI oder auch andere inteligente Baugruppen kann durchaus ein eigenes Programm / Task notwendig sein.
Aber das kann man der entsprechenden Beschreibung entnehmen.
Bei Siemens kann man das mit Anlauf- oder Weckalarm-OBs vergleichen.

Gruß
Blockmove

 

[Passion4Automation]

Ich hätte das jetzt z.b. so gemacht

Plc_prg
, FB_Erdg.
,RaumA

in RaumA würde dann Beleuchtung,Heizung, Rollo, also unter anderem die ganzen Fb,s aus oscat und wago libs.
Mit RaumB gings dann weiter.

Wäre das so sinnvoll?

 

[Blockmove]

Anders als Blockmove benutze ich FB eher sparsamer und dann meistens als Multiinstanz. In dem Fall muss man auf Schachtelung besonders achten. (Ist genau wie Siemens Multi FB)

Ich bin's eben so gewohnt von der S7-Seite her.
In FCs hab ich da keine statischen Variablen und irgendwann braucht man eben doch was statisches
Also warum soll ich mich mit FCs einschränken?

Aber viele Wege führen nach Rom. Ob nun FC/FB, Merker/Global-DB, ... Egal ... Solange es sauber, klar struktueriert und gut dokumentiert ist!

Gruß
Blockmove

 

[holgermaik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hätte das jetzt z.b. so gemacht

wie immer du es möchtest. ist ok.

die ganzen Fb,s aus oscat und wago libs.

nimm an Lib's nur das was du wirklich brauchst. Bei dem 881 bist du sonst relativ schnell an der 1023 Bausteingrenze.
Holger

 

[Passion4Automation]

Werds jetzt mal so aufbauen:
Dali (PLC_PRG) also eigener Task.
Elsner Wetterstation (PLC_PRG) eigener Task
Der Rest also die Stockwerke und Räume (PLC_PRG) eigener Task und darin dann die FB,s für Global. Raum A,B, usw.

Visu werde ich über IPS machen, ggf am Anfang eine kleine Codesys WebVisu als Übergangslösung.

Die Daten aus Dali und Wetterstation muss ich halt dann über Var Global übergeben.

nimm an Lib's nur das was du wirklich brauchst. Bei dem 881 bist du sonst relativ schnell an der 1023 Bausteingrenze.

Die Libs sind echt toll für Einsteiger, hatte auch schon das Problem mit der max B-anzahl, kann man aber mit (unbebutzte Objekte ausschließen) umgehen.
Ich habe eher das Problem das mir der Speicher von 1024 kByte nicht ausreicht.

Ich habe aktuell ein kleines Projekt mit 2 ERR, 1x Rolladensteuerung mit Sonnenstands und 3 Daliadressen (2x EVG und Msensor02) der Compiler zeigt mir ungefähr folgendes an:
Größe der verbrauchten Daten: 25290 byte
Codegröße: 255786 byte

Der Codegröße nach hätte ich da schon ein viertel des Speichers der 881 verbraucht?? Oder verstehe ich das falsch?

alle bereiningen, neu übersetzen, Steuerung auf Ursprungszustand habe ich schon gemacht, sollte aber nichts mit der Codegröße des Offlineprojektes zu tun haben.

Danke.

 

[KingHelmer]

hi GoifalRacer,

da du die DALI.lib benutzt kann es natürlich sein, dass hier einige unbenutzte Bausteine der .LIB mitübersetzt werden und die Codegröße unnötigerweise in die Höhe treiben.
Du kannst im Zweifel mal Bereinigen-Übersetzen-Projekt-Optionen-Übersetzungsoption-Objekte ausschließen-"unbenutzte vom Übersetzen ausschließen".

Gerade bei den Oscat libs ist das manchmal ein Problemchen.


Zu den Tasks:

Ich nehme meine DALI-Programmierung gerne in einen gesonderten Task der mit höherer Zykluszeit läuft.
Dann werden auch keine Eingaben "unterschlagen" und gleichzeitig stört es mein restliches Programm nicht mehr.

Tasks haben auch immer den Vorteil, dass man Sie mal eben abschalten kann ohne mit auskommentieren im Programmcode arbeiten zu müssen.

Gruß,
Flo

 

[RobiHerb]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist natürlich etwas anderes ...

Jetzt musst du nur noch erklären wie du eine V3.x Runtime auf den Controller bekommst!

Holger

Wenn der entsprechende Controller nicht für V3.x zu haben ist (einige Hersteller halten die gleiche Hardware für beide Systeme vor), dann würde ich die Finger davon lassen.

Codesys 2.x ist im Prinzip tot, der Shop von 3S nimmt keine neuen 2.x Tools, Libs etc. mehr auf.

Soweit ich mitbekommen habe, wird es auch keine 2.x Update mehr geben.

Die (Hardware) Lizenznehmer sind aufgefordert, auf V3 umzustellen.

Also für die Automatisierung einer neuen Immobilie, die mindestens 30 Jahre leben soll, kein Auslaufmodell wählen.

 

[Passion4Automation]

Hi Flo,

danke für deine Antwort. Ja das mit bereinigen habe ich schon gemacht und auch geschaut ob unbenutzte Bausteine auch wirklich ausgegrünt sind.
Die Dali Bausteine brauchen halt echt Speicher, vorallem für die Konstantlichtregelung.

Das mit den Tasks muss ich erst noch testen, werde bei Dali aber auf alle Fälle einen machen.

Die 881 hat ja 1024kb Programmspeicher und 512 kb Datenspeicher.
Meine codegrösse ist beim übersetzen bei 255657 byte, heißt das jetzt das von der 881 schon ein viertel des programmspeichers belegt sein werden????

Danke.

 

[Passion4Automation]

@robiherb
Bei der 881 mach ich mir noch keine sorgen, bei der 841 schon.
Gerade als einsteiger finde ich die v2 besser weil hier die Erfahrungen größer sind. Die oscat building lib ist für v3 anscheinend auch noch nicht ganz ausgereift. Das war jedenfalls meine Kaufentscheidung.

Bei Siemens ist man ja auch nicht gleich von der S7 300 auf die 1200er oder 1500er umgestiegen, schön langsam kommen sie aber, tia v10 ist auch schon lange her.