Neue Version V3 IP2 verfügbar für alle Modelle des Timberwolf Servers

HTTP-/REST-API, Grafana 8.2, Verknüpfungsassistent 2.0 und vieles mehr!

Infos: viewtopic.php?f=8&t=3006

[NEUHEIT] Neues Leistungsmerkmal - Modbus RTU als Client (Master) und Modbus TCP als Client (Master)

Wissen, Planung & Diskussion zur Modbus Unterstützung im Timberwolf Server.
Stellt uns hier Eure Modbus Projekte und Ideen vor.

Ersteller
StefanW
Elaborated Networks
Reactions:
Beiträge: 5957
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Grafing
Hat sich bedankt: 2826 Mal
Danksagung erhalten: 4338 Mal
Kontaktdaten:

Neues Leistungsmerkmal - Modbus RTU als Client (Master) und Modbus TCP als Client (Master)

#1

Beitrag von StefanW »

Sehr verehrte Nutzer,

die neue Version 2.0 wird das neue Leistungsmerkmal Modbus erhalten.


Leistungsmerkmal Modbus

Wir freuen uns sehr, nach nun drei Mannjahren der Entwicklung, das neue Leistungsmerkmal Modbus auszurollen.

Die Modbus Implementierung im Timberwolf Server weist eine ganze Reihe von Leistungsmerkmalen - davon viele Alleinstellungsmerkmale - auf:

No Limits
  • Unbeschränkte Anzahl von Modbus Universen: es können beliebig* viele Modbus-Subsysteme definiert werden
  • Unbeschränkte Anzahl von angeschlossenen Modbus Geräten: Über alle Subsysteme hinweg können beliebig* viele Modbus Geräte angeschlossen werden
  • Unbeschränkte Anzahl von Datenpunkten: Keine Beschränkung* oder separate Lizenzierung der Anzahl von Datenaustauschpunkten
  • Unbeschränkte Anzahl von Lese- oder Schreiboperationen auf ein Gerät: Keine Beschränkung* der Anzahl an konfigurierbaren Lese- oder Schreiboperationen auf Modbus Geräte.
  • Extrem kurzes Abfrageintervall: Praktisch keine Beschränkung* beim Abfrageintervall, es kann ab 10 ms definiert werden. Bitte achten Sie auf die entstehende Bus- und Serverlast und ob die Modbus Geräte dies unterstützen.
  • Nahezu beliebige Dekodierung / Kodierung: Die Dekodierung / Kodierung der Datenformate ist beinahe beliebig* konfigurierbar.

Protokolle, Rollen
  • Unterstützte Protokolle: Unterstützung von Modbus RTU über serielle Schnittstellen und Modbus TCP über Ethernet
  • Parallele Modbus Universen: Unlimitierte Anzahl von Modbus Universen parallel am Timberwolf Server durch Virtualisierung, alle Modbus Universen sind vollständig unabhängig voneinander
  • Unterstützte Modbus Rollen: Unterstützung in der Rolle als Client (früher als „Master“ bezeichnet)
  • Administration: Verwaltung der Modbus Schnittstellen in einer grafischen Schnittstellenverwaltung
  • Verbindungsstatistiken: Verbindungsstatistiken für Anzeige in der Schnittstellenverwaltung für Qualitätsanzeige

Einfaches Gerätemanagement durch ladbare Geräteprofile
  • Profilverwaltung: Grafische Verwaltung der lokal gespeicherten Modbus Profile in einer Datenbank mit Suche und Filter
  • Profilaustausch: Import und Export der Profile über json Datei, damit einfache Nutzung auf anderen Timberwolf Servern
  • Weltweit einmalige Profil-IDs: Timberwolf Server Modbus Profile haben weltweit eine eindeutige ID
  • Veränderungssperre: Genutzte, exportierte oder importierte Profile sind über digitale Signaturen gegen Veränderungen gesperrt, damit enthalten weltweit alle Geräteprofile mit der gleichen ID die gleiche Definition
  • Interaktiver Profileditor: Interaktiver grafischer Profileditor unterstützt bei der Erfassung und Test der Datenaustauschpunkte

Datenzugriff und Datenkodierung
  • Datenzugriffsverfahren: Unterstützung aller relevanten Funktionscodes für 1 und 16 Bit Operationen, jeweils Single- und Multi-Register
  • Zusammenfassende Registerzugriffe: Zugriffe mit 32 / 48 / 64 / 96 / 128 / 256 Bit auf zusammenhängende Register
  • Universell konfigurierbare Dekodierung / Kodierung: Universell konfigurierbare Dekodierung / Kodierung der binären Datenformate der Modbus Geräte
  • Datenreihenfolge: Einstellbare Datenreihenfolge für 16 / 32 / 64 Bit (8 Versionen für Big-Endian und Little-Endian mit allen möglichen Mischformen)
  • Bitmaske: Bitmaske zur Selektion beliebiger Daten aus lesenden Registerabfragen von 16 / 32 / 48 / 64 Bit
  • Datenformate: Kodierung und Dekodierung der Datentypen Ganzzahl, vorzeichenbehaftete Ganzzahl mit Einerkomplement und Zweierkomplement, Fließkomma 16 / 32 / 64 Bit sowie ASCII Text.
  • Format Assistent mit Live-Check: Definition für Datenreihenfolge, Bitmaske und Dekodierung mit grafischem Formatassistenten inkl. Live-Check

Wertprüfung / Wertanpassung / Objekt-Typ / Einheit
  • Wertprüfung vor Weiterverarbeitung: Umfassende Wertprüfung der Leseanforderungen auf Gültigkeit, ebenso umfassende Wertprüfung vor Schreiben auf das Modbus Gerät, hierdurch können ungültige, falsche oder gefährliche Werte unterdrückt werden
  • Wertanpassungen und Umrechnungen: Umrechnung mit festen Faktoren oder frei eingebbarer Formel
  • Datentypkonvertierung: Konvertierung für das Timberwolf Objektsystem in Bool, Ganzzahl, Fließkomma oder Text
  • Definition der physikalischen Einheit: Verwaltung der physikalischen Einheiten für eine optimierte Darstellung
  • Assistent für Wertprüfung, Wertanpassung und Konvertierung mit Live->Check: Definition für Wertprüfung, Wertanpassung, Konvertierung und Einheit mit grafischem Assistenten inkl. Live-Check

