# Datenpunte_Modbus_anlegen



## Mohamed (5 März 2021)

Hallo zusammen,


in Codesys 2.3 sind Merkerwörter Automatisch über Modbus als Slave Freigegeben. Bei e!Cockpit muss man die Datenpunte im Slave anlegen und für den Master Freigeben und die Verbindung vom Master zum Slave ziehen(Gerätstruktur). Dann in Application(Master) wird der Modbus Bereich angelegt und man kann die Variablen in Master verwenden.  gibt's keine andere Lösung, um die Datenpunkte anzulegen also nicht im Slave und das ich diesen von anderen Controllern lesen und schreiben kann??

Vielen Dank im Voraus für alle Ideen und Vorschläge.

MFG


----------



## Blockmove (5 März 2021)

Es gibt bei e!Cockpit eine Modbus Bibliothek.
Da kannst du Datenbereiche übergeben. Ziemlich ähnlich zu Codesys 2.3


----------



## Mohamed (5 März 2021)

@Blockmove
wie heißt bitte diese Bibliothek (Funktionsblock)?? hast du vllt klein Beispiel Programm??


----------



## Tobsucht (5 März 2021)

Hallo, 

der Funktionsbaustein ist der fbMbSimpleServerTCP oder fbMbSimpleServerUDP aus der Bibliothek WagoAppPlcModbus.
In der Bibliothek findest Du ein Beispiel.
Wenn Du nun das Array myHoldingRegisters so deklarierst:
 myHoldingRegisters AT %MW0 : ARRAY[12288..14000] OF WORD;

Somit ist der Merkerbereich wie "früher" erreichbar, jedoch nur im Registerzugriff.

Grüße


----------



## KLM (5 März 2021)

Übrigens kann man beim hinzufügen von Bibliothekeben auch nach Stichworten suchen und in der Registerkarte Dokumentation ist bei komplexen Bausteinen meist auch ein Bsp.


----------



## Mohamed (5 März 2021)

das Problem ist wenn es in einem Projekt (Gebäude) 50 Controllern gibt und alle Controllern zwischen einander Daten austauschen, wie wird dann das realisiert?? in Codesys 2.3 werden die Datenpunkte als Merkerwöter angelegt und geht das. wie wird das bei e!Cockpit gehen??


----------



## KLM (5 März 2021)

Wenn Du nicht gerade die voreingestellten 50ms Zykluszeit nimmst, bieten sich Netzwerkvariablen an. Der ehemalige Modbus Slave sendet per Broadcast eine NetVar Senderliste und alle anderen hören zu, wenn sie wollen mit einer NetVar Empfänger Liste. NetVar ist in einem e!C Projekt heute viel bequemer, als Modbus, weil man die Listen gleich als eine Art GVL verfügbar hat und nicht erst zusätzlich noch eine Modbus Verbindung einrichten muss. Bei vielen Controllern nehme ich gern recht hohe Zykluszeiten, also sowas wie 5..60 Sekunden und kombiniere es mit Übertragung bei Wertänderung. Letzteres aber auch mit mehr als dem voreingestellten Wert für den Mindestabstand, gerade wenn Ist-Temperaturen in den Listen sind. Brauch man im Gebäude meist eh nicht alle 20ms.
Wenn Du anstelle von Broadcast in alle Netze (255.255.255.255) nur in Dein lokales Netz broadcastest (192.168.1.255) meckert auch der IT-ler nicht. Wenn Du aber über Subnetzgrenzen hinaus willst, dann muss das meist von der IT freigeschaltet werden, weil die Broadcast hassen und auf ihren Routern sonst blocken.


----------



## Mohamed (5 März 2021)

und so musst man aber alle Controllern in einem e!Cockpit Projekt einfügen oder??


----------



## KLM (5 März 2021)

Nicht zwingend. Du kannst die Senderlisten auch ex- und importieren in andere Projekte. Aber bequemer ist es natürlich in einem Projekt. Aber bei 50 Controllern würde ich schon aufgrund der Performance auf 2..3 Projekte aufteilen.


----------



## Mohamed (5 März 2021)

