# eCockpit Modbusvariablen remanent



## Passion4Automation (26 April 2022)

Hallo zusammen,

unter CS2.3 habe ich die Modbusvariablen in einer GVL reingeschrieben und entsprechend z.B. Merker 12288 AT%MX0.0 als retain persistant deklariert, wie ich es brauchte.

Bei eCockpit habe ich die Möglichkeit Modbusvariablen mit dem Konfigurator zu erstellen, hier erhalte ich den Zugriff über eine Struktur.
Mit der Bibliothek erhalte ich den Zugriff über Arrays.

Wie kann ich jetzt hier variablen retain deklarieren?
Mir geht es speziell um den Fall über die Bibliothek, hier ist mein PFC der Slave und der Master ist ein Device eines Drittanbieters.

Ist es richtig wenn ich die Variable x... aus dem Array auf eine andere variable speichere und diese dann als retain deklariere und dann weiterverarbeitet?

Z.b

Var1:= Array[0.0] 
xStoerung:= Var1;

Var1 würde ich dann retain und persistant deklarieren.

Danke.


----------



## holgermaik (26 April 2022)

goifalracer schrieb:


> Var1:= Array[0.0]
> xStoerung:= Var1;


Das macht so aber keinen Sinn. Der Inhalt von Var1 wäre dann zwar nach einem Neustart weiter Verfügbar aber im 1. Zyklus würde Var1 ja durch den Inhalt von Array[0,0] überschrieben.


----------



## Passion4Automation (26 April 2022)

Hi,

Ja logisch. Hast recht.
Wie würdest du das machen?


----------



## holgermaik (26 April 2022)

goifalracer schrieb:


> Wie würdest du das machen?


Ich weiß ja nicht was du erreichen möchtest. Dazu müsstest du dein Vorhaben mal kurz erläutern.


----------



## Passion4Automation (26 April 2022)

Also mein Modbusmaster ist ein Gerät eines Drittanbieters, wenn dieser ausfällt dann steht in den Modbusadressen der Wert 0.
Das ist schlecht weil hier wichtige Prozessdaten drin sind.
Die Wago ist hier der Modbusslave und die Kommunikation wird mittels Bibliotheksbaustein hergestellt, nicht mit dem Konfigurator.

Die Modbusvariablen bzw. sind hier dann in einem Array enthalten. Dieses array wird dann im POU der Wago weiterverarbeitet, das kriege ich alles hin.

Das Projekt migriere ich gerade, alles ist fertig bis auf modbus.

Im CS2.3 habe ich für modbus einfach eine GVL erstellt und die Adressen die ich brauchte eingetragen z.B. 

Var (*flüchtig*)
%ATMX0.0: Bool;
End_Var

Var_Retain_Persistant (*nichtflüchtig*)
(*rVorgabeWindmax*) %ATDW9: Real;
End_Var

Das funktioniert seit Jahren perfekt.

Nur ecockpit ist bei Modbus sowas von anders, dass mir hier die Idee fehlt.


----------



## holgermaik (26 April 2022)

Bei CS2.3 hattest du ja ein direktes Mapping. (halte ich für eine sehr schlechte Lösung)

Da du Slave bist musst du ja irgndwie merken wann dein Datensatz vollständig übertragen wurde. (Durch ein Bit was vom Master gesetzt wird oder sonst was).
Zu diesem Zeitpunkt würde ich die Daten in einen remanenten Speicher umkopieren.
Alternativ (wenn du den Master nicht beeinflussen kannst und es kein Bit gibt) suche ein Register was niemals 0 ist und kopiere in jedem Zyklus den Datensatz in einen remanenten Speicher solange dieses Register einen gültigen Wert hat.


----------



## Passion4Automation (26 April 2022)

> Bei CS2.3 hattest du ja ein direktes Mapping. (halte ich für eine sehr schlechte Lösung)


Also hier mit der Bibliothek arbeiten???



> Da du Slave bist musst du ja irgndwie merken wann dein Datensatz vollständig übertragen wurde. (Durch ein Bit was vom Master gesetzt wird oder sonst was).
> Zu diesem Zeitpunkt würde ich die Daten in einen remanenten Speicher umkopieren.
> Alternativ (wenn du den Master nicht beeinflussen kannst und es kein Bit gibt) suche ein Register was niemals 0 ist und kopiere in jedem Zyklus den Datensatz in einen remanenten Speicher solange dieses Register einen gültigen Wert hat.


An sowas dachte ich auch schon.
Ich schätze das ich in 2 Wochen soweit bin das ich einen Master zum testen aufgesetzt habe, wenn es nicht klappt stelle ich mal die aktuelle Situation hier rein.
Danke schon mal.


----------



## holgermaik (26 April 2022)

holgermaik schrieb:


> Bei CS2.3 hattest du ja ein direktes Mapping. (halte ich für eine sehr schlechte Lösung)





goifalracer schrieb:


> Also hier mit der Bibliothek arbeiten???


Direktes Mappen in den Speicher ist halt so eine Sache
Vorteile:
- sehr einfach umzusetzen
Nachteile:
- keine Kontrolle über Alter der Daten
- keine Kontrolle ob die Daten vollständig sind
- keine Kontrolle über die Herkunft der Daten ( hat der berechtigte Master geschrieben oder wer anderes)

m.M.n ist ein Handshake über die Kommunikation bei wichtigen Prozessdaten schon wichtig


----------



## KLM (26 April 2022)

Wenn der Master ausfällt und keine Daten mehr sendet, bleiben die letzten Werte im Slave doch erhalten. Zu einem Problem kommt es nur, wenn der Slave einen Neustart macht UND der Master dann nicht sendet.
Nachdem man Variablen einer persitenten Liste nicht im Konfigurator veröffentlichen kann, bliebe sonst nur das Kopieren in der Modbus Variablen in den Retain-Speicher oder die Verwendung der Bibliotheksbausteine.


----------



## Passion4Automation (26 April 2022)

Hi KLM,
Wenn meine SPS (slave) neustartet oder Spannungsausfall hat dann muss ich die Daten im retain Speicher haben. Dann ist nach Neustart alles gut.

Das habe ich gefunden, ich glaube das löst mein Problem.






Kann ich den SimpleMasterTCP eigentlich zwei mal im POU  instanzieren, weil dann könnte ich Arrays für den retain Bereich seperat zu Arrays für den nicht retain Bereich verwalten..??
Dann würde ich bei ca. 200 nicht retains und 50 retains mir eine Menge an  retain Speicher sparen.

Ich hätte für die Unterscheidung der beiden Bausteine einfach zwei Ports verwendet z.B
Retain 503
Nicht retain 504

Mein Master würde dieses konfig hergeben.


----------



## KLM (26 April 2022)

Eine zweite Instanz von des TCP FB bedeutet auch eine zweite TCP Verbindung, d.h. Du müsstest einen anderen Port definieren. Dann muss auch Dein Master zwei TCP Verbindungen zu zwei Ports öffnen.


----------



## Passion4Automation (26 April 2022)

ich habe gerade nachgeschaut, ich kann beim Master jede Variable einer beliebigen IPv4 Adresse und dazu einen beliebigen Port festlegen.
Dann könnte ich die Retains schön von den anderen trennen. Ich teste das die nächsten Tage mal.


----------



## KLM (27 April 2022)

Kann man machen, aber damit sparst Du nur 200 Variablen im Retain-Speicher (NVRAM). Der ist zwar der kleinste Speicher, aber bei 200 Var. mit max. 4 Byte (theoretisch auch 8, aber in der Praxis eher selten) sparst gerade mal 800 Byte ein. Den Mehraufwand würde ich mir nur antun, wenn der NVRAM zur neige geht.


----------



## Passion4Automation (27 April 2022)

Ich verwende nur die HoldingRegisters vom FB, da Variablen die remanent sein sollen sind z.B. aus der Visu einstellbare Jalousienpostionen, Schwellwerte für die Gebäudeautomation, alles Dinge die verstelbar sein sollen aus der Visu.
In dem Array sind auch noch viele Temperaturwerte und Statuswerte  die zum Master zurückgelesen werden, diese Ändern sich ständig, da Istwerte.

Diese sollten nicht in den Retain Speicher, deswegen wollte ich auf 2 Arrays aufteilen.


----------



## KLM (27 April 2022)

In dem Fall muss ich Dir Recht geben. Sich ständig ändernde Werte, wie Ist-Temperaturen, würde ich auch nicht in den NVRAM packen. Der ist mit seinen reduzierten Schreib-/Lesezyklen eher ungeeignet. Wenn der Master die zwei Verbindungen mit wenig Aufwand unterstützt, fällt mir so auf die Schnelle auch keine bessere Idee ein.


----------

