Telegrammverlust bei Beckhoff KL6301 und FOR-Schleifen

[sbzt]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich hatte jetzt schon in mehreren Projekten das Problem, dass ich auf einen Schwung eine große Menge an Telegrammen versenden muss (zentrale GA seitens der EIB-Geräte ist u.U. nicht immer möglich, es müssen teilweise auch unterschiedliche Werte übertragen werden).

Ich habe dafür die entsprechenden EIB_BIT_SEND (bzw. deren Äquivalente für andere Datenpunkttypen) in einer FOR-Schleife drin, die ja bei Änderung der zugwiesenen Eingangsvariable automatisch senden. Das klappt einwandfrei bis ca. 30, 40 Datenpunkte. Es scheint für die Grenze, bis zu der es funktioniert, auch unerheblich zu sein, ob es sich bespielsweise um Bit- oder Float-Werte handelt. Für jedes Telegramm gibt es mindestens einen Empfänger, es geht also nichts ins Leere, so dass auf jedes Telegramm auch ein "ACK" zurückkommt und die Klemme nichts mehrfach senden muss.

Die Zykluszeiten sind bereits relativ niedrig gehalten (10-20ms); der Funktionsblock für die Kommunikation mit der KL6301 läuft im selben Task wie das Programm, in dem die Schleifen aufgerufen werden, um Probleme bei der "Übergabe" auszuschließen. Ich tippe ja drauf, dass intern in der Klemme irgendein Puffer überläuft...

Hat jemand ähnliches feststellen können, ist das ein generelles Problem bei Beckhoff <-> EIB? Oder schickt jemand von euch erfolgreich eine größere Anzahl Telegramme? Welche Infos wären meinerseits noch wichtig?

Es tritt wie gesagt bei mehreren Projekten auf, sowohl in TC2, als auch in TC3...


Gruß Stephan

 

[MasterOhh]

Ich kenne mich mit EIB leider nicht sehr gut aus.
Aus meinen Erfahrungen mit serieller Kommunikation unter Beckhoff könnte ich mir schon vorstellen, dass du mit zu vielen Befehlen den Puffer überfüllst. IdR sollte die Kommunikation immer in einer sehr schnellen Task (<5ms) ausgeführt werden. Bedenke, dass der Puffer nur einmal pro Zyklus an die Klemme übertragen wird und deren Speicher ist begrenzt. Daher ist es im Normalfall besser die Daten in kleinen Happen dafür aber in kurzen Intervallen zu senden.

Dann könnte noch die Art und Weise der Datenbehandlung der Kommunikations-FBs eine Rolle Spielen. Viele FBs für EIB haben einen eingebauten SPAM-Schutz der verhindert, das du den Bus zumüllst. D.h. sie blockieren das versenden neuer Telegramme für einen festgelegten Intervall nachdem sie ausgeführt wurden. Rufst du die Bausteine innerhalb des Intervalls auf, speichern sie nur den Wert den du senden möchtest, führen den Befehl jedoch erst aus, wenn die Zeit abgelaufen ist. Werden sie mehrfach im gesperrten Zustand aufgerufen, wird nur der letzte Wert gesendet.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was genau machst Du mit der FOR-Schleife?

Harald

 

[sbzt]

Hallo Harald,

sorry für die späte Antwort - irgendwie kam keine Benachrichtigung mehr über eine neue Antwort, daher hab ich hier eine Weile nicht mehr reingeschaut.


Aktuelles Fallbeispiel: Heizungsregelung. Man muss jetzt dazu sagen, ich bin der zweite an der Anlage. Mit ein paar Vorüberlegungen (bzw. vielleicht einmal öfter mit dem Kunden zusammensetzen und besprechen, was denn am Schluss überhaupt rauskommen soll) hätte man das sicher sinnvoller in den Reglern selber lösen können, da ich aber wie gesagt nicht von Anfang an involviert war und zudem die "tollen" Gira Tastsensor 3 Komfort mit ETS-Plugin verbaut sind, wo jede Änderung eeewig dauert und Copy&Pasty quasi unmöglich ist, ist das Kind jetzt halt in den Brunnen gefallen und man muss es etwas "durch die Brust ins Auge" lösen. So viel zur Vorgeschichte.