1) aber so kann das Projekt nicht gleichzeitig von mehrere Mitarbeiter von verschiedenen Orten bearbeitet werden oder??
2) wenn jede Controller sendet und empfängt gleichzeitig Daten von anderen Controllern, das heisst braucht gleichzeitig eine sen- und Empfänger Liste geht das??
3) was meist du mit (Bei vielen Controllern nehme ich gern recht hohe Zykluszeiten, also sowas wie 5..60 Sekunden und kombiniere es mit Übertragung bei Wertänderung)?
jetzt bei uns ist die Zykluszeit für jede Controller 100ms (alle 100ms werden die Bausteine aufgerufen und abgearbeitet)
4) mit der Broadcast Geschichte wird das in eine Data center nicht realisierbar denke ich


----------



## KLM (5 März 2021)

1) Ginge schon, wenn die Listen zentral auf ein Laufwerk gelegt werden. Wird halt mühsamer, aber das Problem hast Du ja mit Modbus auch, da muss Du ja auch wissen welcher datenpunkt wo liegt.
2) Ein Controller kann senden und gleichzeitig mehrere Empfängerlisten haben.
3) Modbus ist immer pollend, aber NetVar kann zyklisches senden und/oder bei Wertänderung. Nachdem bei UDP nicht sichergestellt ist, dass Telegramm ankommen, sende ich zur Sicherheit zyklisch in hohem Intervall. Die eigentliche Datenunktänderung übertrage ich aber zusätzlich, um nicht auf die langen Zykluszeiten warten zu müssen. Ein flatterndes Signal in der Sendeliste würde Dir dann aber das Netzwerk dicht machen, deswegen stellt man bei Übertragung bei Wertänderung auch einen Mindestabstand ein. Der steht per Voreinstellung bei 20ms, was man bei Temeraturen nicht brauch, da reicht auch das 10-fache oder noch mehr.
4) Ja, perfekt ist auch das nicht. Ich hoffe ja auf eine baldige Verfügbarkeit eines OPC UA Client. Wenn das so bequem ist, wie der Server jetzt schon, dann wäre das löst das bei mir Modbus und NetVar ab. Aber ich vermute auch das wird Nachteile haben - ist ja schließlich keine Hollywood Romanze. Zum Datenzentrum: Das hängt davon ab, ob Du ein eigenes Subnetz für die Controller hast. Die werden wohl nicht im Netzwerk der Datenserver hängen.

Müssen bei Dir alle untereinander mit jedem kommunizieren? Oder hast Du eine zentrale Steuerung, die alle anderen ließt und beschreibt, die anderen aber nicht untereinander? Dann könntest Du auch eine kleine Schweinerei machen und die Zentrale zum einzigen Modbus Slave und alle anderen zum Master machen. Dann musst du nur aufpassen, dass jeder Master beim Slave einen eigenen Registerbreich hat. Damit kannst Du auch das sonst pollende Modbus zum System machen, dass nur bei Wertänderung überträgt. Bis auf Steuerbefehle vom jetzt Slave, die meist zahlenmäßig weniger sind, die muss der Master (ehemals Slave) halt pollen. Funktioniert recht gut, wenn man auf die Registerbereiche achtet. Aber es bleibt Modbus und das muss Du wieder konfigurieren. NetVar bleibt in der Konfiguration einfacher.


----------



## Mohamed (5 März 2021)

Bezüglich Datenzentrum da hab ich eigenes Subnetz für die Controller
es müssen nicht alle untereinander mit jedem Kommunizieren, und es gibt keine zentrale Steuerung, die alle anderen ließt und beschreibt. 
es sind manchmal 5 bis 10 die untereinander kommunizieren und ließt und beschreibt gleichzeitig.


----------



## KLM (5 März 2021)

Na dann. Alle Controller in ein Projekt und NetVar. Super einfach und effizient


----------



## Mohamed (5 März 2021)

ja NetVar sieht jetzt die beste Lösung aus. und wenn die Datenpunkte für andere eine andere Firme zu Erstellung der Visu gestellt werden sollen geht das?? weil bis jetzt die greifen auf die Datenpunkte für die Erstellung der Visu per Merker_Adressen


----------



## KLM (5 März 2021)

Wenn der Visu-Server nur Modbus kann, würde ich nicht wechseln, wäre ja doppelte Arbeit. Aber wenn der Server Codesys 2 oder 3 basiert ist, kann der auch NetVar. Egal welcher Hersteller. Aber es spricht nichts dagegen die NetVar Senderlisten auch per OPC UA zu veröffentlichen. Sind dann zwar zwei verschiedene Protokolle, aber mehr Netzwerklast ist es nicht und im e!C nur 5 Mausklicks mehr. Und viele Visu-Server sind auch UA Clients.


----------



## Mohamed (13 März 2021)

@Tobsucht
und wie liegst du deine Datenpunkte in diesem ARRAY an ??


----------



## Tobsucht (15 März 2021)

meinDatenpunkt AT %MW0 : WORD;

Ich mache es aber nicht über den Merkerbereich. Ich nutze den Datentyp Union. Das wird aber zu kompliziert sein.


----------



## NeuerSIMATICNutzer (24 Juni 2021)

Tobsucht schrieb:


> der Funktionsbaustein ist der fbMbSimpleServerTCP oder fbMbSimpleServerUDP aus der Bibliothek WagoAppPlcModbus.
> In der Bibliothek findest Du ein Beispiel.


Funktioniert das auch wenn ich gleichzeitig im Modbuskonfigurator Variablen als Datenpunkte freigebe oder beißt sich das?

VG


----------



## KLM (24 Juni 2021)

Du kannst beides parallel betreiben, wenn nicht die gleichen Ports verwendet werden. Konfigurator und Bibliotheksbausteine öffnen einen eigenen Ethernet Socket und können dazu nicht den gleichen Port nutzen. 
Nebenbei, Datentyp Union in dem Kontext von Modbus via FBs kann ich auch sehr empfehlen.


----------



## NeuerSIMATICNutzer (30 Juni 2021)

Tobsucht schrieb:


> Hallo,
> 
> der Funktionsbaustein ist der fbMbSimpleServerTCP oder fbMbSimpleServerUDP aus der Bibliothek WagoAppPlcModbus.
> In der Bibliothek findest Du ein Beispiel.
> ...


Ich benötige eher die Coils als einzelne Merker Bits z.B. ab %MX0.0.  Wie stelle ich das am besten an?
Adresse deklarieren geht ja beim ARRAY OF BOOL nicht :-(

VG

NSN


----------



## Tobsucht (2 Juli 2021)

Verwende ein Union um das Array of BOOL mit einer Struktur in den gleichen  Speicher zu legen.


----------



## Oberchefe (2 Juli 2021)

Das hilft hier nicht, beim Array of BOOL hat jedes BOOL ein Byte.


----------



## KLM (2 Juli 2021)

Bei einem Union kann man auch den Datentyp Bit verwenden


----------



## Tobsucht (2 Juli 2021)

Oberchefe schrieb:


> Das hilft hier nicht, beim Array of BOOL hat jedes BOOL ein Byte.


Ein BOOL hat generell die Größe eines Byte. Nur wenn die Variable einer Bit Speicheradresse wie QX, IX oder MX liegt wird nur ein Bit eingenommen.
Somit wird für jede BOOL Variable in einer Struktur auch ein Byte verwendet und die Variablen passen mit dem Array of BOOL zusammen.

Die Idee mit dem Datentyp BIT ist auch eine gute Idee. Man kann eine Struktur mit 16 "BITs" anlegen. Jede Variable nimmt dabei nur ein BIT und würde ein Register füllen.
Der Namensraum wird dann nur sehr lang:
Variablenliste.Union_auf_Wordarray.Struktur_mit_Variablen.Struktur_mit_Bits.Einzelbit.


----------



## Oberchefe (2 Juli 2021)

> Ein BOOL hat generell die Größe eines Byte.


Das ist schon klar dass das jetzt nicht am Array liegt


> Somit wird für jede BOOL Variable in einer Struktur auch ein Byte verwendet und die Variablen passen mit dem Array of BOOL zusammen.


Der Ansatz oben war aber, dass das Array of BOOL auf die Merkerworte schauen soll, und da passt es dann nicht zusammen, es sei denn man verschenkt 7/8 der Daten.


----------

