[Frage] [V 3.5.1] Signed Int zum SMA WR schreiben & Profil ändern

[Saarlaender]

Servus Leute,

ich habe 2 Fragen

1.) Ich schreibe 0 aus der Logik (auch schon +1 sowie -1 versucht) und will das an den SMA WR senden. Das Register ist offenbar korrekt angelegt - genauso wie alle anderen UINT-Register auch. Die Modbus-Sendegruppe bringt beim Versuch 0 an den SINT zu senden nen Fehler "...keine erfolgreiche Konvertierung".

Was könnte da der Fehler sein?

Alle anderen Werte (unsigned Int) funktionieren wunderbar. der Signed Int ist genauso angelegt, einziger Unterschied. Zweier-Komplement.
Würde gern mal Einer-Komplement testen, weil ich hier eh nicht weiß was genau der Unterschied in meinem Fall sein wird. Aber da kommt die nächste Frage

2.) Wie kann ich mein Modbus-Profil ändern ohne dass ich ständig alles neu anlegen muss? So wie ich das sehe, muss ich zum Editieren ein Profil kopieren, kann dann Änderungen vornehmen und müsste dann aber das Gerät neu anlegen sowie alle abzufragenden / zu schreibenden Parameter neu anlegen. Das ist ja eine endlose Arbeit ... da hab ich bestimmt den richtigen Ablauf noch nicht entdeckt?!

[starwarsfan]

Hallo Daniel,

zu 2) kann ich Dir leider nur sagen, dass das genau so ist. Das ist extrem kontraproduktiv und wurde hier auch schon oft thematisiert. Technisch ist es wohl recht tricky, die entsprechenden Prüfungen erneut vorzunehmen und die Verknüpfungen in der DB zu ändern, wenn "vorn dran" das Profil gewechselt wird.

Die einzige Lösung oder besser ein Workaround für 1) ist demzufolge, ein komplett separates Profil zu machen, welches nur einige wenige Register enthält und damit dann herumzuspielen, bis diese Register und deren Abfragen korrekt funktionieren. Wenn dem so ist, kannst Du diese Einstellungen in das richtige Profil übernehmen.

Das hat mich auch schon viel Zeit und Nerven gekostet und es bleibt nur die Hoffnung, dass das irgendwann mal implementiert wird...

[Parsley]

Moin ihr beiden,

Danke für diesen Tipp von dir, Yves. Das klingt für mich wie ein derziges "best practise".

Zu 2): Ja, die Situation ist noch nicht perfekt und leider gibt es auch noch andere Stellen, an denen ebenfalls die Umsetzung von Komfortfunktionen zurückgestellt wurde. Diese Rückstellung wurde immer dann gemacht, wenn es grundsätzlich Workarounds an den jeweiligen Stellen gibt und parallel der Bedarf bestand Features zu bauen, die noch vollständig fehlten. Aktuelles Beispiel: Dem TWS fehlt eine Visu, um weitere Kunden erreichen zu können, aber Modbus ist grundsätzlich schon möglich. Also wird erstmal die Visu gebaut und der Komfort bei Modbus zurückgestellt. Mir selbst ist das bei den "Sendefiltern"-Eingangsfunktionen im MQTT aufgefallen, die vorgesehen, aber noch funktionslos sind. Dort ist der Workaround halt eine Logik nachzuschalten.
Elabnet hat all diese Punkte 100%ig auf dem Schirm, muss aber halt mit seinen Entwicklerkapazitäten haushalten.

[starwarsfan]

Hi

Diese Rückstellung wurde immer dann gemacht, wenn es grundsätzlich Workarounds an den jeweiligen Stellen gibt

Wobei das in dem Fall eigentlich kein Workaround ist. Ein Workaround stellt IMHO eine Funktionalität resp. ein Resultat her, mit welchem gearbeitet werden kann. Mit dieser Variante kann man sich jedoch lediglich langsam dahin hangeln, dass das Profil funktioniert. Aber bis das nicht abgeschlossen ist, kann man a) nicht wirklich produktiv damit arbeiten und b) das Profil auch nicht veröffentlichen. Habe ich nur zu gut beim SMA-Profil erfahren...

[Parsley]

Wobei das in dem Fall eigentlich kein Workaround ist.

Workarounds sind idR kein Zugewinn an Komfort. Aber an dieser Stelle ist es ganz besonders umständlich. Da gebe ich dir Recht.

[Saarlaender]

Danke für die Antworten.

