[Programmierstil] Was gehört in die Globale Variablenliste

[JüKo]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo an alle,
wenn ich Variablen deklariere, dann schreibe ich die Variablen die an einem Ein- Ausgang liegen in die Globale Variablenliste. Welche weiteren Variablen schreibt ihr noch da rein? Für den Austausch innerhalb der POUs brauch ich das ja nicht. Meine Frage zielt nicht darauf ab wie das Programm funktioniert, sondern wie ein ordentlicher Programmierstil aussieht.
Danke und Grüße,
Jürgen

 

[oliver.tonn]

Hallo Jürgen,
erstmal ein Link bezüglich wie man einen Thread anlegt.
Globale Variablen sollte man so wenig wie möglich nutzen. Für I/Os nutze ich Sie gar nicht, I/O-Variablen erstelle ich direkt in den FBs, allerdings ist TwinCAT da besonders komfortabel mit dem %I* oder %Q* Konstrukt, da man keine Adresse angeben muss.
Für welche SPS sollen die Hinweise denn gelten?

 

[asci25]

Zuviel Werbung?
-> Hier kostenlos registrieren

In dser globalen Varablenliste deklariere ich höchsten ein paar Instanzen von FB's und habe die ein oder andere Konstante. I/O's gehören meiner Meinung nach seltenst in die GVL, wenn man objektorientiert vorgehen will.

Um einen guten Programmierstil mal bildlich zu beschreiben: Ein Baum ohne Wäscheleinen, alles andere ist Spagetti.

 

[asci25]

... allerdings ist TwinCAT da besonders komfortabel mit dem %I* oder %Q* Konstrukt....

Das können die anderen Steuerungen auch, allerdings muss man dann die Variablenkonfiguration manuell ausfüllen. TwinCAT macht das nur automatisch vom Systemmanager aus.

 

[oliver.tonn]

Das können die anderen Steuerungen auch, allerdings muss man dann die Variablenkonfiguration manuell ausfüllen. TwinCAT macht das nur automatisch vom Systemmanager aus.

OK, danke, wieder was gelernt, ich dachte, dass man z.B. bei WAGO immer eine Adresse angeben muss.

 

[asci25]

Zuviel Werbung?
-> Hier kostenlos registrieren

... ich dachte, dass man z.B. bei WAGO immer eine Adresse angeben muss.

Bei Wago im Codesys 2.3 kenne ich drei Möglichkeiten:
1. Du trägst einen Variablennamen direkt in der Steuerungskonfiguration ein, dann hast Du zwar keine Probleme, wenn sich durch Änderungen Adressverschiebungen ergeben, aber Du bist Global.
2. Du deklarierst einfach global Adressbehaftet, das ist die schlechteste aller Möglichkeiten, weil Du bist Global und musst bei Adressverschiebungen nachsteuern
3. Du deklarierst in den Instanzen mit I* und Q*, dann kannst Du die Einträge in der Variablenkonfiguratin zwar automatisch durch den Editor eintragen lassen, musst aber die Adressen manuell eingeben. Bei einer Adressverschiebung musst Du aber auch hier nacheditieren.

Alles Mist. Ich arbeite deswegen nach Möglichkeit auch nur mit TwinCAT - das hat schon das gewisse Etwas.

 

[JüKo]

Hallo Oliver, stimmt der Link von oben,wie man einen Thread anlegt? Und mit einem FB, meinst Du damit ein POU Programm? Laufen soll das Programm auf einer Pixtend-Hardware.
Danke und freundliche Grüße,
Jürgen

 

[oliver.tonn]

Und mit einem FB, meinst Du damit ein POU Programm? Laufen soll das Programm auf einer Pixtend-Hardware.

Ja, damit meine ich ein POU vom Typ Funktionsbaustein.

 

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Jürgen,

meiner Meinung nach gehören folgende Variablen in die globale Variablenliste:

• Konstanten, die man programmweit nutzen möchte
• Konfigurationen, die man programmweit nutzen möchte
• Variablen (Symbole), die veröffentlicht werden sollen, für Kommunikation oder HMI - dafür legt man dann geschickterweise eine eigene Tabelle an, die man dann einzeln frei geben kann
• Retain-Daten

Und diese Kategorien kann man schön in separaten Listen halten, so daß es übersichtlich bleibt.

Gruß
Jens

 

[asci25]