Live-Diagnose & Live-Check
  • Diagnose Werte live abrufen: Live-Diagnose durch Abfrage der Diagnose-Register der Modbus Geräte direkt aus dem Profil Editor
  • Werte von Modbus Geräten live lesen oder schreiben: Live-Check der Gerätekommunikation während der Profilerfassung, Prüfung nach jedem (!) Klick, damit erhebliche Vereinfachung durch vollständige interaktive Definition, auch mit direkten Schreibkommandos aus der Oberfläche
  • Busmonitor für alle Modbus Bussysteme: Modbus Busmonitor für schnelle Übersicht und Diagnose

Geräteinteraktionen im Modbus Geräte Manager verwalten
  • Intervall: Der minimaler Intervall zwischen zwei Abfragen beträgt nur 10 ms
  • Mehrfachabfragen: Mit einem Zugriff können bis zu 16 Register zu 16 Bit am Stück gelesen oder geschrieben werden
  • Gruppierte Leseaufgaben mit frei wählbarem Intervall: Anlegen und verwalten - auch gruppierter - Leseaufgaben mit frei wählbarem Intervall
  • Sendefilter für effiziente Kommunikation: Konfiguration von Sendefiltern für jeden einzelnen Wert, basierend auf Zeit und / oder Wertänderung
  • Gruppierte Schreibaufgaben mit frei wählbarem Auslöser: Anlegen und verwalten - auch gruppierter – Schreibaufgaben mit frei wählbaren Auslösern, basierend auf Intervall und / oder Wertänderung
  • Objektverknüpfungen: Beliebige Verknüpfung mit allen anderen Objekten im Objektsystem des Timberwolf Servers (Zeitserien, KNX, 1-Wire, DMX, Logik, andere Modbus Systeme und künftig auch MQTT, UDP/TCP, Web-API, Clouds usw.)

*Interpretation von "beliebig viele", "Keine Beschränkung": Dies bedeutet, dass in der Firmware keine harten Limits hinterlegt sind. Wir entwickeln Server und Software für eine maximale Leistungsfähigkeit im Rahmen der technischen Möglichkeiten und des Budgets. Wir glauben an die Mündigkeit der Nutzer und erlauben es, die Systemressourcen des Timberwolf Servers und angeschlossener Geräte im gewählten Umfang zu nutzen.
Ein Produkt wie der Timberwolf Server wird im Zusammenhang mit komplexen Netzwerken und Protokollen (KNX, Ethernet, 1-Wire, DMX, Modbus und künftig auch MQTT usw.) genutzt. Die Zusammenstellung der Anlagen der Nutzer ist sehr unterschiedlich, kein Kunde hat genau die gleiche Konstellation. Alleine die Vielzahl der anschließbaren Komponenten geht in die zehntausende, die möglichen Einstellungen und Konfigurationen sind unzählig. Entsprechend kann nicht jedes Szenario getestet werden und mit jedem Update des Timberwolf Servers und / oder anderen Komponenten und deren Konfigurationen können potentiell Inkompatibilitäten entstehen.
Durch Verzicht auf Beschränkungen in der Firmware ist - insbesondere durch Kombination mit anderen Einstellungen - eine Übernutzung von Ressourcen denkbar und möglich, die Probleme verursachen kann. Der Verzicht auf harte Beschränkungen bedeutet nicht, dass jede denkbare Konfiguration in jeder Kombination auch möglich bzw. der Timberwolf Server, die verbindenden Bussysteme, die angeschlossenen Geräte dies unterstützen wie konfiguriert oder die Browser die entstehenden Tabellen in jedweder Länge laden werden. Wir bitten die Nutzer die zeitlichen Intervalle nicht zu kurz zu fassen, vernünftige Sendefilter anzulegen und das Datenaufkommen insgesamt im Auge zu behalten.



Übersicht Modbus

Tatsächlich gibt es nicht nur ein "Modbus" sondern acht Varianten von denen vier Varianten gebräuchlich sind. Im folgenden zuerst eine kurze Einführung und folgend eine Kurzbeschreibung der Umsetzung im Timberwolf Server.

Modbus wurde 1979 von dem Unternehmen Modicon als serielles Kommunikationsprotokoll zur Verwendung mit seinen speicherprogrammierbaren Steuerungen (SPS) veröffentlicht. Die Protokollsammlung Modbus dient der Übertragung von Informationen zwischen elektronischen Geräten. Modicon wurde 1988 zunächst durch die Daimler AG (AEG) und schließlich 1994 von der Schneider Electric SE übernommen. Der Modbus Standard wird von der Modbus Organisation, Inc, einer in den USA registrierten unabhängigen, nur von den Mitgliedern getragenen non-profit Organisation, verwaltet.

Zunächst wurde Modbus für die Kommunikation über serielle Schnittstellen implementiert, später wurde das Protokoll um die Kommunikation über IP-Netzwerke ("Modbus TCP") erweitert. Seit Oktober 2018 steht hierfür auch die Erweiterung um eine TLS Verschlüsselung und Absicherung über digitale Zertifikate zur Verfügung.

Dasjenige Gerät, das die Informationen anfordert oder schreibt, wird als Modbus Client (früher der „Master“) bezeichnet, während die Geräte, deren Informationen abgefragt werden als "Modbus Server" (früher „Slave“) bezeichnet werden. Die Kommunikation wird immer nur vom Client (früher als „Master“ bezeichnet) gesteuert.

Im Juli 2020 hat die Modbus Organisation – im Rahmen der zu der Zeit in den USA aufgekommenen Rassismus-Debatte – entschieden, zukünftig die vormaligen technischen Rollenbezeichnungen „Master“ und „Slave“ durch „Client“ und „Server“ zu ersetzen. Künftig soll die bisher als „Master“ bezeichnete Rolle als der steuernde „Client“ bezeichnet werden und das angesteuerte Gerät wird künftig als „Server“ bezeichnet. Wir begrüßen die neuen sensitiven Bezeichnungen und werden diese in Beschreibungen und in der Benutzeroberfläche sukzessive umsetzen.

