Stimmt, da kann das Textfeld direkt vorher validieren. Gute Idee. Baue ich ein.
paresy
Nein. Nur die von den alten Instanzen:
Ergänzung:
Nur eine der beiden Geräteinstanzen wird nicht aktualisiert. Die andere schon. Sehr seltsam. Da wären Debuginformation schon hilfreich 
Ergänzung 2:
Jetzt geht es. Es war noch eine fehlerhafte Adresse aktiv:
(Das „Watt“ Thema)
Nun mit deaktivierter Adresse geht es.
Ergänzung 3:
Es wäre schön, wenn die Instanz auf Fehler ginge. Dann hätte ich es wohl sofort gesehen.
Ich habe gerade für mich die Importdatei zum schnellen Erfassen und Bearbeiten der Adressen entdeckt. Dabei sind mir jedoch drei Tippfehler unterlaufen, die etwas schwerer zu finden waren.
Die Punkte sind sicherlich nicht so relevant, da die Exportdatei ja eigentlich nicht zum Bearbeiten gedacht ist, aber vielleicht lässt sich da ja dennoch etwas machen
- Bei dem ersten Fehler konnte ich den Import erfolgreich durchführen, aber beim ApplyChanges kam es dann zur Fehlermeldung:
Bei der Suche nach dem Fehler kam es dann beim Aufruf von „Expertenoptionen“ bei dem fehlerhaften Element zu
Ursache war letztendlich ein falscher Eintrag in
"Translation": "[{\"Language\":\"de\",\"Name\":Zählerstand Batterieentladung, in Wh\"}]",
- beim zweiten Fehler kam es zur Meldung
Hier wäre es schöner, wenn in der Fehlermeldung nicht der deutsche Text, sondern der Name der Adresse stände.
- der dritte Fehler trat auf, nachdem alle Fehler korrigiert waren
hier war die Ursache, dass unter der Instanz eine Variable ohne Ident lag.
Dies ist übrigens die Datei mit den beiden Fehlern
modbus.json (8,8 KB)
Ich habe mal zum nächsten Update ein paar Kleinigkeiten optimiert:
- Im JSON waren die Translations als String kodiert. Das ist jetzt ordentlich als Array.
- Idents werden validiert
- Die Skript Editoren für virtuelle Adressen sind standardmäßig leer
paresy
Hallo,
ich habe gerade mal auf die 7.0 Testing auf meinen Testsystem hochgerüstet.
Ich habe 3 x Wago SPS über Modbus an IPS.
Jetzt ist mir folgendes aufgefallen.
Aus den Datentypen Word wird UINT.
In meinen Skripten spreche ich z. B. meine Rollos auf der Wago über ein Aktionskript wie folgt an
<?php
if(($_IPS['SENDER'] == "WebFront") or ($_IPS['SENDER'] == "SetValue"))
{// Befehle für Rollo AUF /AB/Stop
switch($IPS_VALUE)
{
case 1:
ModBus_WriteRegisterWord(19177, 1); //Rollo_Auf
break;
case 2:
ModBus_WriteRegisterWord(19177, 2); //Rollo_STOP
break;
case 3:
ModBus_WriteRegisterWord(19177, 3); //Rollo_Ab
break;
}
}
?>
Das wirft jetzt folgenden Error
Dann lasse ich das (Word) beim schalten auf die Modbus Instanz weg.
und zwar so.
<?php
if(($_IPS['SENDER'] == "WebFront") or ($_IPS['SENDER'] == "SetValue"))
{// Befehle für Rollo AUF /AB/Stop
switch($IPS_VALUE)
{
case 1:
ModBus_WriteRegister(41811, 1); //Rollo_Auf
break;
case 2:
ModBus_WriteRegister (41811, 2); //Rollo_STOP
break;
case 3:
ModBus_WriteRegister(41811, 3); //Rollo_Ab
break;
}
}
?>
Dann läuft es.
Blöd nur, ich habe ca. 80 Skripte mit
ModBus_WriteRegister Word
``
Muss ich die jetzt alle ändern???
Braucht man den Datentypen nicht mehr explizit ansprechen, bzw. mache ich das so überhaupt richtig?
Meine Instanz sieht so aus
Ich teste jetzt mal weiter, ob mir noch was auffällt.
Warum hast du überhaupt ein Aktions-Skript?
Die Variablen sollten doch auch so bedienbar sein.
Michael
Genau so. Das DWord kann aus dem Namen raus. Aber eigentlich sollte es Kompatibilität Funktionen geben. Ich prüfe das gleich.
paresy
Das habe ich so gemacht, weil ich mit dem Profil das Case Statement anspreche, wüsste nicht wie das anders geht.
Das mache ich ganz oft so, nicht nur bei Rollos.
Aber dein Case und dein gesendet Wert sind doch identisch 
Einfach mal mit der Standardaktion ausprobieren.
Michael
Das müsste ich tatsächlich mal testen, ich weiß was du meinst…
Diese Skripte sind aus 2019 (IPS Anfangszeit) Ich war damals glücklich, als es lief, machte mir da keine Gedanken mehr;)
Auf welchem OS läuft dein Symcon denn?
Aber ein Suchen + Ersetzen in allen Skripten von ModBus_WriteRegisterWord → ModBus_WriteRegister sollte dein Problem sehr schnell lösen.
Trotzdem hat Nall-Chan Recht, dass du das vermutlich gar nicht brauchst und die Aktionsskripte an der Variable einfach entfernen kannst.
paresy
Der Test läuft aktuell auf einem aktuellen Ubuntu Desktop in einer Proxmox VM…
Ansonsten bin ich beim Produktivsystem mit V6.4 auf einem Pi unterwegs.
Dann fallen also generell alle ModbusWritRegisterWord, Integer, Real ausser String weg, nur noch
ModbusWritRegister, ohne Datentyp???
Ja genau. Und noch einfacher ist, wenn du RequestAction direkt auf die Variable machst. Dann brauchst du eigentlich die ModBus_* Funktionen gar nicht mehr.
paresy
1 „Gefällt mir“
Aber NICHT in einem Aktions-Skript der Variable welche du versuchst mit RequestAction anzusteuern.
Dann hast du eine perfekte Endlosschleife!
Michael
1 „Gefällt mir“
Ich werde diesen Typ von Skript dann mit der Standard Aktion, wie oben erläutert betreiben.
Jedoch habe ich noch unzählige andere solcher Konstrukte wo ich z.B die Modbuswerte, von Heizung, Wallbox, Akku, PV Anlage zwischen Symcon und den SPS,n austausche, hier muss ich per Hand ran.
Hier kann ich nicht einfach die Standardaktion laufen lassen.
Ich hoffe es geht schnell mit Suchen + Ersetzen alles fix.
Falls es Probleme gibt, ich melde mich.
Danke Euch…
@goifalracer Im aktuellen Update sollten die Funktionen da sein (sie werfen zwar eine Deprecation Notice), aber Sie sollten komplett funktional sein.
paresy
Danke für den Hinweis.
Hab mittlerweile mit Suchen und alles Ersetzen auf die neue Syntax gewechselt.
Aber das mit dem Hinweis auf Deprecation finde ich gut.
Wie bekomme ich bei einer Anlage von einer virtuellen Adresse den Ident von einer anderen Adresse heraus ohne im Objektbaum nachzuschauen? Gibt es da eine Möglichkeit, per Tastenkürzel die Adressen auszuwählen?
Das ist tatsächlich aktuell der beste Weg. Wenn du das Objekt bearbeitest kannst du auch den Ident per Copy&Paste rausholen.
Zum nächsten Update gibt es noch einen Fix zum Little Endian Modus. Der war seit dem Umbau beim Schreiben komplett murks. Ich habe mich auch entschieden doch noch mal die Byte Order Geschichte anzufassen und größer umzubauen, sodass das ganze Thema komplett konsistent wird.
- Byte Order fliegt im Splitter komplett raus
- Im neuen ModBus Device kann man die ByteOrder auf Geräteebene setzen und pro Adresse noch überschreiben. Das sollte alle aktuell gewünschten Use-Cases abbilden.
- Zu den bisherigen Byte Order Einstellungen „Big Endian“ und „Little Endian (Byte Swap)“ fügen wir noch „Little Endian“ und „Big Endian (Byte Swap)“ hinzu. Das wird zwar sehr selten genutzt, aber ist dann vollständig.
- In den alten ModBus Adress Instanzen werden wir die im Splitter gesetzte ByteOrder in die jeweiligen Instanzen kopieren. Dies passiert einmalig beim ersten Start der nächsten 7.0.
- Die Eigenschaft „SwapWords“ belassen wir im Splitter noch, damit ggf. PHP-Module die darauf zugreifen nicht ins Leere fallen. Langfristig werden wir die Eigenschaft jedoch entfernen.
Zusätzlich konnte ich das Problem von @bumaas mit den Einzelinstanzen fixen.
paresy
4 „Gefällt mir“
Dann bitte sofort umbennen in ‚als Kompatibilität nur für php Module relevant‘. Sonst gibt das nur Verwirrung.