Hallo Andi,
tger977 hat geschrieben: ↑Mo Okt 19, 2020 8:06 pmWas braucht man wirklich zwingend zusätzlich von dieser Liste und warum?
Am 23 September 1999 ging die Doppelsonde "Mars Climate Orbiter" durch Absturz auf dem Mars verloren, weil die Sonde zum Bremsen zu tief in die Mars Atmosphäre gesteuert wurde (57 km anstatt 150km). Der Grund war, dass zwei Wissenschaftlerteams zwar Zahlen austauschten, aber nicht die Einheiten und beide Teams mit unterschiedlichen Einheiten rechneten.
Damit sind wir beim warum. Praktisch alle IT-Systeme tauschen Daten als Zahlen oder Text aus. Beides können in jeweils Dutzenden verschiedenen Formaten binär codiert sein. Und bei Zahlen kommt die physikalische Einheit noch oben drauf.
Wenn man will, dass ich zwei System verstehen, dass muss man sich auch um die Kompatibilität kümmern.
Bei KNX ist alles geregelt
Wer KNX System kennt (oder 1-Wire in der Ausprägung von ElabNET) muss sich darüber nur selten Gedanken machen. Denn der Hersteller des KNX Gerätes hat das nicht nur in umfangreichen Handbüchern beschrieben, sondern alle Details in der Applikation für die ETS festgelegt. Diese Applikation enthält alle Details zu den Objekten, den Datenpunkttypen, den Flags und alle die Details zu Timing und Protokoll sind im KNX Standard festgelegt. Das ist bei all den Details die man mit der ETS noch festlegen muss, äußerst komfortabel.
Bei 1-Wire wird das Gerät sogar automatisch erkannt
Bei 1-Wire (zumindest in der Ausprägung von ElabNET) handhaben wir das genauso. Alle unsere 1-Wire Geräte haben eine Applikation mit allen Eigenschaften, die im Timberwolf Server hinterlegt ist.
Einfach nur Anstecken und das Gerät wird vom Plug´n´Play automatisch erkannt. Dann nur noch die gewünschten Daten auswählen und verknüpfen. Womöglich das Intervall noch anpassen, aber um mehr muss man sich nicht kümmern.
Bei Modbus muss mal alles einstellen. Wirklich ALLES
Bei Modbus gibt es nix. Keine Erkennung, keinen Automatismus, keine fertige Applikation*
Folgendes ist anzugeben:
- Den richtigen Protokolltyp (mir fallen da 8 Varianten ein)
- Baudrate / Stoppbits / Parität (bei RTU)
- IP-Adresse & Port (bei TCP)
- Device-Adresse (bei RTU bzw. TCP-to-RTU-Gateways)
- Registeradresse (und ob diese Dezimal oder in HEX angegeben ist)
- Die Angabe zum Base der Registeradressen (sind die Angaben zu Base=0 oder Base=1?)
- Anzahl der Register für den jeweiligen Wert
- Nutzbare Functioncodes für das jeweilige Register
- Endiness (Byte- &_ Wort und ggfls. Dword-Reihenfolge)
- Bei Signed Integer, die Angabe ob diese im Einerkomplement oder im Zweierkomplement gebildet sind
- Bei BCD, 8 Bit Integer sowie Text, wieviele Stellen pro Register verwendet werden und welche Bits
- Bei Text, in welchem der 34 möglichen Formate
- Bei BCD, ob das Ergebnis als String oder als Zahl zu formatieren ist
- Bei Zahlen, welche Werte zulässig sind
- Bei Ganzzahlen, ob es ein Festkommaformat ist
- Grundsätzlich, welche Werte, Wertepaare eine Fehlermeldung darstellen
- Welche der Register dazu dienen, das Gerät selbst einzustellen (hinsichtlich Baud, Stoppbits, Parity, Deviceadresse)
- Die Angabe, welche Zeit zwischen zwei Abfragen zu warten ist (manche Geräte kommen sonst nicht hinterher)
- Die Angabe, wieviele Register in einem Schwung abgefragt werden dürfen)
- Die Angabe, ob Setup-Register im volatilen RAM sind oder im Flash
- Hilfreich können Angaben zu Diagnose und Device Identification sein
- Hilfreich sind auch Angaben dazu, wo der Firmwarestand via Modbus ausgelesen werden kann, evt. auch eine Seriennummer
Das sind die wesentlichsten Parameter, welche der Timberwolf Server verarbeiten kann. Die meisten davon MUSS man eingeben, der Server kann es ja nicht raten. Und deshalb muss das am Ende auch auf dem Datenblatt stehen, weil sonst muss der Nutzer raten. Man kann zwar auch aus schlechten Datenblättern mit viel kombinatorischem Geschick und viel Wissen über Modbus einen versuch starten und der Timberwolf Server wird auch das "durchprobieren" maximal unterstützen, aber bei oft dutzenden bis tausenden Registern mancher Modbus Geräte wünsche ich mir für unsere Kunden mehr Klarheit von den Herstellern.
-----------------------------------------------------
*Zunächst. Mit dem Timberwolf Server haben wir ein Austauschformat für Modbus Applikationen entwickelt und wir erhoffen uns, dass dies weiterverwendet wird und dazu führt, dass es fertig nutzbare Modbus Applikationen gibt.
da ich da leider keine Ahnung von habe und ich auch keine Rückfragen beantworten könnte werde ich da erstmal keine Fragen im anderen Forum stellen.[/quote]
Da ein paar essentielle Angaben fehlen, fürchte ich, dass der ersten Anwender hier ein wenig herumprobieren muss.
lg
Stefan