Hinweise:
Wir bitten zu beachten, dass wir alle an den Timberwolf Server angeschlossenen technischen Systeme (unabhängig vom Protokoll) jeweils als „Gerät“ bezeichnen.

Bitte achten Sie darauf, bei diesem Client-Server-Konzept den steuernden Timberwolf Server nicht mit der Rolle eines Modbus Gerätes als „Server“ (vormals als „Slave“ bezeichnet) zu verwechseln. Die Modbus Subsysteme des Timberwolf Server agieren als steuernder Modbus Client der auf die Geräte zugreift (die sich als die gesteuerten Modbus Server verhalten).


Verwendungszweck Modbus

Modbus wird seit 50 Jahren in der Industrie für Sensornetze und Messwertaufbereitung und zunehmend in der Gebäudeautomatisierung verwendet. Seit mehr als 15 Jahren ist Modbus der De-Facto Standard für die Steuerung von Wärmepumpen, Systemen der HKL-Technik, in PV-Wechselrichtern und wird genutzt in Hausbatteriesystemen und Ladestationen für Elektrofahrzeuge. Ein besonders umfangreiches Angebot existiert für Modbus Energiezähler und Smartmeter, die bereits ab einem unteren zweistelligem Eurobereich erhältlich sind.
  • Smartmeter: Für Modbus stehen äußerst preisgünstige Smartmeter und Zähler zur Verfügung
  • E-Mobility: Die meisten Wandladestationen sind Modbus fähig
  • Photovoltaik: Sehr viele PV-Wechselrichter geben den Status per Modbus aus
  • Hausbatterien: Eine Vielzahl von Batterie-Steuerungen lassen sich per Modbus einbinden
  • Heizungssteuerungen: Einige Heizungs- und Wärmepumpensteuerungen sind ebenfalls per Modbus steuerbar
  • Sensoren: Für Modbus existiert sowohl ein breites Angebot an sehr günstigen Sensoren als auch für den professionellen Einsatz in der Industrie
  • Industrie: Sammeln, Umrechnen und Zusammenfassen von Messwerten inkl. Langzeitaufzeichnung und grafischer Auswertung sowie , Umrechnung von Modbus Systemen für übergeordnete SCADA Systeme

Übersicht der Modbus Implementierung im Timberwolf Server

Der Timberwolf Server wird ab Version 2.0 mit einer umfassenden Modbus Implementierung ausgestattet. Durch die Interface- und Protokoll Virtualisierung wir der gleichzeitige Anschluss von hunderten Modbus Geräten an Dutzenden Bussen unterstützt.

Die Konfiguration erfolgt über eine von jedem Browser auf jedem Endgerät nutzbare Web-APP Benutzeroberfläche und ermöglicht eine besonders einfache und flexible Konfiguration der Leistungsmerkmale. Dabei ermöglicht insbesondere die grafische Webschnittstelle eine interaktive Konfiguration, so dass die Parametrisierung nicht „blind“ vorgenommen werden muss. Mehrere Assistenten erleichtern die Definition der Geräteeigenschaften.

Der Leistungsumfang ist enorm und es sind kaum Limitationen zu beachten. Die Daten der Modbus Geräte können in (fast) beliebig kurzen Intervallen abgefragt werden (soweit vom Gerät unterstützt). Zusätzlich lassen sich alle Werte auf Plausibilität prüfen, mit frei eingebbaren Formeln umrechnen und in andere Datentypen konvertieren. Dies erfolgt noch innerhalb der Modbus Subsysteme, so dass hierfür keine Logik angelegt werden muss, was eine erhebliche Vereinfachung bedeutet.

Die Modbus-Objekte können anschließend beliebig mit allen anderen Objekten jedes beliebigen Subsystems in n:m verknüpft und damit unter anderem auch dauerhaft aufgezeichnet werden. Damit stehen für Modbus auch alle anderen Leistungsmerkmale des Timberwolf Servers wie Langzeitaufzeichnung in Zeitreihen, umfangreiche grafische Auswertung und die fast beliebige Verknüpfung mit Logik, KNX, 1-Wire, anderen Modebus-Systemen und künftig auch MQTT usw. zur Verfügung.

Unterstütze Protokollvarianten:
  • Modbus RTU als Client
  • Modbus TCP als Client
mit diesen Parametern:
  • Pollintervall: ab 0,01 Sekunden (= 10 Millisekunden zwischen zwei Abfragen)
  • Unterstützte Modbus Functioncodes: 01 / 02 / 03 / 04 / 05 / 06 / 08 / 15 / 16 / 43
  • Unterstützte Registerbreiten: 1 / 16 / 32 / 48 / 64 / 96 / 128 / 256 Bit mit einer Abfrage
  • Dekodierung nach Bitmaske: Für Registerabfragen 16 / 32 / 48 / 64 Bit kann jede beliebige Bitmaske (1 - 64 Bit) angewendet werden
  • Konfigurierbare Byte-Reihenfolge: Litte Endian & Big Endian (acht Kombinationen für 16 Bit / 32 Bit / 64 Bit)
  • Dekodierbare Datentypen: Bool, Integer & Signed Integer (Einer- und Zweierkomplement von 2 - 64 Bit), Fließkomma 16 / 32 / 64 Bit, ASCII
  • Unterstützte Modbus Errorcodes: 0x81 / 0x82 / 0x83 / 0x84 / 0x85 / 0x86 / 0x88 / 0x8F / 0x90 /
  • Unterstützte Modbus Exceptioncodes: 01 / 02 / 03 / 04

MODBUS RTU vs. Modbus TCP

Das Modbus Protokoll steht für zwei Übertragungsmedien zur Verfügung: Über serielle RS-485 Bussysteme sowie über TCP/IP Netzwerke. Die Verwendung von Modbus über RS-485 Bussysteme wird als „Modbus RTU“ bezeichnet. Die Protokollvariante, welche über TCP/IP Netze kommuniziert, wird als „Modbus TCP“ bezeichnet.

