UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[Frage] Roadmap Timberwolf - speziell zur Modbus Implementierung

Fragen, Antworten und Diskussionen über unseren Shop
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten

Ersteller
JustMe
Reactions:
Beiträge: 17
Registriert: Di Apr 28, 2020 11:33 pm
Wohnort: C:\Windows
Hat sich bedankt: 9 Mal
Danksagung erhalten: 2 Mal

Roadmap Timberwolf - speziell zur Modbus Implementierung

#1

Beitrag von JustMe »

Hallo zusammen,

in dem Shop ist unter den Merkmalen des Timberwolfs öfters die Rede von der Roadmap. Ich konnte diese allerdings nicht finden, gibt es dazu einen Link?

Besten Dank!
Zuletzt geändert von StefanW am So Jul 05, 2020 4:56 pm, insgesamt 1-mal geändert.
VG
Frank

TWS 960, ID502 ID840, VPN offen, Reboot jederzeit möglich

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#2

Beitrag von StefanW »

Hallo JustMe,

herzlich willkommen im Forum und danke für Deinen ersten Beitrag.

Die offizielle Roadmap wird derzeit noch intern abschließend beraten.

Fest steht bisher folgendes:

  1. Unterstützung Plug´n´Play für externe ElabNET RS-485 Extensions
  2. Unterstützung Modbus RTU als Master über interne (950 / 960) und externe RS-485 Schnittstelle
  3. Unterstützung Modbus RTU als Slave über interne (950 / 960) und externe RS-485 Schnittstelle
  4. Unterstützung Modbus TCP als Master über lokale Ethernet Schnittstelle
  5. Unterstützung Modbus TCP als Slave über lokale Ethernet Schnittstelle
  6. Unterstützung Plug´n´Play für externe ElabNET DMX Extensions
  7. Unterstützung DMX als Master über interne (950 / 960) und externe DMX Schnittstelle
  8. Unterstützung MQTT als Teilnehmer mit lokalem und / oder externen MQTT Broker über lokale Ethernet Schnittstelle
  9. Unterstützung Rest-API als Master über lokale Ethernet Schnittstelle
  10. Unterstützung Web-API als Master über lokale Ethernet Schnittstelle
  11. Unterstützung E-Autoladestationen über OCPP 2.0 als Master über lokale Ethernet Schnittstelle



Das ist die die ungefähre Reihenfolge, in der wir die Entwicklung anstarten. Da wir an mehreren Themen parallel arbeiten, kann die Reihenfolge in der ein Leistungsmerkmal erscheint, davon abweichen (weil das eine Team etwas schneller fertig hat, als das andere).

Es gibt noch ca. 15 weitere Leistungsmerkmale die sich in der langfristigen Planung befinden. Aber wir wollen nicht alles verraten (wegen den Marktbegleitern) und zudem brauchen wir auch noch etwas Luft um die Wünsche der Kunden zu erfüllen.

Prinzipiell wollen wir im Laufe der Zeit so ziemlich alles unterstützen, was technisch relevant ist und einen Nutzen für unsere Kunden hat. Aber eben nacheinander.

Ich hoffe das ist soweit zunächst ausreichend an Informationen für Dich.

lg

Stefan
Zuletzt geändert von StefanW am Sa Jul 04, 2020 8:30 am, insgesamt 2-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#3

Beitrag von gbglace »

Mich erfreuen die drei Buchstaben DMX so nach dem Modbus.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#4

Beitrag von StefanW »

gbglace hat geschrieben: Fr Jul 03, 2020 10:34 pmMich erfreuen die drei Buchstaben DMX so nach dem Modbus.
Jep, die Extensions für Modbus und DMX sind auch bereits in Produktionsvorbereitung, neben den BlitzARTs dafür (letztere warten gerade auf den CE Test im Hochspannungslabor). Die Hardware wird dann auch bereitstehen inkl. der CoProzessoren die für die hohe parallele Dimmleistung beim DMX verantwortlich sind.

