MDT Logikmodul: wie einfachen Zähler realisieren?

[hjk]

Das ist klar und richtig formuliert. Da ist auch kein Bug. Les dir das in Ruhe nochmal durch, auch vom Waldemar die Einträge bzw. Erklärungen.
Der Impuls sendet nur den Ausgang, nicht mehr und weiniger. Auf die Rechenfunktion hat das keinerei Einfluß. Den Rest findest du in den Erklärungen von Waldemar.
Die richtigen Einstellung standen schon in Post 16.

[mumpf]

Ihr versteht mich nicht :-)

Doch, aber es ist nicht so, wie Du es Dir vorstellst...

(es wird aber nicht neu gerechnet, das wird ausschließlich über den Impuls angestoßen*)

Ich denke, genau das ist das, was sich in Deinem Kopf festgesetzt hat (weil es Dir plausibel erscheint), was aber nirgendwo so steht und auch nicht passiert, ist also die Antwort auf Deine frühere Frage "Wo ist der Denkfehler".

Da steht nicht "Rechnen bei Impulseingang", da steht "Senden bei Impulseingang". Und nur das passiert: Wenn ein Impuls eingeht, wird der Ausgangswert gesendet. Das ist vollkommen unabhängig davon, ob der Ausgang schon mal diesen Wert gesendet hat oder nicht. Man könnte das somit auch dazu nutzen, den letzten berechneten Wert (der über "Senden bei Änderung" schon gesendet wurde) nochmal zu wiederholen (natürlich nicht bei Deinem Zählerbeispiel).

Gerechnet wird der Kanal ziemlich sicher nach jedem Telegrammeingang. Das Ergebnis wird ins KO geschrieben, dabei wird geschaut, ob man gar nicht, bei Änderung oder bei jedem Eingangstelegramm senden soll. Das wird gemacht. Der Wert steht dann ja noch im KO. Den kann man dann z.B. mit einem ReadRequest lesen. Oder eben per Impulseingang explizit senden lassen.

Gruß, Waldemar

[dreamy1]

Also ich befasse mich seit über 25 Jahren mit Digitaltechnik und Funktionspläne auch mit komplexen Logikbausteinen sind mein täglich Brot. Wenn ich eine "Blackbox" habe, die sich in dem Fall Addierer mit Impulseingang nennt, dann verstehe ich die Funktion so wie ich oben geschrieben habe (wenn Impuls dann zähle 1 zum am Eingang aktuell anstehenden Wert und gib die Summe am Ausgang aus. Danach Ruhe, bis der nächste Impuls kommt. Ob da jetzt eine Rückkopplung des Ausgangs auf den Eingang da ist, ist dabei völlig egal, es wird dann halt mit jedem neuen Impuls hochgezählt). Ohne Impuls darf das nicht selbständig loslaufen, macht es aber. Ohne eine Änderung am Ausgang darf es kein Telegramm geben, es kommen aber welche.

Das dies mit den o.g. geänderten Einstellungen nun funktioniert, freut mich natürlich. Ich habe ein grundsätzlich anderes Verständnis eines Addierers mit Impulseingang - das "Problem" ist, dass die Rechnung immer ausgeführt wird und nicht impulsgetriggert. Dann entsteht logischerweise die o.g. Schleife mit automatischem Hochzählen, da beim Start des Zählers der Initialwert 0 sofort um 1 erhöht wird und sich dann alles hochschaukelt.

[dreamy1]

Da steht nicht "Rechnen bei Impulseingang", da steht "Senden bei Impulseingang". Und nur das passiert: Wenn ein Impuls eingeht, wird der Ausgangswert gesendet. Das ist vollkommen unabhängig davon, ob der Ausgang schon mal diesen Wert gesendet hat oder nicht.

Hallo Waldemar,

sorry Du warst schneller, habe meinen Post oben erst eben losgeschickt.

Nochmals: es gab niemals einen Impuls, das hatte ich schon mehrfach geschrieben. Deswegen darf das nicht automatisch loslaufen, ich hätte eine andere Erklärung:

Ich bin mir ziemlich sicher, dass es an dem o.g. Initialwert 0 des Zähler-KOs liegt, der beim ersten Zyklus des LM durch die Rückkopplung sofort durch 1 ersetzt wird, beim nächsten Zyklus durch 2 usw...dann kommt natürlich die Telegrammflut, wenn das Ausgangs-KO bei Änderung sendet und die Rechnung immer aktiv ausgeführt wird. Das lässt sich nur unterbinden, wenn man das Senden auf "nicht automatisch" setzt. Dann wird wohl tatsächlich nur bei einem Impuls addiert und nicht dauernd.