Der Timberwolf Server unterstützt ab Firmware Version 2.0 beide Protokolle.


MODBUS RTU

Modbus RTU basiert elektrisch auf dem sehr robusten RS-485 Bussystem.

Die Modelle 950Q und 960Q verfügen über zwei RS-485 Schnittstellen, eine davon kann für Modbus RTU verwendet werden (die dann verbleibende RS-485 Schnittstelle kann weiterhin für DMX verwendet werden) und erlaubt den Anschluss von bis zu 248 Modbus RTU Geräte über eine Länge von 1200 Metern (bitte „Busload“ beachten).

Für ALLE Modelle des Timberwolf Servers steht eine Erweiterung als „Dual Isolated Modbus Extension“ zur Verfügung, die jeweils zwei Modbus RTU Kanäle hinzufügt. Beide Kanäle sind separat voneinander und unterstützen jeweils ebenfalls bis zu 248 Modbus RTU Geräte über eine Länge von 1200 Metern. Es können Dutzende dieser Extensions gleichzeitig am Timberwolf Server genutzt werden, womit ein umfassendes Netz aus tausenden Modbus Geräten mit dem Timberwolf Server verbunden werden kann. Diese Extension wird ab Firmware 2.0 des Timberwolf Servers erkannt, automatisch eingebunden und unterstützt. Fremde RS-485 Schnittstellen werden vom Timberwolf Server nicht erkannt und können nicht genutzt werden.

Hinweis: In der ursprünglichen Releaseplanung von 2018 war die Modbus Funktion für die Modelle 2100 und 2400 nicht vorgesehen. Diese damals geplanten Einschränkungen werden wir nicht vornehmen. Die Modbus Funktionalität wird für alle Modelle des Timberwolf Servers zur Verfügung gestellt.


Topologie in Modbus RTU

Modbus RTU basiert elektrisch auf dem RS-485 Bussystem. Der TIA/RS-485-A Standard spezifiziert streng lineare 2-Draht Verdrahtung – von Teilnehmer zu Teilnehmer – mit beidseitig terminierten Enden und einer dritten Ader für GND.

Stichleitungen vom Bus weg sollten vermieden werden und sind sehr kurz zu halten. Je nach Hersteller liegen die Angaben Für Modbus RTU Geräte bei 0,5 bis 4 m (in einem Fall sogar bei nur 10 cm). Die erlaubte Länge hängt von den verbauten Sender-Chips ab und deren Flankensteilheit sowie von der verwendeten Leitung. Da die genauen Parameter meistens nicht bekannt sind, empfehlen wir Abzweigungen auf eine Länge von maximal 1 m vom Bus weg zu begrenzen, kürzer ist besser. Für Sterninstallation können RS-485 Splitter verwendet werden (Beschreibung weiter unten)

Für die Verkabelung sollten Leitungen vom Typ S/STP, F/STP, S/FTP, F/FTP, SF/FTP, S/UTP, F/UTP, U/FTP, U/STP – nach Möglichkeit mit einem dritten Leiter für GND – verwendet werden. Für die Datenleitungen ist ein verdrilltes Adernpaar zu verwenden, für GND dann eine der verbleibenden Adern

Bei größeren Entfernungen und / oder bei vielen angeschlossenen Modbus RTU Geräten sowie zur Erzielung hoher Übertragungsraten sollte eine Leitung mit einem Wellenwiderstand von 120 Ohm verwendet werden. Größeres Augenmerk ist jedoch auf einwandfreie gasdichte Kontaktstellen, Vermeidung von Aderbruch durch Einkerben beim Abisolieren und darauf zu richten, dass die beiden Busenden mit jeweils einem Abschlusswiderstand (je 120 Ohm) terminiert sind.

Hinweis: Die RS-485 Schnittstellen im Timberwolf Server 950Q und 960Q sind bereits mit einem fixen 120 Ohm Widerstand ausgestattet. Diese Schnittstellen stellen daher ein Busende dar. Die optional erhältlichen „Dual Isolated Modbus Extensions“ verfügen über Dip-Schalter für die Terminierung, diese könnten damit auch an jeder Stelle im Bus angeschlossen werden.

Weitere Details zur Installation entnehmen Sie bitte der Artikelbeschreibung für die „Dual Isolated Modbus Extensions“ (sobald fertiggestellt).

Für jeden Modbus RTU Bus (eigentlich RS-485 Bus) ist jeweils das entsprechende Interface in der Modbus Schnittstellen Verwaltung mit einem (jeweils anzulegenden oder einem existierendem nicht belegtem) Modbus RTU Subsystem zu verbinden. An einem Modbus RTU Subsystem

Die RS-485 Schnittstellen der Timberwolf Servers bzw. die Schnittstellen der Modbus Extension unterstützen:
  • Leitungslänge: Maximal 1200 Meter (pro Kanal)
  • Baudrate: 1200 – 115.200 Baud
  • Datenbits: 8 Bit
  • Stopbits: 1 oder 2 Bit
  • Parität: Gerade, ungerade, keine
Hinweis: Auf ALLEN Geräte in einem Modbus RTU System müssen die selben Kommunikationsparameter eingerichtet werden


Hinweis zu RS-485 Buslasten

Modbus RTU Geräte werden über die Geräteadressen 1 bis 247 angesprochen. Diese sind individuell bei der Einrichtung eines jeden Modbus Gerätes zu vergeben. Die Anzahl der tatsächlich gleichzeitig an einem Bus elektrisch anschließbaren Modbus RTU Geräte wird von der Buslast bestimmt, die vom jeweiligen Gerät verursacht wird.

Grundsätzlich gilt: Ein Sender-Baustein in einem RS-485 System (und damit in einem jedem Modbus RTU Gerät) kann 32 Einheiten „Buslast“ treiben.