==> Zunächst rollen wir nächste Woche die Bodenfeuchtesensoren, Bodenfeuchteaktoren und das Zubehör aus.

Mit letzterem mussten wir bis zum neuen Shop warten und die Artikel werden nun angelegt.

lg

Stefan
Zuletzt geändert von StefanW am Sa Jul 04, 2020 8:38 am, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ersteller
JustMe
Reactions:
Beiträge: 17
Registriert: Di Apr 28, 2020 11:33 pm
Wohnort: C:\Windows
Hat sich bedankt: 9 Mal
Danksagung erhalten: 2 Mal

#5

Beitrag von JustMe »

Hallo Stefan,

vielen Dank für die ausführlichen Antworten. Ich habe irendwo mal gelesen, dass ihr keine genauen Zeitpunkte mehr angebt um Kunden nicht zu enttäuschen, falls es doch zu Verzögerungen kommen sollte. Ich muss trotzdem fragen, ob es eine ungefähres Timing dazu gibt O:-) . Gerade was die Modbus Thematik angeht wäre ich tatsächlich zumindest auf eine grobe zeitliche Einschränkung angewiesen.. =)
VG
Frank

TWS 960, ID502 ID840, VPN offen, Reboot jederzeit möglich

eib-eg
Reactions:
Beiträge: 442
Registriert: Fr Sep 14, 2018 5:03 pm
Hat sich bedankt: 1457 Mal
Danksagung erhalten: 235 Mal

#6

Beitrag von eib-eg »

Hallo @JustMe
( Name leider unbekannt da deine Fußzeile nicht ausgefüllt, hierzu ein link viewtopic.php?f=8&t=331 )

Je mehr Ansporn ( also je mehr du bestellst und hier im Forum kund tust welche Menge ) um so schneller kann ich mir vorstellen das sie lieferbar werden.
Wir reden hier aber nicht von einem Stück 😉.

Ich meine jetzt mal Gans frech, wenn du jetzt 100-200 Stück hier im Forum schreibst das du bestellen willst und das schriftlich der Firma ElabNET einreichst, kann ich mir gut vorstellen das Stefan einen Termin sagen könnte.

Es soll jetzt nicht böse klingen, sondern ich bitte um Verständniss da du
Noch nicht so lange dabei bist ( angemeldet)
Erst zwei Beiträge geschrieben hast
Fußzeile nicht ausgefüllt

Ich mein ja nur
Viele stellen sich vor, schreiben was sie haben, und zum Schluss schreiben sie welches Teil für was benötigen und bitten um Hilfe.

Ich benötige auch das Teil, aber erst Mitte Dezember für meine Solaranlage und Batterien.

Sollte ich dich jetzt mit meiner Wortwahl erschreckt haben oder ein Missverständnis aufkommen, bitte ich vorab um Entschuldigung, oder eine private PN.

Ich bin gelegentlich sehr direkt.
TW 2600_99 seit 1.1.2018 / VPN zu

Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#7

Beitrag von Robert_Mini »

Hallo zusammen!

Ich denke die Frage nach der Roadmap war in Bezug auf die Ankündigung von Stefan durchaus berechtigt (welche auch auf eine etwas andere Strategie bez. Ankündigungen hinweist).
Meiner Meinung nach ist die Entwicklung nun auch wieder etwas planbarer geworden, da die Release stabil ist, Modbus sehr weit fertig gestellt und damit auch die Basis für weitere Systeme wie Web und Rest-API gelegt wurde.

@Georg: Ich kann deinem Posting nicht folgen (und will auch keine Diskussion dazu). Keiner muss 100e Stück bestellen um eine Antwort auf eine Roadmap zu bekommen. Gegebenenfalls gibt es eben keine Aussage zum Termin.