Oder anders ausgedrückt: wenn die Rechnung immer ausgeführt wird, würde der Zähler doch immer sofort nach dem Start hochzählen, egal was der Impulseingang macht? Der Impulseingang würde dann ja nur immer den gerade aktuellen Zählwert als Telegramm absetzen und es durch das "Senden bei Änderung" zu einer Flut kommen.

EDIT: siehe Bild...wenn die Rechnung immer "scharf" ist und unabhängig vom Impuls, würde das Zähler-KO immer automatisch hochlaufen.

Der Impuls sendet nur den Ausgang, nicht mehr und weiniger. Auf die Rechenfunktion hat das keinerei Einfluß.

Das kann eigentlich nicht sein, siehe oben und Bild unten.

Screenshot 2023-08-17 174318.jpg

[mumpf]

Oder anders ausgedrückt: wenn die Rechnung immer ausgeführt wird, würde der Zähler doch immer sofort nach dem Start hochzählen, egal was der Impulseingang macht?

Genau! Es wird gerechnet, sobald sich ein EINGANGSWERT ändert. Der berechnete Wert steht dann im Ausgangs-KO. Ob er gesendet wird, bestimmen die Einstellungen für den Ausgang: Sendebedingung und Senden bei Impulseingang.

Der Impulseingang würde dann ja nur immer den gerade aktuellen Zählwert als Telegramm absetzen

Genau, der sendet einfach nur den Wert, der im Ausgangs-KO steht, auf den Bus.

und es durch das "Senden bei Änderung" zu einer Flut kommen.

Deswegen solltest Du ja "Senden bei Änderung" wegmachen. Weil es zu einer Flut kommt. Aber zu der Flut kommt es ja nur, weil Du eine Rückkopplung auf den Eingang eingebaut hast. Weil es Deine Anwendung Zähler erfordert. Die Funktion heißt aber auch "Universal-Rechner" und nicht "Zähler". Das Ding kann also auch noch andere Berechnungen durchführen. Und es kann sein, dass man das Ergebnis einer Rechnung unabhängig von irgendeinem Impuls haben will. Dann arbeitet man mit "Sendebedingung".

Beide Einstellungen "Sendebedingung" und "Senden bei Impulseingang" sind unabhängig voneinander und haben nichts miteinander zu tun. Vor allem hat "Senden bei Impulseingang" nichts mit dem Rechnen zu tun. Das musst Du verinnerlichen.

Das kann eigentlich nicht sein, siehe oben und Bild unten.

Diese Schlußfolgerung verstehe ich nicht, Du hast eigentlich alles korrekt hergeleitet...

Gruß, Waldemar

[mumpf]

Noch eine Anmerkung:

Wenn ich eine "Blackbox" habe, die sich in dem Fall Addierer mit Impulseingang nennt, dann verstehe ich die Funktion so wie ich oben geschrieben habe

Das ist leider nicht so. Die Funktion nennt sich "Universal-Rechner" und hat einen Parameter, der "Senden bei Impulseingang" heißt. Du hast aufgrund Deiner langjährigen Erfahrung mit komplexen Logiken im Kopf daraus einen "Addierer mit Impulseingang" gemacht und ein bestimmtes Verhalten unterstellt.

Es ist aber weder die erwartete Funktion noch das erwartete Verhalten. Ist einfach anders implementiert. Unter anderem, weil die Sachen in einem Telegrammbasierten System anders laufen...

Gruß, Waldemar

[dreamy1]

Hallo Waldemar,

vielen Dank für Deine Geduld :-)

Du hast Recht, bei mir hat sich einerseits Post #7 festgesetzt als auch meine Denkweise aufgrund des Berufs, da funktioniert ein "Baustein mit Impulseingang" völlig anders. Es sind halt keine statischen Signale wie im Bild - der Eingang "sieht" den Ausgang erst, wenn dieser durch die Sendebedingung: Änderung Ausgang" gesendet wurde und dann gibt es die Endlos-Schleife.

Leider gibt es ausgerechnet beim aktuell Logikmodul kein THB, wo man die Funktionsweise im Detail hätte nachlesen können - unter anderem auch, was für Initialwerte angenommen werden.

Da muss ich wirklich komplett umdenken und aufpassen, sonst lege ich mir nochmal den Bus lahm.

Danke nochmals

[jcd]

Blöde Frage falls ich auch mal so etwas fabriziere: Wie kommt man da wieder raus?

Verursachendes Gerät durch abklemmen identifizieren und dann… Werksreset?

[willisurf]

Normalerweise kann auch der Versuch klappen das Gerät einfach in der ETS umzuprogrammieren.
Der Befehl kommt durch und dann ist auch Ruhe.

[dreamy1]

So habe ich das gemacht, einfach schnell umprogrammiert...wobei schnell relativ ist, Puls bei 200 :-)

[mumpf]

Ja, bei Logiken teste ich auch immer erst im Gruppenmonitor oder einem kleinen Simulationsszenario, bevor ich die produktiv mache. Da sieht man schnell, wenn etwas schief läuft und kann schnell reagieren.

sonst lege ich mir nochmal den Bus lahm.

Der ist erstaunlich stabil, ich hatte mal eine (selbst verursachte) Bus-Überflutung (tagsüber) und es erst Abends bemerkt, als meine Frau sagte, dass an dem Tag alles irgendwie träger als sonst läuft - eben so was wie Licht geht erst nach 2-5 Sek an usw. Interessanterweise lief aber weiterhin alles!

Zur Denkweise: Ich hab es glaube ich inzwischen durchdrungen, alleine weil ich selber ja ein über die ETS parametrierbares Logikmodul programmiert habe und mich somit tief in ein telegrammbasiertes Processing "reindenken" musste. Gerade das von Dir angesprochene Startup-Verhalten und die Behandlung von Initialwerten hat bei meinem Logikmodul mehr als die Hälfte der Entwicklungszeit eingenommen - einfach weil ich das möglichst dezidiert beeinflussbar machen wollte.

Ich würde einfach mal das Startup-Verhalten vom Zähler-Kanal mal untersuchen, im Guppenmonitor, ohne Rückkopplung. Dann sieht man am ehesten, was da passiert.

Gruß, Waldemar

[dreamy1]

Der ist erstaunlich stabil

Das kann ich bestätigen - trotz der Schleife mit gefühlt 20 Telegrammen/s wurde auch der normale Busverkehr noch abgewickelt, sogar während der Neuprogrammierung des Logikmoduls. Das hat komischerweise nicht länger gedauert als sonst. Konnte das fast kaum glauben, zumal hier ja immer wieder der Ruf nach mehr Geschwindigkeit kommt.

Das Netzteil im Keller hat während der Zeit aber sicher geglüht

Ich würde einfach mal das Startup-Verhalten vom Zähler-Kanal mal untersuchen

Das habe ich indirekt schon - da der Zähler brav bei 0 beginnt, ist der Initialwert 0 - obwohl der eigentlich nie irgendwo festgelegt wurde. Bei 1bit-KOs ist das auch so - eigentlich ist deren Wert auch erst dann 0 und gültig, wenn das KO erstmalig auf dem Bus mit diesem Wert auftaucht.

Hatte mich bei der Sammelmeldung Fensterkontakte auch darüber gewundert, dass mir in der Visu bereits 0=geschlossen angezeigt wird, obwohl die Kontakte noch gar nicht alle zyklisch gesendet hatten. Irgendwo kann man einstellen, dass erst gesendet wird, dass alle Eingänge auch gültig sind (also das erste mal als KO auf dem Bus auftauchen) - hatte ich nicht angehakt, trotzdem war der Ausgang des LM=0, den die Visu abfragt und anzeigt (oder der VC Easy II belegt die 1bit-Status-KO's auch erstmal mit 0 vor).

[mumpf]

Verursachendes Gerät durch abklemmen identifizieren und dann… Werksreset?

Nein, zumindest nicht als erstes!
Das verusachende Gerät musst Du nicht durch abklemmen identifizieren, das siehst Du im Gruppenmonitor an der PA, die so viele Telegramme verschickt .

Falls klar ist, welcher Ausgang es ist und der Kanal beim Verursacher eine Sperre parametrisiert hat, würde ich per Gruppenmonitor eine Sperre setzen. Das wäre das einfachste, und dann die Applikation anpassen und neu programmieren.
Ohne Sperrmöglichkeit würde ich abklemmen und in der Applikation nach der kürzesten (von der Datenmenge her betrachtet, die an das Gerät gesendet werden muss) Änderung suchen, die das Problem behebt. Also falls es z.B. einen Parameter gibt, der den verursachenden Kanal deaktiviert, würde ich den setzen. Oder die GA vom Ausgang entfernen, der die Rückkopplung verursacht. Oder oder oder...
Und dann partiell programmieren! Schickt wesentlich weniger Daten als eine Vollprogrammierung. Und bei Parameteränderungen werden weniger Daten geschickt als bei GA-Änderungen.

Damit sollte man so eine Rückkopplungsschleife gut per Bus beheben können, hatte ich schon öfters bei meinen Tests, ist eigentlich keine große Sache...

Gruß, Waldemar

[jcd]

Danke für die Erklärungen, ich habe das Gefühl, das wird mir mal sehr helfen 😅

[dreamy1]

Falls klar ist, welcher Ausgang es ist und der Kanal beim Verursacher eine Sperre parametrisiert hat, würde ich per Gruppenmonitor eine Sperre setzen.

Das ist eine richtig gute Idee - muss ich mir merken, da eine Sperr-GA mit einzuplanen!