Das RS-485 Bussystem wurde 1983 von der Electronic Industrie Alliance ("EIA") entwickelt um die erheblichen Limitationen der seriellen RS-232 Schnittstelle zu überwinden. Jeder RS-485 Busteilnehmer verfügt üblicherweise über einen Sender und einen Empfänger. Zum damaligen Zeitpunkt wurde der Bus durch jeder Empfänger mit einer Stromaufnahme belastet, die als eine (1) Einheit „Buslast“ bezeichnet wurde. Jeder Sender im RS-485 Bus kann elektrisch 32 Stück solcher Buslasten treiben. Aus diesen technischen Vorgaben von vor 40 Jahren entstand die (veraltete) Vorgabe, dass ein RS-485 Bus auf 32 Teilnehmer limitiert ist.

Moderne Modbus RTU Geräte belasten den Bus nur noch mit einer Last von ¼ bis 1/10 Einheiten, so dass bis zu 320 gleichzeitig angeschlossene Geräte an einem Bussegment betrieben werden können. Da die jeweiligen Buslastern der Geräte nicht immer von den Herstellern in der Dokumentation veröffentlicht werden, empfehlen wir von ¼ Einheit auszugehen, womit sich eine Limitierung auf 128 gleichzeitig angeschlossene Geräte in der Praxis ergibt.

Hinweis: Die elektrisch maximal an RS-485 anschließbaren Systeme bitte nicht mit den maximal adressierbaren Modbus Geräten verwechseln. In Modbus wird die Geräteadresse mit einem (1) Byte kodiert, womit 256 Adressen möglich sind, von denen 248 Adressen (von 1 bis 247) genutzt werden dürfen. Die Adressen von 248 bis 255 sind durch die Modbus Organisation reserviert und dürfen nicht für normale Geräteadressen genutzt werden.


Hinweise zu Segmentierung und Reichweitenverlängerung mit Repeater

Ein RS-485 Bus kann mit Repeater elektrisch in mehrere Segmente getrennt werden. Damit kann die maximale Leitungslänge über 1200 Meter hinaus verlängert und der volle Adressraum von 248 Geräteadressen genutzt werden. ElabNET hat solche Repeater nicht getestet und kann daher keine Empfehlung abgeben.

Solche Repeater sind keine genormten Systemgeräte eines RS-485 Bussystems. Der Timberwolf Server und dessen RS-485 Schnittstellen wurde nicht mit den am Markt verfügbaren Repeatern getestet. Wir empfehlen derzeit, auf Repeater zu verzichten.


Hinweise zu Stern-Topologie mit RS-485 Splittern (Hubs)

Modbus RTU basiert elektrisch auf dem RS-485 Bussystem. Der TIA/RS-485-A Standard spezifiziert streng lineare 2-Draht Verdrahtung – von Teilnehmer zu Teilnehmer – mit beidseitig terminierten Enden und einer dritten Ader für GND.

RS-485 Splitter (auch als Hub bezeichnet) erlauben nach Angaben der Hersteller jedoch auch Stern-Installation. Die Kommunikation auf einem Bus (das Segment an dem sich der steuernde Client befindet) wird auf zwei oder mehrere (entsprechend der Auslegung des Splitters) RS-485 Busse kopiert. Antworten werden vermutlich an den „steuernden Bus“ zurück kopiert. Was hierbei passiert, falls Geräte auf mehreren Segmenten gleichzeitig antworten, bleibt unklar.

Alle an einen Splitter anschließbaren RS-485 Busse dürfte elektrisch jeweils als elektrisch eigenständige RS-485 Bussysteme ausgeführt sein, daher sind diese entsprechend zu terminieren. Beachten Sie die Betriebsanleitungen.

Solche Splitter sind keine genormten Systemgeräte eines RS-485 Bussystems. Der Timberwolf Server und dessen RS-485 Schnittstellen wurde mit den am Markt verfügbaren Splittern nicht getestet. Wir können für solche Konstellationen keinen Support leisten. Bitte beachten Sie, das DMX Splitter zwar ebenfalls auf RS-485 basieren, jedoch für eine unidirektionalen Kommunikationsrichtung ausgelegt sind.

Derzeit empfehlen wir die Nutzung solcher Splitter nicht. Wenn Sie mehrere Leitungsstränge in einem Schaltschrank anschließen wollen, empfehlen wir für eine übersichtliche Installation und einfache Diagnose die Verwendung der „Dual Isolated Modbus Extension“ von ElabNET mit der Kanalzahl, die der Anzahl der physikalischen Leitungsästen der Sternverkabelung entspricht, also einen separat betriebenen Bus pro Leitung.


Modbus TCP

Modbus TCP ist ein IP Protokoll und nutzt TCP/IP Netzwerke. Alle Modbus TCP Geräte werden über deren IP-Adresse angesprochen.

Der Timberwolf Server nutzt für Modbus TCP die Ethernet Schnittstelle zum lokalen Netzwerk. Sofern das lokale Netzwerk mit weiteren Netzen über Router, Datenleitungen und VPNs verbunden ist, können Modbus TCP Geräte weltweit angesprochen werden.

Für jedes Modbus TCP Gerät ist jeweils ein Interface in der Modbus Schnittstellen Verwaltung anzulegen und mit jeweils einem eigenen Subsystem zu verbinden.


MODBUS Client vs. Modbus Server

Ein Modbus Gerät muss entweder die Rolle als Client („Master“) oder als Server („Slave“) einnehmen. Die jeweils mögliche Anzahl in der jeweiligen ist je nach Protokollvariante und Gerätefähigkeiten begrenzt.

Modbus RTU: EIN Modbus RTU Gerät als Client der bis zu 248 Modbus RTU Geräte als Server an einem Bus ansprechen kann

Modbus TCP: EIN oder mehrere Modbus Geräte als Client können Modbus TCP Geräte per IP ansprechen. Es sind alle per IP erreichbaren Geräte adressierbar (4 Milliarden nur bei IPv4). Wie viele Clients auf jeweils einen Server zugreifen können ist im Standard nicht festgelegt, dies hängt von der Implementierung des Gerätes als Server ab.


Modbus als Client (“Master”)

Modbus ist ein Client-Server-Protokoll. Ein (oder bei TCP auch mehrere) Clients fragen Daten bei Modbus Servern ab oder senden Daten an diese. Die Kommunikation wird komplett vom Client gesteuert, die Server bearbeiten diese.