@JustMe: Willkommen hier im Forum - dein Vorname wäre tatsächlich hilfreich um dich anzusprechen (siehe Link von Georg oben).
Wenn du Zeit und Lust hast und häufiger hier aktiv sein möchtest, wäre eine kurze Vorstellung sehr nett, aber natürlich kein Muss.

lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

Sun1453
Reactions:
Beiträge: 1849
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 1541 Mal
Danksagung erhalten: 788 Mal

#8

Beitrag von Sun1453 »

Modbus kommt mit V 2.0 . Die erste IP sollte dazu nach Final der 1.6 kommen. Denke also in absehbarer zeit August so.
Zuletzt geändert von Sun1453 am Sa Jul 04, 2020 11:20 pm, insgesamt 1-mal geändert.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#9

Beitrag von StefanW »

Hi JustMe

(Angabe des Vornamens wäre nett, nicht zwingend aber fühlt sich besser an)
JustMe hat geschrieben: Sa Jul 04, 2020 8:28 pmvielen Dank für die ausführlichen Antworten. Ich habe irendwo mal gelesen, dass ihr keine genauen Zeitpunkte mehr angebt um Kunden nicht zu enttäuschen, falls es doch zu Verzögerungen kommen sollte.
Wir sind vorsichtig geworden, weil wir haben uns in der Anfangszeit der Timberwolf Entwicklung leider massiv im Realisierungsaufwand getäuscht.

Der Grund für die falsche Einschätzung war, dass wir zwar durchaus Vorstellungen hatten, welche grundlegenden Merkmale die Software erfüllen soll, aber zu einem großen Teil stand die nötige Technologie noch nicht zur Verfügung (kompakte & bezahlbare Prozessorleistung mit geringer Verlustleistung, kompakter Flash) bzw. war so brandneu, dass es keinen Entwickler gab, der sich damit bereits auskannte.

Wir mussten also insbesondere zu Anfang mehr Forschung- als Entwicklungsarbeit unternehmen, bis wir herausgearbeitet hatten, mit welchen Technologien die Architektur aufgebaut wird, wie man diese dann auch debugged und testet, wie man es dokumentiert und wie man es leistungsfähig, ressourceneffizient und vor allem auch skalierbar aufbaut.


Zudem war eine komplette grafische Oberfläche zu erstellen, die auch eine Administration erlaubt. Ein bisschen ist das wie Windows und Office. Das Windows selbst kann nicht viel, "nur" die Hardware und die grundlegenden Einstellungen verwalten. Aber seine Arbeit kann man nur mit Windows nicht erledigen. Dazu braucht es erst die Applikation wie Office, Browser und andere spezielle Programme für die Aufgaben, die wiederum das Windows als Basis brauchen.

Beim Timberwolf Server mussten wir die Grundlage für die grafische Oberfläche und vor allem auch für dies Live-Verbindung zur Overfläche zunächst entwickeln. Wir verwenden kein PHP das für jedes Update der Seite neu geladen werden muss (womit der Browser dann jedesmal "blinzelt"), sondern alle Ein- und Ausgaben werden im Browser berechnet und nur die reinen Daten mit dem Backend ausgetauscht. Das sieht sehr selbstverständlich und normal aus, aber tatsächlich ist das eine recht komplexes Client-Server-Modell im Browser mit einer Menge an Live Daten.

Zudem wollten wir, dass alle Engines im laufenden Betrieb neue Regeln, Logiken usw. akzeptieren ohne neu gestartet werden zu müssen. Alleine dieses einfache kleine Leistungsmerkmal, das man als selbstverständlich hinnimmt bedeutet den zehnfachen Aufwand, gegenüber der üblichen Technik, dass nach einer Rekonfiguration von Regeln und Einstellungen alles neu gestartet werden muss. Negativbeispiel hierfür ist der Homeserver. Wenn man da eine Änderung in der Logik vornimmt, muss diese erst übertragen werden und anschließend der Homeserver neu gestartet werden. Dieser Neustart dauert zwischen 5 und bis zu 40 Minuten, in denen der Server gar nicht zur Verfügung steht und wenn man sich dann vertan hat, dann beginnt das peil von vorne. Das ist tatsächlich Stand der Technik, der verkauft wird.