Was ich also habe: KNX-Temperaturregler, die mir Ist- und Sollwerte liefern. Eine Anlage mit Fußbodenheizung, die über das selbe Leitungssystem im Sommer aber auch kühlen kann. Es handelt sich um ein Gebäude mit drei Stockwerken à max. 15 Räume, welche der Kollege als zweidimensionales Array angelegt hat. Damit man jetzt entsprechende Sollwert-Presets für Heizen und Kühlen abrufen kann, deren Werte persistent in der Beckhoff gespeichert sind, gibt es quasi ein Array "bySoll_Kuehl[floorNr,roomNr]" sowie ein Array "bySoll_Heiz[floorNr,roomNr]".

Wenn dann der entsprechende Befehl zur Umschaltung des Betriebsmodus kommt, schreibe ich eben wahlweise die Werte des einen oder anderen Arrays auf den Bus, damit die entsprechenden Sollwerte auch wieder in den Reglern hinterlegt sind. Da ich Bedenken hatte, dass es an der Flankenauswertung via R_TRIG liegt, habe ich testweise noch einen TOF nachgeschaltet, um das entsprechende Signal zu verlängern. In einem anderen Projekt hat das tatsächlich teilweise Abhilfe geschaffen, hier jedoch nicht. Ich habe das Ganze jetzt einfach aufgeteilt und sende Stockwerk 1 & 2 unmittelbar nacheinander und Stockwerk 3 mit ein paar Sekunden Abstand. Geht hier, weil das alles ja nicht zeitkritisch ist. Bei Schaltaktionen sieht das natürlich wieder anders aus, und schön ist auch was anderes...

Was man dazu sagen muss - auch das habe ich übernommen: Der FB "KL6301" für die Kommunikation läuft bei mir im Standard-Task, der eine verhältnismäßig hohe Zykluszeit hat (glaube 10 oder 20ms). Da gab es wohl irgendwie Probleme, dass Werte aus anderen Tasks nicht sauber übernommen bzw. dorthin übermittelt wurden, wenn das in einem eigenen Task war. Allerdings hatte der Kollege dann alles in einem eigenen Task, also auch Read/Send. Vielleicht sollte ich mal probieren, nur die Kommunikation in einen FastTask zu packen und alles andere in den Standard-Task, so gibt es Beckhoff ja z.B. für DALI auch vor und das scheint auch gut zu laufen. Ich seh schon, ich muss mich da etwas rantasten...


Edit: Ich habe mir jetzt grade nochmal die Doku zum entsprechenden Funktionsblock KL6301 angesehen.
https://infosys.beckhoff.com/englis...nt/1033/tcplclibeib/html/TcEIB_KL6301.htm&id=

Es gibt wohl einen Input "tTimeout", den wir nie beschaltet haben und der per Default auf 5s steht. Das geht sich glaube ich schon ganz gut hin. Die Send-Funktionsblöcke müssen ja warten, bis der Puffer frei ist, und wenn bis dahin die 5 Sekunden vergangen sind, wird der Rest natürlich verworfen. Das werde ich direkt mal ausprobieren.

 

[Heinileini]

Die Zykluszeiten sind bereits relativ niedrig gehalten (10-20ms);

... die Kommunikation läuft bei mir im Standard-Task, der eine verhältnismäßig hohe Zykluszeit hat (glaube 10 oder 20ms).

??? Relativ niedrig bezogen auf was? Verhältnismässig hoch bezogen auf was?

Was ich also habe: KNX-Temperaturregler, die mir Ist- und Sollwerte liefern.

... oder lieber ...

Wenn dann der entsprechende Befehl zur Umschaltung des Betriebsmodus kommt, schreibe ich eben wahlweise die Werte des einen oder anderen Arrays

auf den Bus, damit die entsprechenden Sollwerte auch wieder in den Reglern hinterlegt sind.

...??? Egal, Du wirst schon wissen, was Du gemeint hast.
​

... Geht hier, weil das alles ja nicht zeitkritisch ist. Bei Schaltaktionen sieht das natürlich wieder anders aus, und schön ist auch was anderes ...