Der Timberwolf Server kann für Modbus RTU und Modbus TCP als steuernder Client konfiguriert werden. Mehrere Modbus Universen können unabhängig voneinander konfiguriert und parallel betrieben werden.


Modbus als Server (“Slave”)

Modbus ist als Client-Server-Protokoll implementiert. Ein (oder bei TCP auch mehrere) Clients fragen Daten bei Modbus Servern ab oder senden Daten an diese. Die Kommunikation wird komplett vom Client gesteuert, die Server bearbeiten diese.

Der Timberwolf Server kann für Modbus RTU und Modbus TCP als gesteuerter Server konfiguriert werden. Hierdurch ist eine weitgehende Emulation von Modbus Geräten möglich. Mehrere Modbus Universen – jeweils in der Rolle als Client oder als Server - können unabhängig voneinander konfiguriert und parallel betrieben werden.

Hinweis: Die Rolle als Server wird von der bisherigen Modbus Implementierung im Timberwolf Server in der Version 2.0 nicht unterstützt. Möglicherweise fügen wir diese Rolle später der Implementierung hinzu.


Video zur Einführung des Leistungsmerkmal Modbus

Für den Rollout des ersten Teiles der Modbus Leistungsmerkmale an die Entwickler wurde eine Live-Präsentation per Youtube durchgeführt. Es war unsere erste Live-Präsentation mit mehreren Kameras in unserem neuen Videostudio und es gibt noch das ein oder andere Verbesserungspotential.

Das Video dauert mehr als eineinhalb Stunden, ist jedoch voller Detailinformationen zu Modbus im Allgemeinen und zur Implementierung der Modbus Funktionen im Besonderen.

Für das beste Verständnis der neuen Funktionen empfehlen wir, dieses Video anzusehen. Die einzelnen Kapitel sind markiert und erlauben ein schnelles Anspringen der jeweiligen Abschnitte.

Kapitel:
0:00:00 Start & Vorstellung
0:01:26 Modbus Protokolle
0:02:36 Modbus Rollen (Client oder Server)
0:05:16 Modbus RTU Topologie
0:12:00 Modbus TCP Topologie
0:12:43 Adressierung Modbus RTU
0:13:06 Adressierung Modbus TCP
0:13:49 Adressierung Modbus Register
0:16:38 Zugriffsvarianten und Functioncodes
0:22:37 Modbus Datenformate
0:28:34 Interface Verwaltung im Timberwolf Server
0:38:59 Modbus Profile im Timberwolf Server
0:57:14 Format-Assistent für Modbus Profile
0:58:20 Wertprüfungsassistent für Modbus Profile
0:58:20 Wertprüfungsassistent für Modbus Profile
1:02:22 Fragen & Antworten

Hinweis: Wir wissen, dass dieses Video in mehrfacher Hinsicht nicht perfekt ist. Am Anfang läuft die Musik zu lang, ich habe zu oft auf den Monitor seitlich gesehen, oft war mein Konterfei im Weg. Werden wir beim nächsten Mal auch alles besser machen. Dennoch wollten wir Euch die Informationen darin nicht vorenthalten.




Verfügbarkeit

Wir stellen die Modbus Funktionen beginnend ab der Insider Preview 3 zur Version 2.0 zur Verfügung. Diese erscheint heute, am 17. Februar 2021.

Mit der IP3 haben wir den ersten Teil zur Verfügung gestellt, der die Schnittstellenverwaltung, den Busmonitor und die Profil-Verwaltung sowie die Erstellung der Profile umfasst. Zunächst werden die Modbus Protokolle Modbus RTU als Client (RTU „Master“) und Modbus TCP als Client (TCP „Master“) unterstützt. Der Timberwolf Server kann damit auf alle Modbus Server („Slaves“) über RS-485 und Ethernet zugreifen.

Ab der Insider Preview 4 (22. April 2021) haben wir auch den Modbus Geräte Manager zur Verfügung gestellt, in dem – basierend auf den Profilen – die Regeln für die Abfrage und / oder das Übertragen auf Modbus Geräte eingerichtet werden und dies mit dem Objektsystem des Timberwolf Servers verknüpft werden kann.


Für zeitnahe Informationen zur Bereitstellung neuer Versionen empfehlen wir Ihnen, unserem Telegram-Kanal für Insider beizutreten: https://t.me/joinchat/WTfK9VSIcPzLxfsl


Bei Rückfragen: Wir empfehlen die bereitgestellten Videos anzusehen, hier wird viel erklärt und gezeigt.


lg


Stefan
Zuletzt geändert von StefanW am Di Apr 27, 2021 9:08 am, insgesamt 7-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART der Elaborated Networks GmbH
Support nur über dieses Forum und in individuellen Fällen über support@elabnet.de.
Bitte KEINE PN Impressum und Datenschutzerklärung oben

danik
Reactions:
Beiträge: 299
Registriert: Mo Sep 10, 2018 8:40 pm
Hat sich bedankt: 146 Mal
Danksagung erhalten: 220 Mal

#2

Beitrag von danik »

Vielen dank, klingt spannend was da kommt und möglich wird. Da muss ich dann direkt auch mal schauen ob ich meine Alpha Innotec WP über Modus anbinden könnte, um so sukzessive weitere Software zu reduzieren. Ich hoffe die Funktionen bringen viele neue Kunden auf den TW.

Gruss
Dani
TW 950Q #321, VPN offen, Reboot nach Rücksprache

Ersteller
StefanW
Elaborated Networks
Reactions:
Beiträge: 5957
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Grafing
Hat sich bedankt: 2826 Mal
Danksagung erhalten: 4338 Mal
Kontaktdaten:

#3

Beitrag von StefanW »

Hallo Dani,
danik hat geschrieben: Mi Feb 17, 2021 8:35 pmVielen dank, klingt spannend was da kommt und möglich wird.
Der erste Teil wurde gestern veröffentlicht und ist ab sofort verfügbar. Der noch fehlende Modbus Geräte Manager geht diese oder nächste Woche zu den Dev-Testern und dürfte auch sehr schnell für die Insider verfügbar sein und dann kann man richtig Gas geben.