• Variablen (Symbole), die veröffentlicht werden sollen, für Kommunikation oder HMI - dafür legt man dann geschickterweise eine eigene Tabelle an, die man dann einzeln frei geben kann

Hi Jens,

dem einen Punkt würde ich gezielt widersprechen wollen. Das habe ich genau einmal in meinem ersten Groß-Projekt, damals noch mit Siemens, gemacht.
Was für einen Aufwand.

Ich lege HMI-Symbole ganz normal mit in den Funktionsbaustein, wo die verarbeitet werden. Dann musst Du die nicht über die Schnittstelle, vieleicht noch über mehrere Ebenen, rausführen.
Du musst nichts extra deklarieren, weil das bereits mit der Instanziierung des FB erledigt ist.

Der Zugriff vom HMI aus erfolgt dann über den Instantzpfad.

Außer, das HMI oder die SPS kann das nicht, dann würde ich aber zügig wechseln.

 

[DeltaMikeAir]

Ich lege HMI-Symbole ganz normal mit in den Funktionsbaustein, wo die verarbeitet werden. Dann musst Du die nicht über die Schnittstelle, vieleicht noch über mehrere Ebenen, rausführen.
Du musst nichts extra deklarieren, weil das bereits mit der Instanziierung des FB erledigt ist.

Der Zugriff vom HMI aus erfolgt dann über den Instantzpfad.

Diese Lösung darf man nur nicht mehr bei der S7-1500/1200 verwenden, aufgrund des fehlenden Zykluskontrollpunkt.
D.h. die Daten werden unkontrolliert im laufenden Zyklus abgeholt. Gut, hier geht es um CoDeSys aber nur als kurze
Anmerkung.

 

[asci25]

Zuviel Werbung?
-> Hier kostenlos registrieren

Diese Lösung darf man nur nicht mehr bei der S7-1500/1200 verwenden, aufgrund des fehlenden Zykluskontrollpunkt.
D.h. die Daten werden unkontrolliert im laufenden Zyklus abgeholt. Gut, hier geht es um CoDeSys aber nur als kurze
Anmerkung.

Wieso? Das habe ich schon bei den 300er CPUs erfolgreich so gemacht. Datenkonsistenz spielt bei einem langsamen HMI's wohl weniger eine Rolle und einfache Datentypen wie Real, Time usw. sind über ihre Länge immer konsistent, weil alle Bytes "gleichzeitig" gelesen oder geschrieben werden. Dabei ist es auch bei Siemens-CPU's völlig egal, ob du die Daten aus einem Global-DB oder Instanz-DB holst - ist immer das gleiche Problem. Bei Verwendung eines Istanz-DB's musstest Du bei einer 300/400er nur einen Datenbereich so festlegen, dass der sich bei Änderungen nicht verschiebt oder Du arbeitest symbolisch.

Die 1500er sind doch bestimmt per se symbolisch - oder? Ich bin auf TwinCAT umgestiegen, weil besser als TIA. Ich habe hier noch eine neue 1500er CPU rumliegen, habe die aber nie verwendet. TIA hat so genervt, dass ich das nicht mehr wollte.

 

[DeltaMikeAir]

Wieso? Das habe ich schon bei den 300er CPUs erfolgreich so gemacht...

300ér kann man nicht mehr mit der 1200/1500ér vergleichen. Bei der 300ér gibt es einen Zykluskontrollpunkt. D.h. die Daten die das HMI abholt
entsprechen dem Zustand am Zyklusende der 300ér.

Bei der 1200/1500ér gibt es den Zykluskontrollpunkt nicht mehr. Die Daten werden im laufenden Zyklus abgeholt und dies kann die wildesten Folgen
haben. Daher muss man nun selber dafür sorgen, dann man Daten am Zyklusende in einen Übergabe-DB schreibt.

 

[asci25]

*ROFL**ROFL*
Echt jetzt? Dann habe ich jetzt einen weiteren Grund Siemens-Projekte abzulehnen.

Übergabe-DB? das ist ja wie vor 30 Jahren!

Bist Du Dir absolut sicher, dass das bei den 1500er anders nicht geht. Ich meine die Datenkosistenz auf der unteren Ebene bis 4 oder 8 Byte ist doch immer gegeben. Hast Du da schlechte Erfahrung mit gemacht?

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hier mal ein guter Beitrag dazu:
https://www.sps-forum.de/simatic/82310-zykluskontrollpunkt-s7-1500-a.html#post620532

Ich meine die Datenkosistenz auf der unteren Ebene bis 4 oder 8 Byte ist doch immer gegeben.

Es geht nicht um die Datenkonsistenz einer Variable sondern darum, dass der Punkt wann sie von der SPS geholt wird undefiniert ist.

 

[PN/DP]

Ich lege HMI-Symbole ganz normal mit in den Funktionsbaustein, wo die verarbeitet werden. Dann musst Du die nicht über die Schnittstelle, vieleicht noch über mehrere Ebenen, rausführen.
Du musst nichts extra deklarieren, weil das bereits mit der Instanziierung des FB erledigt ist.

Der Zugriff vom HMI aus erfolgt dann über den Instantzpfad.

Diese Lösung darf man nur nicht mehr bei der S7-1500/1200 verwenden, aufgrund des fehlenden Zykluskontrollpunkt.
D.h. die Daten werden unkontrolliert im laufenden Zyklus abgeholt. Gut, hier geht es um CoDeSys aber nur als kurze
Anmerkung.

Wieso? Das habe ich schon bei den 300er CPUs erfolgreich so gemacht...

Daß Du dann innerhalb des FB eine Übergabeschnittstelle für die HMI-Variablen basteln müsstest ist Dir bewußt?
Bei Übergabe über die Bausteinschnittstelle bekommt man automatisch konsistente Kopien der HMI-Variablen. Wenn die HMI direkt in der Instanz liest oder schreibt, dann muß man selber extra für ein konsistentes Abbild der HMI-Variablen sorgen.

Die S7-300 in der Einstellung ohne BuB-Priorisierung war da noch gutmütig zu den unbedarften Programmierern, bei S7-400/1200/1500 muss man wegen dem fehlenden Zykluskontrollpunkt für HMI-Kommunikation schon mehr nachdenken was man tut.

PS: mit konsistent ist weniger gemeint, ob Variablen in sich konsistent gelesen/geschrieben werden, sondern daß die Werte der Variablen zeitlich konsistent sind, daß am Anfang des Instanz-Durchlaufs die Werte anders sein können als am Ende, was man abfangen/vermeiden muß.

Harald

 

[DeltaMikeAir]

Kleines einfaches Beispiel:

Die Variable "Farbe[0..99]" steuert an 100 animierte Rechtecke an deiner Visu

Nun steht im Code:

// alle Farbvariablen pauschal abloeschen
FOR i := 0 TO 99 DO                                       
    Farbe[i] := 0;                                        [COLOR=#FF0000]<= Mal wird die Variable hier abgeholt ( Status vielleicht schon 0 )[/COLOR]
END_FOR;                                                  [COLOR=#ff0000]<= Mal wird die Variable hier abgeholt ( jetzt auf jeden Fall 0 )[/COLOR]


// Farbe zuweisen
FOR i := 0 TO 99 DO                   
    Farbe[i] := 1;                                        [COLOR=#ff0000]<= Dann wird sie mal hier abgeholt, jetzt vielleicht schon auf 1[/COLOR]
END_FOR;                                                  [COLOR=#ff0000]<= Dann mal hier, jetzt auf jeden Fall 1.....[/COLOR]

Nur mal als einfaches Beispiel ohne großen Sinn dahinter. Man geht also nun davon aus, dass an der HMI immer an allen 100 Variablen der Farbstatus 1 angezeigt wird.
Dem ist aber nicht so. Alle Variablen zeigen die meißte Zeit den Farbstatus 1 an, werden aber ständig flimmern auf Farbstatus 0 weil die Farbvariable immer wieder mal
abgeholt wird, wenn der Status gerade 0 ist. Und das ist dann kein seltenens Phänomen sondern wenn die dies einmal so projektierst wird alles ständig flimmern.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

*ROFL**ROFL*
Echt jetzt? Dann habe ich jetzt einen weiteren Grund Siemens-Projekte abzulehnen.

Übergabe-DB? das ist ja wie vor 30 Jahren!

Bist Du Dir absolut sicher, dass das bei den 1500er anders nicht geht. Ich meine die Datenkosistenz auf der unteren Ebene bis 4 oder 8 Byte ist doch immer gegeben. Hast Du da schlechte Erfahrung mit gemacht?

Das Thema Zykluskontrollpunkt gab es auch schon bei S7-400er Steuerungen.
Ob man es nun mit einem Übergabe-DB oder anders löst, ist eigentlich egal.
Ursache ist schlichtweg, dass die Kommunikation zu HMI oder auch anderen Geräten asynchron läuft.
Ich bin mir gerade nicht sicher, aber bei Beckhoff und anderen Codesys-Steuerungen gibt es das Thema doch auch?

 

[JSEngineering]

Hi Jens,

dem einen Punkt würde ich gezielt widersprechen wollen. Das habe ich genau einmal in meinem ersten Groß-Projekt, damals noch mit Siemens, gemacht.
Was für einen Aufwand.

Ich lege HMI-Symbole ganz normal mit in den Funktionsbaustein, wo die verarbeitet werden. Dann musst Du die nicht über die Schnittstelle, vieleicht noch über mehrere Ebenen, rausführen.
Du musst nichts extra deklarieren, weil das bereits mit der Instanziierung des FB erledigt ist.

Der Zugriff vom HMI aus erfolgt dann über den Instantzpfad.

Außer, das HMI oder die SPS kann das nicht, dann würde ich aber zügig wechseln.

Moin,

da muß ich aber gezielt widersprechen!
Bei Deiner Lösung gibst Du entweder alle Variablen einer Instanz frei oder Du mußt Dir aus jeder Instanz die zu veröffentlichenden Variablen raussuchen!
Da sage ich: Was für ein Aufwand.

Einmal nachgedacht und die notwendigen Variablen in einer Variablentabelle deklariert, gebe ich genau diese Variablen frei, mit einem Klick.
Sofern ich dann noch Schreib- und Lesezugriffe unterscheiden möchte, geht das auch ganz prima und einfach, indem ich ganze Listen oder Blöcke innerhalb der Liste markiere.

Wozu einzelne Variablen freigeben? Datenschutz, Datensicherheit, Know-How-Schutz, Effizient beim Zuweisen der Variablen im HMI, denn ich muß nicht aus 20.000 Variablen aus allen Instanzen raussuchen, sondern nur aus 500, die ich veröffentlicht habe.

Und am Ende kommt dann noch die nun geführte Debatte um Datenkonsistenz oben drauf.

Gruß
Jens

 

[asci25]

Kleines einfaches Beispiel:

Die Variable "Farbe[0..99]" steuert an 100 animierte Rechtecke an deiner Visu

Nun steht im Code:

// alle Farbvariablen pauschal abloeschen
FOR i := 0 TO 99 DO                                       
    Farbe[i] := 0;                                        [COLOR=#FF0000]<= Mal wird die Variable hier abgeholt ( Status vielleicht schon 0 )[/COLOR]
END_FOR;                                                  [COLOR=#ff0000]<= Mal wird die Variable hier abgeholt ( jetzt auf jeden Fall 0 )[/COLOR]


// Farbe zuweisen
FOR i := 0 TO 99 DO                   
    Farbe[i] := 1;                                        [COLOR=#ff0000]<= Dann wird sie mal hier abgeholt, jetzt vielleicht schon auf 1[/COLOR]
END_FOR;                                                  [COLOR=#ff0000]<= Dann mal hier, jetzt auf jeden Fall 1.....[/COLOR]

Nur mal als einfaches Beispiel ohne großen Sinn dahinter. Man geht also nun davon aus, dass an der HMI immer an allen 100 Variablen der Farbstatus 1 angezeigt wird.
Dem ist aber nicht so. Alle Variablen zeigen die meißte Zeit den Farbstatus 1 an, werden aber ständig flimmern auf Farbstatus 0 weil die Farbvariable immer wieder mal
abgeholt wird, wenn der Status gerade 0 ist. Und das ist dann kein seltenens Phänomen sondern wenn die dies einmal so projektierst wird alles ständig flimmern.

So und dann erweitere ich Dir Dein Beispiel mal ganz einfach mit

FOR i := 0 TO 99 DO                   
    stHmi.Farbe[i] := Farbe[i];                                        
END_FOR;

Und schon bist Du das Problem los. So funktioniert übrigens Multitreading abseits der SyncLock-Mechanismen.
Und das Ganze geht immer noch in der Instanzebene.

stHmi ist übrigens immer meine Standard-Struktur, die die Schnittstelle zu HMI enthält. So finden sich auch Fremdprogrammiere gut zurecht.