Dann muss ich da mal rumprobieren. Insgesamt für mich schon sehr ärgerlich, aber ich kann verstehen dass die Visu Vorrang hat. Weniger verstehen kann ich, wie bei einer (für mich erstmal) so professionellen Umsetzung von Modbus im Rahmen der Entwicklung niemand daran gedacht hat dass man so ein Profil evt. auch mal ändern will.
"Fertig" gibts hier meine ich auch gar keine "schreibenden" Profile - aber genau das brauche ich um den Batterie-WR zu steuern.


Hat jemand von euch zu 1) eine Idee? Sprich wieso der SINT nicht korrekt funktioniert und was da ggf. helfen könnte?

Zu 2): Wie ist denn der schnellste Weg, ein neues Profil zu nutzen? Muss ich wirklich das Gerät auch immer neu anlegen?

[StefanW]

Daniel,

Weniger verstehen kann ich, wie bei einer (für mich erstmal) so professionellen Umsetzung von Modbus im Rahmen der Entwicklung niemand daran gedacht hat dass man so ein Profil evt. auch mal ändern will.

Fürs Protokoll: Man kann ein Profil sehr einfach ändern, indem man es bearbeitet (bzw. eine Kopie davon).

Eine komplexe, aktive Modbus-Konfiguration im laufenden Betrieb umstellen, ist, wegen der vielen Details, nicht einfach zu realisieren. Es ist eine große Herausforderung für Backend und Frontend, z.B. eine laufende Abfrage von "16 Bit, Unsigned Integer" auf "32 Bit, BigEndian, die mittleren 16 Bit, Float" umzustellen mit allen Berücksichtigungen der womöglich ein Dutzend verbundener Objekte dahinter. Wir schätzen, dass die Umsetzung einer solchen "Easy-Edit-Komfortfunktion" locker ein halbes Mannjahr kostet, also etwa 50.000 - 75.000 EUR und das war es uns damals nicht wert, weil es gibt auch viele andere Wünsche, die man für dieses Geld finanzieren könnte. Z.B HTTP-/REST-API (was danach kam).

==> Wir hatten uns mit den Kunden auf Fastrack geeinigt und das bedeutet, dass Komfortfunktionen hinten angestellt werden. Punkt.

Fürs Protokoll: Wir entwickeln agil und rollen auch so aus. Das bedeutet, dass Leistungsmerkmale auch dann ausgerollte werden, wenn noch nicht alles wünschenswerte implementiert ist. Punkt.

Weil man mit einer guten 85% Lösung bereits viel machen kann - hier den Modbus nutzen. Würde man jede Software erst dann ausrollen, wenn alles und jedes Detail daran zu 100 % ausimplementiert ist, dann wären die Kosten deutlich höher und die Wartezeit darauf länger. Wollen die Kunden aber auch nicht.

Ich frage mich schon, wie oft ich diese - übrigens mit der Mehrheit der Nutzer hier im Forum vereinbarte - agile Entwicklung, mit allen Vor- und Nachteilen, noch erklären muss?

Wenn ich das hier lese, dann frage ich mich schon, ob es ein Fehler ist, wenn wir die neue VISU nur mit den ersten Funktionen ausrollen (damit man diese bereits nutzen kann, während wir weitere Funktionen dazu entwickeln). Womöglich ist es doch besser, noch ein oder zwei Jahre daran zu arbeiten, damit wir dann sicher sind, dass NIEMAND mehr was dran auszusetzen hat, weil alles und jedes, an das man denken könnte, bereits implementiert ist?

Stefan

[gbglace]

Weniger verstehen kann ich, wie bei einer (für mich erstmal) so professionellen Umsetzung von Modbus im Rahmen der Entwicklung niemand daran gedacht hat dass man so ein Profil evt. auch mal ändern will.

Naja man nehme die Doku des Gerätes und arbeitet das komplett durch entweder mit Wegwerf Geräten zum Testen komplexer einzelner Register usw. aber am Ende baut man ein Profil mit einfach allen Objekten, warum sollte ich da nur die Hälfte umsetzen?

Ob man alles dann am Ende mit anderen TWS Objekten verbindet ist ja eine ganz andere Frage.

[Saarlaender]

Weniger verstehen kann ich, wie bei einer (für mich erstmal) so professionellen Umsetzung von Modbus im Rahmen der Entwicklung niemand daran gedacht hat dass man so ein Profil evt. auch mal ändern will.

Naja man nehme die Doku des Gerätes und arbeitet das komplett durch entweder mit Wegwerf Geräten zum Testen komplexer einzelner Register usw. aber am Ende baut man ein Profil mit einfach allen Objekten, warum sollte ich da nur die Hälfte umsetzen?

Ob man alles dann am Ende mit anderen TWS Objekten verbindet ist ja eine ganz andere Frage.

Soweit Zustimmung. Ich habe die Profile hier genommen und das hat funktioniert. Aber hier gibts nur Lese-Profile, nichts zum Steuern.
Dazu habe ich ein Profil angelegt und alles was ich brauche eingetippt.

Das Ändern ist für mich nur nötig, weil ich - mangels genauer Fehlermeldung und sonstigem Support - rumtesten muss, wieso mein SINT-Datentyp nicht funktioniert.
Wenn ich für dieses wild in der Gegend herumstochern ständig alles neu anlegen muss (und nicht einfach mit wenigen Klicks ein neues Profil nutzen kann), ist das extrem ärgerlich. Ganz besonders, wenn man wie ich nur sehr wenig Zeit für diese Spielereien hat und - auch durch die entspr. Kosten - davon ausging, man hat ein Produkt welches einem das Leben hier leichter macht

[Saarlaender]

Daniel,

Weniger verstehen kann ich, wie bei einer (für mich erstmal) so professionellen Umsetzung von Modbus im Rahmen der Entwicklung niemand daran gedacht hat dass man so ein Profil evt. auch mal ändern will.

Fürs Protokoll: Man kann ein Profil sehr einfach ändern, indem man es bearbeitet (bzw. eine Kopie davon).

Eine komplexe, aktive Modbus-Konfiguration im laufenden Betrieb umstellen, ist, wegen der vielen Details, nicht einfach zu realisieren. Es ist eine große Herausforderung für Backend und Frontend, z.B. eine laufende Abfrage von "16 Bit, Unsigned Integer" auf "32 Bit, BigEndian, die mittleren 16 Bit, Float" umzustellen mit allen Berücksichtigungen der womöglich ein Dutzend verbundener Objekte dahinter. Wir schätzen, dass die Umsetzung einer solchen "Easy-Edit-Komfortfunktion" locker ein halbes Mannjahr kostet, also etwa 50.000 - 75.000 EUR und das war es uns damals nicht wert, weil es gibt auch viele andere Wünsche, die man für dieses Geld finanzieren könnte. Z.B HTTP-/REST-API (was danach kam).

==> Wir hatten uns mit den Kunden auf Fastrack geeinigt und das bedeutet, dass Komfortfunktionen hinten angestellt werden. Punkt.

Fürs Protokoll: Wir entwickeln agil und rollen auch so aus. Das bedeutet, dass Leistungsmerkmale auch dann ausgerollte werden, wenn noch nicht alles wünschenswerte implementiert ist. Punkt.

Weil man mit einer guten 85% Lösung bereits viel machen kann - hier den Modbus nutzen. Würde man jede Software erst dann ausrollen, wenn alles und jedes Detail daran zu 100 % ausimplementiert ist, dann wären die Kosten deutlich höher und die Wartezeit darauf länger. Wollen die Kunden aber auch nicht.

Ich frage mich schon, wie oft ich diese - übrigens mit der Mehrheit der Nutzer hier im Forum vereinbarte - agile Entwicklung, mit allen Vor- und Nachteilen, noch erklären muss?

Wenn ich das hier lese, dann frage ich mich schon, ob es ein Fehler ist, wenn wir die neue VISU nur mit den ersten Funktionen ausrollen (damit man diese bereits nutzen kann, während wir weitere Funktionen dazu entwickeln). Womöglich ist es doch besser, noch ein oder zwei Jahre daran zu arbeiten, damit wir dann sicher sind, dass NIEMAND mehr was dran auszusetzen hat, weil alles und jedes, an das man denken könnte, bereits implementiert ist?

Stefan

Ich würde niemals sagen, dass man nur bei 100% ausrollen soll. Ich bin ein Freund von Funktionalitäten, die ständig erweitert werden.
Ich frage mich halt nur - und das hab ich auch so geschrieben - wie man bei der Entwicklung offenbar vergessen konnte, dass jemand ein Profil evt. auch mal ändern / erweitern will und aufgrund der Grundstruktur dieser Vorgang offenbar unmöglich oder extrem komplex wird.
Ich habe nicht gesagt, dass ich im laufenden Betrieb alles ändern will - aber wenn ich doch alles Pausieren / Stoppen kann (Gerät, Abfrage-Gruppe etc) ... dann sollte der Wechsel vom Profil doch einfach möglich sein?!

Wenn ichs aber richtig im Kopf hab, muss ich schon beim ersten Schritt (Anlegen Gerät mit IP etc) ein Profil auswählen ... hier sollte doch zunächst egal sein, welche Register verwendet werden sollen?!