danik hat geschrieben: Mi Feb 17, 2021 8:35 pmDa muss ich dann direkt auch mal schauen ob ich meine Alpha Innotec WP über Modus anbinden könnte,
Hier ist, was ich im Netz gefunden habe. Es gibt eine Menge Daten, die man per Modbus mit der Alpha Innotec austauschen kann:

https://docplayer.org/20531057-Alpha-co ... itung.html

danik hat geschrieben: Mi Feb 17, 2021 8:35 pmum so sukzessive weitere Software zu reduzieren.
Ja, das ist ja die Zielrichtung für den Timberwolf Server, dass man möglichst viele Gewerke einfach integrieren kann.

danik hat geschrieben: Mi Feb 17, 2021 8:35 pmIch hoffe die Funktionen bringen viele neue Kunden auf den TW.
Ja, wir sind sehr zuversichtlich.

Es kommen auch in schneller Folge weitere Leistungsmerkmale mit anderen Protokollen. Wir haben letztes Jahr viel Zeit aufgewendet, die Architektur auszubauen und zu proofen. Es war doch nochmal ein großer Aufwand, das hierarchische Objektsystem dahingehend zu erweitern, dass ein Protokoll mehrfach parallel existieren kann und die Verbindung zum Interface eine virtuelle ist, also das gesamte Subsystem mit ein paar Klicks umgehängt werden kann auf ein anderes Interface. Man mag letzteres für selbstverständlich halten, tatsächlich was das aufwändig.

Das Ergebnis der Bemühungen kann man hier sehen:

2021-02-18_Subsystem Manager.png

Hier kann man gut das hierarchische Objektsystem erkennen und insbesondere, wie ausbaufähig das ist. Weitere Technologien, Bussysteme, Protokolle und Module lassen sich einfach anhängen, ohne bestehende Software ändern zu müssen. An den zentralen Komponenten ist hier gar nichts zu ändern, weil neue Technologien einfach nur andocken und sich im System anmelden.

Dadurch ist auch der Rollout des neuen Modbus Leistungsmerkmales - obwohl sehr umfangreich - kein kritisches Update, den es ändert sich nichts an den zentralen Komponenten. Es ist einfach nur ein neues Modul das an den Dispatcher andockt und mit dem Rest darüber kommuniziert. Es ist nichts an KNX, 1-Wire oder anderen Komponenten zu ändern.


lg

Stefan
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART der Elaborated Networks GmbH
Support nur über dieses Forum und in individuellen Fällen über support@elabnet.de.
Bitte KEINE PN Impressum und Datenschutzerklärung oben
Benutzeravatar

ztjuu
Reactions:
Beiträge: 44
Registriert: Sa Mär 07, 2020 8:49 am
Wohnort: Bleiberg-Nötsch (Kärnten)
Hat sich bedankt: 41 Mal
Danksagung erhalten: 38 Mal

#4

Beitrag von ztjuu »

Hallo Stefan

Perfekt, jetzt kann ich mit der NIBE WP, dem Fronius Symo Wechselrichter und mit den Küchengeräten (Miele) kommunizieren und die einzelnen APPS am Smartphone/Tablet werden weniger. Genau deshalb hab ich mir den Timberwolf gekauft, weil mann alles verheiraten kann. Bin bis jetzt sehr zufrieden Danke.
TWS 950Q ID:424 VPN: aktiviert Reboot: (OK)
EFH-Neubau: KNX, 1-Wire, DALI, VPN, CV & in Zukunft Multiroom Sound mit raspberry pi, Ekey-Zugang, ModBus TCP & RTU, MQTT

Ersteller
StefanW
Elaborated Networks
Reactions:
Beiträge: 5957
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Grafing
Hat sich bedankt: 2826 Mal
Danksagung erhalten: 4338 Mal
Kontaktdaten:

#5

Beitrag von StefanW »

Hi ztjuu,
ztjuu hat geschrieben: Do Feb 18, 2021 7:34 amPerfekt, jetzt kann ich mit der NIBE WP, dem Fronius Symo Wechselrichter und mit den Küchengeräten (Miele) kommunizieren
Echt, Miele geht auch? Hast Du da Infos dazu?

==> Bitte (das gilt für alle), mache für jedes Gerät einen Thread auf und veröffentliche bitte Infos zu Gerät, Datenblatt und das Modbus-Profil, damit andere das nutzen können. Dies dient uns dann auch zum Aufbau des zentralen Repositories!

ztjuu hat geschrieben: Do Feb 18, 2021 7:34 amund die einzelnen APPS am Smartphone/Tablet werden weniger.
Ja, die App-Pest gilt es zurückzudrängen. Das ist ein Irrweg.

ztjuu hat geschrieben: Do Feb 18, 2021 7:34 amGenau deshalb hab ich mir den Timberwolf gekauft, weil mann alles verheiraten kann. Bin bis jetzt sehr zufrieden Danke.
Danke, wir sind auch weiter dran, noch mehr Geräte und Technologien einfach anschließbar zu machen.


lg

Stefan
Zuletzt geändert von StefanW am Do Feb 18, 2021 7:41 am, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART der Elaborated Networks GmbH
Support nur über dieses Forum und in individuellen Fällen über support@elabnet.de.
Bitte KEINE PN Impressum und Datenschutzerklärung oben
Benutzeravatar

ztjuu
Reactions:
Beiträge: 44
Registriert: Sa Mär 07, 2020 8:49 am
Wohnort: Bleiberg-Nötsch (Kärnten)
Hat sich bedankt: 41 Mal
Danksagung erhalten: 38 Mal

#6

Beitrag von ztjuu »

StefanW hat geschrieben: Do Feb 18, 2021 7:41 am
Echt, Miele geht auch? Hast Du da Infos dazu?
Beim Kauf der Geräte wurde mir bestätigt das diese nicht nur WLAN fähig sind sondern auch auswertbar sein sollten. Im WLAN und auf der APP hab ich bis jetzt Dampfgarer, Backrohr, Geschirrspüler und Zeranfeld.

