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
- 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 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