Bei unserer Logikengine ist das so, dass wenn man eine Logik ändert oder neu erstellt und auf Speichern drückt, dann ist diese Logik etwa 1/20 Sekunde später aktiv. Ohne dass andere Logiken davon betroffen sind. Da wird nix aufwändig "übertragen" und auch nicht neu gestartet.

Unsere Nutzer nehmen das als "normal" hin (und ist es auch für ein Produkt aus 2020) weil es ist auch so selbstverständlich für unseren Anspruch an Qualität und Benutzerführung. Tatsächlich ist eine solche Vorgabe aber alles andere als leicht umzusetzen. Eine solche Bedienweise mit "Änderungen-sofort aktivieren" haben wir praktisch im gesamten Produkt realisiert. Also neben der Logik auch in bei 1-Wire, bei allen Verknüpfungen zwischen den technologien, bei ekey und wir werden dies auch bei den neuen Protokollen wie Modus, DMX, MQTT usw. umsetzen. Wir haben uns da wirklich eine sehr feine Technik erarbeitet und nutzen das nun konsequent.

Dieser ganze Aufwand, dass wir zunächst viel mehr erforschen mussten als angenommen, dass die Programmierung der Architektur ("unser Windows") sehr Aufwändig war und dass wir uns so hohe Ansprüche an den Bedienungskomfort vorgenommen hatten, hat uns um die ursprünglich avisierten Termine gebracht. Dazu kommt, dass wir noch viele guten Ideen hatten, die wir unbedingt unterbringen wollten und dann kamen noch sehr viel Wünsche unserer Kunden dazu. In der Gesamtheit haben wir den Aufwand damals im Team heftig unterschätzt. Auf der anderen Seite sind wir sehr glücklich mit dem was daraus entstanden ist.

Aus der Erfahrung heraus sind wir einfach vorsichtig geworden mit frühzeitigen Angaben zu genauen Terminen. Wir meinen, es ist uns allen mehr gedient mit wirklich guter Qualität und Zuverlässigkeit, als zwar termingerecht aber hinsichtlich der Qualität verfrüht auszuliefern. Weil letzteres frisst dann viel Zeit im Support, frustriert und alle und ist nicht wirklich zielführend. Besser ein paar Monate etwas länger reifen zu lassen und ausgereift auszuliefern. Hat man auch als Kunde sehr viel mehr davon.

Ich bitte um Verständnis, dass wir zwar gerne eine Reihenfolge veröffentlichen, in der wir an neuen Leistungsmerkmalen arbeiten, aber genaue Zeitpunkte schwierig sind. Dafür gibt es aber eben auch die neue Roadmap Garantie, damit der Kunde zumindest sicher sein kann, dass er das Leistungsmerkmal, sollte es sich verspäten, auf jeden Fall ohne Kosten zur Verfügung gestellt bekommt, wenn es ausgerollt wird.


JustMe hat geschrieben: Sa Jul 04, 2020 8:28 pmIch muss trotzdem fragen, ob es eine ungefähres Timing dazu gibt O:-) . Gerade was die Modbus Thematik angeht wäre ich tatsächlich zumindest auf eine grobe zeitliche Einschränkung angewiesen.. =)
Klar, das ist auch eine legitime Frage. Schließlich verkaufen wir ein Produkt mit einem ziemlich heftigen Upgrade Versprechen und da wollen die Kunden das schon genauer wissen.

Da wir hinsichtlich der Modbus Implementierung auch schon sehr weit sind, kann ich dazu auch gerne Auskunft geben.


Die Modbus Implementierung besteht aus fünf großen (und ein paar kleinen) Modulen.

Modul "Modbus Schnittstellenverwaltung": Hier werden die Modbus Schnittstellen für "Modbus TCP" und "Modbus RTU" verwaltetet.

Denn - je nach Servermodell - werden wir eine größere Anzahl an Schnittstellen gleichzeitig unterstützen. Das ist ein starkes Alleinstellungsmerkmal, weil die meisten Server des Mitbewerbes, können, sofern sie überhaupt Modbus unterstützen, nur die eine eingebaute lokale Schnittstelle. Hat man zwei Busse, braucht man einen weiteren Server. Beim Timberwolf Server kann man fast beliebig viele externe Schnittstellen anstecken und diese nicht nur mit den internen Schnittstellen benutzen, man kann auch die darauf gebundenen Funktionen mit drei Klicks (von denen zwei nur der Sicherheit dienen) beliebig zwischen den Schnittstellen "umziehen", etwa wenn man einen Fehler in Bus / Schnittstelle sucht. Es gibt dann auch gute und klare Rückmeldungen zum Funktionsstatus und es ist komplett Plug´n´Play. Genau so einfach, wie wenn man an Windows eine neue Maus ansteckt und diese sofort funktioniert, geht das auch bei unseren Extensions. Bei allen übrigens ist das so einfach.

==> Dieses Modul ist weitestgehend fertig und funktioniert gut. Sowohl für Modbus RTU als auch für Modbus TCP und auch mit mehreren Interfaces.


Modul "Modbus Stack": Das ist der Kommunikationsstack für die eigentliche Modbus Kommunikation

Hiervon werden mehrere Instanzen gestartet, für jede konfigurierte Schnittstelle eine und hier wird der ganze Datenaustausch, das Protokollhandling, Timings usw. gesteuert.

==> Auch dieses Modul ist sehr weit fortgeschritten, läuft stabil und funktioniert recht gut. Es kann sein, dass wir hier noch das ein oder andere Tuning brauchen, aber das sehen wir dann erst bei den Test mit den "Insidern" in der Praxis.


Modul "Modbus Scheduler": Dies ist der zentrale Prozess, der die Aufträge sortiert uns vom Stack ausführen lässt

Das ist die zentrale Modbus Kontrolle im System. Hier werden aus dem vom Kunden eingestellten Regeln die jeweiligen Aufträge verwaltet, die dann vom Modbus Stack ausgeführt werden (jede Regel kann ein eigenes Intervall und ein eigenes Timing haben, das von allen anderen Regeln unabhängig ist, es sind also durchaus mehrere tausende individuelle und gleichzeitig nebeneinander existierende "Fahrpläne" für die verschiedenen Modbus Register möglich - mit jeweils individuellen Settings für Berechnungen, Weiterleitungsfiltern und Regeln).

==> Dieses Modul funktioniert im Prinzip bereits. Die ein oder andere Erweiterung wird mit dem Regeleditor noch kommen.


Modul "Modbus Applikationseditor": Dies ist der Editor, mit dem man die Fähigkeiten der Modbus Geräte als "Applikation" anlegt.

Ein sehr zentrales (und geniales) Konzept von KNX ist, dass es zwar 8000 kompatible Geräte gibt, aber diese mit nur EINER Software parametrisiert werden kann: Der ETS. Damit das fiunktioniert, stellen die Hersteller die jeweiligen Applikationen zum Download zur Verfügung, die man nun in die ETS einliest und mit der man dann das entsprechende KNX Gerät parametrisieren kann. Damit die Hersteller diese Applikation erstellen können, wird den Herstellern von der KNX Association gegen den Einwurf kleiner (und größerer) Münzen eine Software zur Verfügung gestellt, die als "Manufacturer Tool" bezeichnet wird.

Bei Modbus gibt es das leider nicht. Jeder Hersteller eines Modbus Gerätes gibt nur ein (mehr oder weniger schlechtes) Datenblatt heraus, indem die Parameter drin stehen, welche vom System unterstützt werden. Das muss dann jeder Nutzer in seinen jeweiligen Modbus Master implementieren. Das ist nicht gerade effizient.

Darum haben wir nun einen solchen Standard für den Austausch einer solchen Modbus-Spezifikation entwickelt und einen Editor dazu entwickelt, mit dem diese Spezifikation eingegeben werden kann. Diese kann geteilt werden, so dass das aufwändige Anlegen der Fähigkeiten der Modbus Geräte nur noch einmal vorgenommen werden muss. Gerade bei den Wechselrichtern sind durchaus hunderte von Parametern nutzbar und es ist ein Irrsinn, wenn das nun jeder Kunde individuell anlegen muss.

Daher machen wir das nun beim Timberwolf Server wie bei der ETS: Es gibt eine (vorinstallierten) Applikationseditor und damit legt der Nutzer die Applikation zunächst an. Der Clou ist: Diese Definition lässt sich teilen und das soll dafür sorgen, dass nur ein Nutzer es anlegen muss uns alle anderen können das nutzen. Das soll die Implementierung massiv vereinfachen und ganz erheblich Zeit und Aufwand verkürzen.

Der Editor unterstützt dabei einen Live-Check, d.h. man kann damit bereits beim Eintippen mit dem Device kommunizieren und die richtigen Einstellungen damit interaktiv austesten.

==> Auch dieses Modul funktioniert bereits und wird derzeit gefinished.


Modul "Modbus Geräte-Editor": Dies ist derjenige Editor, mit dem der Kunde die Regeln anlegt.

Wir oben bereits aufgezeigt, geben wir dem Nutzer maximale Freiheiten. Für jedes Register lassen sich beliebig viele und auch unterschiedliche Regeln hinsichtlich Intervall, Berechnungen, Filter und Weiterleitungen anlegen. Alles Live und sofort aktiv nach dem Speichern.

Hier ist der Stand, dass dieser Editor noch vor der Entwicklung steht, weil dieser die Funktion der anderen Module benötigt. Das ist also die noch fehlende und umzusetzende Komponente.


Wir sind also schon sehr weit und beginnen in einigen Wochen, die Modbus Software - abgesehen vom Regeleditor - auszurollen mit der Insider Preview 1 für die version 2.0. Damit kann man dann die Applikation definieren und komplett austesten. Während die Insider diesen Teil ausrollen, werden wir den noch fehlenden Modbus Geräteeditor ausrollen. Dieser orientiert sich an der Funktionalität des 1-Wire Editors und ich schätze, dass wir hier zwischen zwei und vier Monaten benötigen werden.

Kurz: Zum Ende des Sommers / Anfang Herbst sollte die Modbus Implementierung für Insider zur Verfügung stehen. Wie lange es dann dauert, bis diese Version dann als freigegebene Hauptversion zur Verfügung steht, wird davon abhängen, ob sich beim Test durch die Insider noch Probleme herausstellen oder nicht. Das kann man schlecht vorhersehen. Bei uns im Labor und einigen Testhäusern läuft das schon alles, aber es ist dann nochmal was anderes, wenn es bei hunderten Insidern mit bislang unbekannten Modbus Geräten laufen soll.


Ich hoffe die Angaben sind für Dich und Dein Projekt ausreichend

lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

Ersteller
JustMe
Reactions:
Beiträge: 17
Registriert: Di Apr 28, 2020 11:33 pm
Wohnort: C:\Windows
Hat sich bedankt: 9 Mal
Danksagung erhalten: 2 Mal

#10

Beitrag von JustMe »

Hallo Stefan,

die Angaben sind mehr als ausreichend für mich. Vielen Dank für deine sehr ausführliche Antwort und verzeih' bitte meine kurze ;)
VG
Frank

TWS 960, ID502 ID840, VPN offen, Reboot jederzeit möglich
Antworten

Zurück zu „ElabNET Shop“