Sobald ich eine ModBus Registerliste habe werde ich die natürlich zur verfügung stellen.

Für die Nibe Wärmepumpe hab ich irgendwo auf meinem PC eine Registerliste.

lg
Jürgen
TWS 950Q ID:424 VPN: aktiviert Reboot: (OK)
EFH-Neubau: KNX, 1-Wire, DALI, VPN, CV & in Zukunft Multiroom Sound mit raspberry pi, Ekey-Zugang, ModBus TCP & RTU, MQTT

danik
Reactions:
Beiträge: 299
Registriert: Mo Sep 10, 2018 8:40 pm
Hat sich bedankt: 146 Mal
Danksagung erhalten: 220 Mal

#7

Beitrag von danik »

StefanW hat geschrieben: Do Feb 18, 2021 6:49 am Hier ist, was ich im Netz gefunden habe. Es gibt eine Menge Daten, die man per Modbus mit der Alpha Innotec austauschen kann:
Vielen dank Stefan, klingt spannend. Habe mich eben mit dem Heizungsmonteur ausgetauscht. Die Modbus Lizenz mit Installation wird wohl zwischen 350 - 700 CHF kosten, also alles andere als günstig. Mal schauen ob mir dies Wert ist (sehr wahrscheinlich aber eher nicht), zumal es auf anderem Weg die Möglichkeit gibt, die Daten ohne Kostenfolgen anzuzapfen (zurzeit habe ich dies über Edomi am laufen, geht wohl über Websocket). Ev. geht dies ja später mit der UDP-Anbindung.

Gruss
Dani
TW 950Q #321, VPN offen, Reboot nach Rücksprache

Sun1453
Reactions:
Beiträge: 1234
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 813 Mal
Danksagung erhalten: 493 Mal

#8

Beitrag von Sun1453 »

@danik Was das ist nur nen Stück Software und das lassen die sich mit Gold bezahlen. Einfach frech. Ich habe meine Heizung ja per KNX angebunden mit dem ISE Modul von Vaillant. Da hat man noch zwei Hardware Komponenten und das kostete damals 450 € aber okay das macht man einmal. Es gab aber auch keine andere Möglichkeit außer so nen komischen gefrikel mit Rasberry Pi. Da ich schon wollte das der EBUS der Heizung stabil weiter läuft und nicht durch den Abgriff gestört wird, habsch das Geld eben hingelegt.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache

Ersteller
StefanW
Elaborated Networks
Reactions:
Beiträge: 5957
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Grafing
Hat sich bedankt: 2826 Mal
Danksagung erhalten: 4338 Mal
Kontaktdaten:

#9

Beitrag von StefanW »

Hi Michael,
Sun1453 hat geschrieben: Sa Feb 20, 2021 11:00 amWas das ist nur nen Stück Software und das lassen die sich mit Gold bezahlen.
Entwicklung und Support von Software ist außerordentlich aufwändig. Bei eher geringen Stückzahl wirkt sich der theoretische Vorteil der günstigen Vervielfältigung nicht aus.

Nehmen wir an, die Lizenz für Modbus-Unterstützung in einer Heizungsanlage würde 500.- EUR kosten.

- Dann sind darin schon 80.- EUR Umsatzsteuer enthalten, die der Staat bekommt.

- Von den verbleibenden 420 EUR wird der Heizungsinstallateur zwischen 100 uns 180 EUR erhalten. Er muss dafür auch Fragen der Kunden beantworten, muss Anbebote erstellen und - im Falle seines Auftrages - den Einkaufs- und den Verkaufsprozess ausführen und die Buchhaltung dafür bezahlen.

- Der eigentliche Hersteller, wenn nicht noch ein Großhändler dazwischen geschaltet ist, bekommt irgendwas um 240.- EUR. Muss dafür aber auch die Fragen des Installateurs beantworten, womöglich noch ein Angebot schreiben, Datenblätter und Erklärungen vorhalten sowie in den folgenden Jahren Support leisten. Die Software musste dafür auch noch Entwickelt werden und womöglich in der Zukunft angepasst.

Wir haben hier noch nicht die Aufwände berücksichtigt, was den Verkauf über Landesgrenzen in der Verwaltung verursacht.

Ich denke, diese Preisgestaltung hat nichts mit "Gold" zu tun, sondern reflektiert den Aufwand den Hersteller und Installateur haben.

Man darf nicht übersehen, welchen Aufwand Erklärungen (Vertriebskosten) und Unterstützung (Supportkosten) verursachen. Ich schätze, dass der Betrieb dieses Forums und der darin geleistete Support kalkulatorisch einen hohen vierstelligen Betrag im Monat kostet.

Hardware selbst ist heute zutage nicht mehr der Kostenfaktor. Sondern deren Entwicklung, insbesondere der Software dafür und vor allem die Kosten, die immer umfangreicheren und komplexeren Leistungsmerkmale zu erklären (Pre-Sales-Beratung und Post-Sales-Support).


lg

Stefan
Zuletzt geändert von StefanW am So Feb 21, 2021 12:16 pm, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART der Elaborated Networks GmbH
Support nur über dieses Forum und in individuellen Fällen über support@elabnet.de.
Bitte KEINE PN Impressum und Datenschutzerklärung oben

DeLaDope
Reactions:
Beiträge: 223
Registriert: Mo Sep 03, 2018 2:26 pm
Hat sich bedankt: 113 Mal
Danksagung erhalten: 86 Mal

#10

Beitrag von DeLaDope »

Hi Stefan,

kann Deine Perspektive verstehen. Zumindest wenn man das SW Modul stand alone betrachtet.
Bei einer WP, habe auch eine von Siemens Novelan mit Luxtronic 2 Steuerung, welche über 10.000€ kostet (ist eigentlich ein besserer Kühlschrank) sollte das aber locker drin sein und zum "Stand der Technik" gehören. Man muss das immer im Kontext sehen. Wir reden hier ja nicht von einem reinen SW Produkt.

VG
TWS 2500 ID:134 + 2 x PBM ID:833/789, VPN offen, Reboot nach Rücksprache
Antworten

Zurück zu „Modbus“