Die Übertragung der SollWerte dürfte in der Tat nicht zeitkritisch sein, da nicht ständig zwischen den Sommer- und Winter-SollWerten, zwischen Kühlung und Heizung umgeschaltet werden muss.
Was sind 'SchaltAktionen'? Override der SollWerte aus den Arrays durch aktuelle Anforderungen aus den zu kühlenden/heizenden Räumen?
Oder aktuelle RückMeldungen der IstWerte?
Wenn man von 3 x 15 Räumen, Reglern u.s.w. ausgeht und von 100 ms Übertragung pro Raum, kommt man auf < 5 s, um alle Räume nacheinander abzufragen bzw. mit Daten zu versorgen. TotZeiten sind sicherlich 'unschön', aber 5 s zusätzlich in der TemperaturRegelung von Räumen kein wirkliches Problem?

 

[sbzt]

Zuviel Werbung?
-> Hier kostenlos registrieren

OK, auch wenn das eigentliche Problem heute tatsächlich gelöst werden konnte (komm ich gleich dazu), möchte ich das trotzdem kurz ein wenig entdröseln.

Gut, das mit langen/kurzen Zykluszeiten ist natürlich immer eine Frage dessen, was man in Relation setzt. Ich habe den Standardtask oft auch auf 50ms laufen, dann ist das natürlich im Vergleich dazu "kurz". Ich habe aber in anderen Projekten auch die Situation, dass ich aus mehreren Quellen simultan Multicast-Lichtsteuerdaten (sACN E1.31) verarbeiten muss. Da brauche ich dann Zykluszeiten <5ms, damit das sauber funktioniert. Im Verhältnis dazu ist es dann lang.

"Schaltaktion" bezieht sich auf einen normalen Ein-/Aus-Befehl. Beleuchtungsstromkreise. Hier habe ich bei unseren Anlagen in Theaterhäusern (der vorliegende Fall eines Geschäftsgebäudes bildet bei meinem Kundenkreis eher eine Ausnahme), die eben auch per DMX oder E1.31 geschaltet werden, "Echtzeitanforderungen". Da haut einer auf seinen Flash-Button auf dem Lichtstellpult, und es muss nach <100ms eine Reaktion da sein und halt nicht "irgendwann".

Bzgl. der Temperaturregler widersprechen sich meine Aussagen tatsächlich nicht. Die Mitarbeiter können die Temperatur natürlich vor Ort am Regler einstellen, die Änderung wird dann auch zur SPS gesendet, um sie dort zu visualisieren und auch in den betriebsmodus-abhängigen Speicher zu schreiben. Ebenso wird aber bei einer Änderung der Temperatur auf der Beckhoff-WebVisu logischerweise der Wert auch wieder an die Temperaturregler zurückgesendet, damit die lokal angezeigten Werte wieder stimmen.

Nachdem ich mal probehalber eine Schleife mit 100 Elementen erstellt habe und auf dem ETS Gruppenmonitor tatsächlich beobachten konnte, wie alles, was nach exakt fünf Sekunden noch nicht gesendet war, verworfen wurde, habe ich also mal besagten "tTimeout"-Eingang beschalten wollen.

Es kam prompt eine Fehlermeldung. Also den entsprechenden FB in der Lib angeschaut und siehe da, es gibt diesen Eingang nicht. Erst ein Update auf die aktuelle Lib, die im Übrigen immerhin "erst" vom 29.6. diesen Jahres ist (ich bin jetzt keiner, der jeden Tag guckt, ob es ein Update gibt, wenn die Entwicklungsumgebung ja soweit funktioniert), brachte ihn zum Vorschein. Dann alles nochmal mit 10s Timeout ausprobiert - et voilà.

Es gibt also noch gar nicht sooo lange eine Lösung des Problems, welches mir bereits vor über zweieinhalb Jahren das erste Mal Kopfzerbrechen bereitet hat. Laut Beckhoff-Support gab es eben genau in solchen Fällen Probleme, wo mittels Schrittketten oder FOR-Schleifen viele Werte gesendet werden mussten, und daher wurde die Option der manuellen Anpassung des Timeouts nachgerüstet. :icon_idea: