Aktueller Inhalt von WAGO Soluteer

Das kannst du machen; musst aber bedenken, dass bei der Benutzung von einem Baustein die Latenzzeiten größer werden, d.h. je mehr du Nachrichten über einen FB schickst, desto länger dauert es, bis die erste Quelle wieder gesendet wird. Das kannst du nur umgehen, indem du mehr Instanzen des FB...

Dann würde ich dir pro Nachrichtenquelle einen FbPublisher empfehlen. Ich dachte, es geht um "BYTE-Sparen" und nicht um die größte Performance... Noch eine andere Idee: Wenn ich die Beschreibung von openHAB richtig lese, kannst du auch Modbus TCP verwenden. Das wäre für deine Anforderung des...

Willst du das wegen des Clients (Handy, Tablet, ...) so häufig senden, damit das schnell bei Verbindung die aktuellen Werte bekommt?

Wenn ich deinen Code sehe, möchtest du die Werte immer senden. Ich war davon ausgegangenen, dass du die Nachrichten/Werte dynamisch senden willst... Soll die Steuerung ständig senden oder nur bei "Bedarf" (Wertänderung, 1x pro Minute o.Ä.)? Das ändert nämlich deinen Code.

Jep.(y)

Das steht ja schon in den vergangenen Posts und bringt den Kollegen hier nicht weiter.

Ich habe es befürchtet :confused: Zuerst einmal kannst du den Puffer nicht mit einer FOR-Schleife aufrufen, das ist Unsinn. Dann musst du dein Sendedaten ja irgendwie in den Puffer reinschreiben. Dazu ist dann "iPosition", welches den "Füllstand" des Puffers anzeigt. Also z.B. Rückmeldung Licht...

Ich würde eine Struktur bauen und die in ein Array schmeißen mit einem Zeiger auf das letzte Element. So kann man die Elemente nacheinander abarbeiten (der FB braucht zum Senden mehrere Zyklen!) STRUCT typMsg sTopic: STRING; sMessage: STRING; END_STRUCT STRUCT typBuffer iPosition: INT...

Das sollte freilich funktionieren. Du musst nur das Topic vor dem Senden mit "xTrigger" neu zusammenbauen. Schlussendlich wäre eine Art Auftragsliste denkbar, die über einen FbPublishMQTT_2 abgearbeitet wird.

Das kann e!C nicht. Du müsstest mit IF THEN vergleichen

Zur Zeit meldest du dich mit je einem Baustein an ein Topic an, also zum Beispiel an deinen Dimmwert 1. Da brauchst du das nicht auszuwerten, da es 1:1 auf deine für Dimmwert 1 verwendete Variable kopiert wird. Wenn du aber einen Subscribe-Baustein für das ganze Wohnzimmer nimmst und dich auf...

Versuche es mal ohne SysMemCpy Funktion und kopiere die Bytes um. Bitte folgende Variablen zusätzlich deklarieren: ptSource: POINTER TO BYTE; // Quellpointer ptDestination: POINTER TO BYTE; // Zielpointer i: DWORD; // Laufvariable Dann ersetzt du denen Code mit dem SysMemCpy durch folgendes...

Was passiert, wenn du den String mit dem Wert '0' statt '' löschst?

Genau das ist das Problem. Bitte den String vor dem Aufruf der SysMem.SysMemCpy() Funktion löschen! So wie ich es geschrieben habe. IF ...xReceived THEN sMessageLicht1DimValue:=''; SysMem.SysMemCpy(...); END_IF Zur Info: Ein STRING wird BYTE-technisch immer durch eine "0x0"...

Das scheint ein Kopierproblem mit unterschiedlichen Stringlängen zu sein. Lösche doch mal die Schreibvariable "sMessageDimmValue" vor dem MemCpy Aufruf. Also sMessageDimmValue:='';