Codesys 3.5: GLOBAL PERSISTENT RETAIN

AW123

Level-2
Beiträge
35
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Morgen zusammen,

ich habe ein Projekt in 2.3 vor einem Jahr erstellt mit einer Variablenliste "VAR_GLOBAL PERSISTENT RETAIN".
In dieser Liste habe ich mehrere Variablen eine direkte Modbus Adresse gegeben damit auf diese mit einem
HMI zugegriffen werden kann.
Dies sah wie folgt aus:
testHMI AT%MX5.0 :BOOL ;

Wenn ich nun unter Codesys 3.5 eine Persistent Variablenliste anlege und genau diese Variablen hinein kopiere
meckert er, dass er keine Adressierung zulässt.
Muss ich hier nun jede einzelne Variable ohne Adressierung anlegen und die dann auf eine neue mit Adresse mappen?
wie zb:
xTestHMI AT%MX5.0 :BOOL ;
varPersitTestHMI :BOOL ;

xTestHMI:=varPersitTestHMI;

Oder gibt es hierfür eine andere Lösung / Möglichkeit ?

MfG AW123
 
Moin, zum einen funktioniert die Modbus Zuordnung in 3.5 nicht mehr so wie bei 2.3.
Du müsstest in dem Fall die Variable bspw. im PLC_PRG deklarieren. (Als Persistent Retain)
Wenn du in der Peristenten Liste dann über "rechte Maustaste" - > "Alle Instanzpfade hinzufügen" gehst, werden die dort hinterlegt.

Bei Codesys 2.3 war es so, sobald du eine Variable im FB als Persistent (Retain) deklariert hast, war der FB es auch. Dies wurde dann wohl geändert und mit der Liste gehandelt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Bei Codesys 2.3 war es so, sobald du eine Variable im FB als Persistent (Retain) deklariert hast, war der FB es auch. Dies wurde dann wohl geändert und mit der Liste gehandelt.
Ein FB ist in CS2.3 und CS3.5 nur dann Persistent/Retain, wenn er als solcher deklariert ist. Ist eine lokale Variable im FB als Persistent/Retain deklariert (und bei CS3.5) in der globalen Liste referenziert, ist der FB nicht automatisch auch Persistent/Retain. ABER, der FB verbraucht dennoch Retain-Speicherplatz, als wäre er es.
Und Variablen und FBs verbrauchen doppelt soviel Retain-Speicherplatz, wenn Sie lokal deklariert und in die globale Liste referenziert werden. (Gilt für CS3.5, für CS2.3 hab ich das Verhalten nicht im Kopf.)
D.h. mit nur einer kleinen Persistent/Retain-Variable lokal in einem FB deklariert (und global referenziert) kann man richtig viel unnötig NVRAM-Speicher verblasen.
Ich glaube die Möglichkeit lokal Persistent/Retain deklarieren zu können ist in der CS3.5 nur drin, um Kompatibel zu sein zu CS2.3 Projekten. Bei neu erstellten Projekten würde ich Persistent/Retain immer direkt in der globalen Liste deklarieren.
 
Ich glaube die Möglichkeit lokal Persistent/Retain deklarieren zu können ist in der CS3.5 nur drin, um Kompatibel zu sein zu CS2.3 Projekten. Bei neu erstellten Projekten würde ich Persistent/Retain immer direkt in der globalen Liste deklarieren.
Das heist man sollte immer die Variablen Global deklarieren oder?
 
Wenn man ein CS2.3 Projekt portiert und die Retains lokal deklariert sind MUSS man in die globale Liste referenzieren. Der Umbau auf global deklarieren und lokal entfernen bedeutet Aufwand. Wenn der Retain-Speicher das schafft, würde ich mir den Aufwand vermutlich nicht antun. Ist halt die Frage warum man portiert und wie viel man sowie anpassen muss und die Retains dann gleich mitmachen kann. Retains lokal innerhalb von FBs war aber unter CS2.3 schon kein guter Stil.
Bei neu angelegten CS3.5 Projekten würde ich aber immer ausschließlich global deklarieren.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
xTestHMI AT%MX5.0 :BOOL ;

Die Adressierung via AT würde ich ganz weglassen. Das ging auch unter CS2.3 schon über die Flagvariablen in der Steuerungskonfiguration besser. Eine manuelle Adressierung auf HW-Adressen birgt immer das Risiko, dass man Fehler macht und sich Speicherbereiche überlappen. Gerade wenn es ein wachsendes Projekt ist an dem man über die Zeit immer wieder Änderungen vornimmt.

Und nachdem Merker unter CS3.5 sowieso nicht mehr automatisch auf Modbus-Register gemappt werden, besteht auch kein Grund mehr für die Verknüpfung auf Merker.

In dieser Liste habe ich mehrere Variablen eine direkte Modbus Adresse gegeben

Nur um das sprachlich sauer zu trenn und keine Missverständnisse aufkommen zulassen. Merker sind nicht identisch mit Modbus-Registern (oder Adressen). Unter CS2.3 wurden die Merker automatisch auf Modbus-Register gemappt, d.h. aus dem Speicher des Prozessabbild, also Hardware-Adressen (%I, %Q und %M) wurden auf die Speicherbereiche für Modbus kopiert. Genau dieser Mechanismus existiert aber nicht mehr. Über eine Modbus Slave Konfiguration kann man nun aber gezielt definieren, welche symbolische Variable wo in den Modbus-Registern liegen soll.
 
Die Adressierung via AT würde ich ganz weglassen. Das ging auch unter CS2.3 schon über die Flagvariablen in der Steuerungskonfiguration besser. Eine manuelle Adressierung auf HW-Adressen birgt immer das Risiko, dass man Fehler macht und sich Speicherbereiche überlappen. Gerade wenn es ein wachsendes Projekt ist an dem man über die Zeit immer wieder Änderungen vornimmt.
und wie schaut dies dann aus? Die meisten Variablen habe ich Test : bool; geklariert.
Und nachdem Merker unter CS3.5 sowieso nicht mehr automatisch auf Modbus-Register gemappt werden, besteht auch kein Grund mehr für die Verknüpfung auf Merker.
Oh das ist gut zu wissen. und wie kann ich nun verschiedene Variablen auf eine Modbusadresse legen?
Da ich ein Panel verwende welches nur mit Modbus funktioniert bin ich gezwungen, die Variablen, welche relevant sind auf eine Modbusadresse
zu legen. Für ModbusSlave brauche ich ja ModbusMaster oder?
 
Das sind jetzt recht allgemeine Fragen, wie der Modbus-Konfigurator in CS3.5 funktioniert. Das ist für einen Forums-Eintrag etwas zu umfangreich. Schau doch Mal auf YouTube, da gibt es einige gute Tutorials.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also für HMI Kommunikation lege ich immer %MX oder %MW Variablen als globale Liste an, für Persistenz gibts auch ne Liste.

Bei Wago gibts zB nen Baustein ModbusSimpleServerTcp da gebe ich als Holding Register ein Array of Word rein und da sind dann von 0-x alle Merker drin.

Merker verwenden ist mittlerweile unorthodox wie an mich herangetragen wurde aber es funktioniert halt und früher haben alle Merker benutzt. Ich kann mal ein Io Mapping teilen bei interesse dann kann man mal vergleichen da gibt es ja ganz viele herangehensweisen...
 
Zurück
Oben