# Taster reagieren nicht oder sehr träge



## philipp75 (24 November 2021)

Liebe SPS Gurus,

seit ein paar wenigen Tagen scheint meine Wago Steuerung langsam auf Tastendrücke zu reagieren. Manchmal muss man 3-4 mal drücken bis das Licht an- bzw. ausgeht, manchmal scheint eine Taste zu hängen und der Dimmer spielt verrückt. 

Eine größere Änderung habe ich an der Wago nicht vorgenommen, nur an der Visu ein paar Kleinigkeiten ohne Logik auf der Steuerung.
Was können allgemeine Gründe dafür sein?


der PLC Browser sagt mir plc load = 0%
per SSH eingeloggt und "top" ausgeführt: irgendwas zwischen 1-50% CPU utilization


```
top - 20:54:35 up 481 days,  6:34,  1 user,  load average: 0,77, 1,07, 1,08
Tasks: 108 total,   1 running, 107 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1,9 us,  9,0 sy,  0,0 ni, 85,9 id,  0,0 wa,  0,0 hi,  3,2 si,  0,0 st
MiB Mem :  239,074 total,   73,656 free,  103,969 used,   61,449 buff/cache
MiB Swap:    0,000 total,    0,000 free,    0,000 used.  111,000 avail Mem
```

Steuerung: WAGO 750-8202 PFC200 CS 2ETH RS  / DMX Dimmer über AllNet (DMX4All)
Firmware Wago: 03.05.10(17)

Falls wichtig: Im Haus sind zwei weitere Wagos verbaut- eine für Gartenbewässerung und Beleuchtung und eine für den Ofen - beide sind über NetVars verbunden sind.


1000 Dank schoneinmal!
Phil


----------



## PN/DP (24 November 2021)

Wie groß ist die Zykluszeit bzw. Task-Zeit und ggf. die E/A-Aktualisierungszeit? Eine Taste muß mindestens so lange gedrückt werden, damit die SPS den Tastendruck sicher mitbekommt.

Harald


----------



## philipp75 (24 November 2021)

Hallo Harald,

vielen dank für Deine Antwort - anbei der Dump, ich hoffe das ist das gesuchte.


```
tsk

Number of Tasks: 3

Task 0: DefaultTask,  ID: 2
   Cycle count: 1218300136
   Cycletime:       25294 microseconds
   Cycletime (min): 21940 microseconds
   Cycletime (max): 212899820 microseconds
   Cycletime (avg): - microseconds
   Status: RUN
   Mode:   CONTINUE
   ----
   Priority:  31
   Intervall: 10 ms
   Event:     NONE
   ----
   Function pointer: 16#B5D99E34
   Function index:   663

Task 1: InputUpdateTask,  ID: 3
   Cycle count: 415831703
   Cycletime:       431 microseconds
   Cycletime (min): 369 microseconds
   Cycletime (max): 63113 microseconds
   Cycletime (avg): - microseconds
   Status: RUN
   Mode:   CONTINUE
   ----
   Priority:  31
   Intervall: 100 ms
   Event:     NONE
   ----
   Function pointer: 16#B5D00038
   Function index:   3

Task 2: KBus-Task,  ID: 999
   Cycle count: 0
   Cycletime:       2523 microseconds
   Cycletime (min): 0 microseconds
   Cycletime (max): 8154 microseconds
   Cycletime (avg): - microseconds
   Status: RUN
   Mode:   CONTINUE
   ----
   Priority:  0
   Intervall: 0 ms
   Event:     0000:0000:0000
   ----
   Function pointer: 16#00000000
   Function index:   0
```


----------



## Heinileini (24 November 2021)

PN/DP schrieb:


> Eine Taste muß mindestens so lange gedrückt werden, damit die SPS den Tastendruck sicher mitbekommt.


... und auch mindestens so lange nicht gedrückt werden, um mehrere aufeinander folgende Tastendrücke zu unterscheiden.

Aber was heisst ...


philipp75 schrieb:


> seit ein paar wenigen Tagen *scheint* meine Wago Steuerung *langsam* auf Tastendrücke *zu reagieren*. Manchmal muss man 3-4 mal drücken bis das Licht an- bzw. ausgeht, manchmal scheint eine Taste zu hängen und der Dimmer spielt verrückt.


Reagiert die Steuerung gar nicht auf zu kurze Tastendrücke bzw. zu kurze Pausen zwischen Tastendrücken oder reagiert sie zwar, jedoch erst "verspätet"?

Oder ist die ZyklusZeit evtl. so kurz (geworden), dass die Steuerung ein Prellen der Kontakte nicht gut genug "wegbügeln" kann?

Oder hast Du ein Problem mit dem BezugsPotenzial? Schlechte MasseVerbindungen oder sogar fehlende? Oder hohe AusgleichsStröme auf den MasseVerbindungen? Wenn das Problem so plötzlich aufgetreten ist, würde ich tatsächlich auf eine schlechte MasseVerbindung tippen. Vielleicht hat sich eine Klemme gelöst oder eine Strippe wurde versehentlich herausgerissen?


----------



## Passion4Automation (24 November 2021)

Ich würde auf zu kurze Taskintervalle oder ein höher priorisierter task macht dir die Abarbeitung deiner DI,s platt.
Du hast zwei Tasks mit gleicher Prio und die sind mit prio 31 von der Priorität her sehr niedrig.
Welcher Task verarbeitet bei dir die Logik die Probleme macht.?


----------



## philipp75 (24 November 2021)

Das Verhalten ist ehrlich gesagt nicht sonderlich deterministisch - würde sagen "mal so mal so". Manchmal reagieren die Taster gar nicht, mal normal, manchmal leicht verzögert. Auf gaaaanz kurze Tastendrücke reagiert sie nicht (bin mir aber auch nicht sicher ob sie das jemals getan hat)

Bei mir wurde vor kurzem eine Wallbox installiert - soll heissen der Elektriker war am Schaltschrank.... Aber das korreliert zeitlich nicht miteinander  - die Störungen traten also erst 2-3 Tage später auf.


----------



## philipp75 (24 November 2021)

@goifalracer: das ist Task0 - der hat die Taster Logik.


----------



## philipp75 (24 November 2021)

hm - in der Taskkonfiguration sehe ich aber nur einen Haupttask:


----------



## Passion4Automation (24 November 2021)

Teste es einfach mal aus und stelle den task auf das 2,5 fache der maximal gemessenen Zykluszeit.


----------



## Oberchefe (24 November 2021)

> Cycletime (max): 212899820 microseconds



Wären 212 Sekunden...


----------



## Passion4Automation (24 November 2021)

Man sollte dann Zähler für die Taskzeit nach dem Laden des Bootprojekts zurücksetzen und dann die Sps das Programm mal abarbeiten lassen, dann wird die Zeit bei guter Programmierung wesentlich niedriger und ohne riesen Schwankungen sein. Dan  klappt auch das mit den 2,5 Faktor recht gut.


----------



## philipp75 (24 November 2021)

Ich habe nun mal das Programm gestoppt und wieder gestartet

Jetzt sieht das so aus:

```
tsk
Number of Tasks: 3
Task 0: DefaultTask,  ID: 2
   Cycle count: 1379
   Cycletime:       24033 microseconds
   Cycletime (min): 22525 microseconds
   Cycletime (max): 246880 microseconds
   Cycletime (avg): 36891 microseconds
   Status: RUN
   Mode:   CONTINUE
   ----
   Priority:  31
   Intervall: 10 ms
   Event:     NONE
   ----
   Function pointer: 16#B5D8B480
   Function index:   663
```


Nach einer Minute und ein paar mal "tsk":

```
tsk
Number of Tasks: 3
Task 0: DefaultTask,  ID: 2
   Cycle count: 5534
   Cycletime:       27510 microseconds
   Cycletime (min): 22401 microseconds
   Cycletime (max): 379967 microseconds
   Cycletime (avg): 36863 microseconds
   Status: RUN
   Mode:   CONTINUE
   ----
   Priority:  31
   Intervall: 10 ms
   Event:     NONE
   ----
   Function pointer: 16#B5D8B480
   Function index:   663
```


----------



## Passion4Automation (24 November 2021)

philipp75 schrieb:


> Das Verhalten ist ehrlich gesagt nicht sonderlich deterministisch - würde sagen "mal so mal so". Manchmal reagieren die Taster gar nicht, mal normal, manchmal leicht verzögert. Auf gaaaanz kurze Tastendrücke reagiert sie nicht (bin mir aber auch nicht sicher ob sie das jemals getan hat)
> 
> Bei mir wurde vor kurzem eine Wallbox installiert - soll heissen der Elektriker war am Schaltschrank.... Aber das korreliert zeitlich nicht miteinander  - die Störungen traten also erst 2-3 Tage später auf.


Es kann nicht deterministisch sein weil die 10ms von Task 0 mal eine Flanke des Tasters mit verarbeiten und mal nicht. 
Evtl. hast du zwei Probleme, 1x Tasksystem 1x Masseproblem


----------



## Passion4Automation (24 November 2021)

philipp75 schrieb:


> Ich habe nun mal das Programm gestoppt und wieder gestartet
> 
> Jetzt sieht das so aus:
> 
> ...


----------



## Passion4Automation (24 November 2021)

Deine Taskzeit ist ziemlich lange, das Programm kann nur in Scheibchen abgearbeitet werden. Wenn du die Taskeit auf 300ms hochstellst wird dein Programm anders reagieren, evtl. müssen die Doppelklicks sehr langsam ausgeführt werden. 
Aber trotzdem brauchen da Programmteile viel Zeit.
Kannst du einzelne PRGs mal aus dem Programmdurchlauf rausnehmen? Somit könntest du sehen wie die Zeit sich verändert.


----------



## philipp75 (24 November 2021)

Macht es Sinn das Hauptprogramm in eine andere Task mit anderer Priorität auszulagern?


----------



## Heinileini (24 November 2021)

```
Cycletime (max): 246880 microseconds
nach einer Minute und ein paar mal "tsk":
Cycletime (max): 379967 microseconds
```
Tendenz steigend also. Knappe 400 ms Zykluszeit und erst recht Schwankungen 25..400 ms können einen Bediener (der Tasten) durchaus irre machen und die Reaktion eines Dimmers auch.


----------



## Oberchefe (24 November 2021)

Die Frage wäre, was hast du angestellt, um mit dem PFC 200 aus solche Zeiten zu kommen


----------



## Passion4Automation (24 November 2021)

Oberchefe schrieb:


> Die Frage wäre, was hast du angestellt, um mit dem PFC 200 aus solche Zeiten zu kommen


Ich habe die gleiche CPU im Häuschen und habe eine Zeit, avg im Haupttask von 8ms.


----------



## Oberchefe (24 November 2021)

Ein Soll von 10ms macht keinen Sinn wenn du Minimum 22ms brauchst. Da würde ich erst mal auf 30ms hoch gehen und dann schauen, was die Werte machen.


----------



## Oberchefe (24 November 2021)

Screenshot von den Tasks bitte.


----------



## Passion4Automation (24 November 2021)

Stell mal die Priorität statt 31 auf 6 und schau was passiert.
Alles über prio 15 ist für unwichtige Aufgaben vorgesehen. Aber nicht unter prio 5 einstellen.


----------



## philipp75 (24 November 2021)

da ist vom Vorbesitzer nach meinem Empfinden schon einiges an Logik eingebaut worden. Fussbodenheizung, Dimmer, Alarmanlage, Heizung, Bewegungsmelder, u.v.m. -

Das einzige was ich mal eingebaut habe - und das kann durchaus eine Ursache sein - eine Abfrage meiner Luftwärmepumpe über Sockets. Aber die sind "unblocking" programmiert (zumindest nach Anleitung, ob das in der Realität auch so funktioniert .....)


----------



## philipp75 (24 November 2021)

die Priorität des Standard Tasks kann ich gar nicht ändern (siehe Bild oben) - da ist kein Task gepflegt, nur der Default.
Den KBus-Task und den InputOutput Task sehe ich da nicht.


----------



## PN/DP (24 November 2021)

Ich kenne mich mit Wago nicht aus, doch mir kommt die Cycletime (max) von 246 ms bzw fast 380 ms verdächtig vor. Wie kann es zu so hohen Zykluszeiten kommen? Sehr viele Unterbrechungen durch höherpriore Tasks? Kommunikation? Hat die Wago einen Webserver? Oder Schleifen im Programm? Oder andere ungeeignete Programmierung? In industriellen Steuerungen (z.B. Siemens S7) wird die Zyklusüberwachungszeit typischerweise auf 150 ms eingestellt, weil bei höheren Zykluszeiten ist die Reaktionszeit auf Taster oder Sensoren/Lichtschranken einfach nicht mehr hinnehmbar, da wird die Reaktion der Anlagen unberechenbar, und dann soll die Steuerung besser in STOP gehen anstatt Lichtschranken oder Endschalter zu überfahren oder nur auf sehr langes Stop-Taster-drücken zu reagieren.

(PS: zu langsam getippselt...)

Harald


----------



## Passion4Automation (24 November 2021)

Welche Art von task ist das? Wenn der als zyklischer Task angelegt ist, muss man die prio ändern können.


----------



## philipp75 (24 November 2021)

habe gerade mal hier im Forum gesucht und eine Antwort eines WAGO Mitarbeiters gelesen:

--
wenn Sie in Codesys ein neues Projekt erstellen und in diesem ein PLC_PRG Programm anlegen, wird dieses automatisch in einer freilaufenden Taks aufgerufen. Wenn Sie jedoch ein Programm mit einem anderem Namen anlegen ist dieses nicht mehr gewährleistet und wird nicht mehr in einer freilaufenden Task abgearbeitet.
--

genauso heisst mein Hauptprogramm.


----------



## Passion4Automation (24 November 2021)

Also ein zyklischer Task wäre am besten.
Einfach den Task löschen, einen neuen anlegen und das PRG auswählen, welches der Task aufrufen soll.

Ich habe mal bei mir nachgeschaut in ein Paar Bilder angehängt.
Also wenn du im PLC Browser schaust habe ich eine maximale Zeit von 150ms, das ist aber nicht ausschlaggebend, weil das wirlich die maximale ist und die beim Start und beim Bootprojekt laden geeneriert wird.
Ich arbeite mit der grafischen Variante, ich glaube du muss die (SysLibTaskInfo) laden damit das bei dir funktioniert.
Hier kannst du die Zeiten zurücksetzen und kannst beobachten was deine Zykluszeit macht. Also im laufenden Programm wieder alle gespeicherten Zeiten rücksetzen, dass ist gut.

Ich denke wen du deine Zykluszeit auf 50 ms einstellst kannst du mal weiter sehen.


----------



## PN/DP (24 November 2021)

goifalracer schrieb:


> Also ein zyklischer Task wäre am besten.


Wenn das Programm in der freilaufenden Task zu lange dauert, dann wird es als zyklische Task auch nicht schneller sondern langsamer. Die zyklische Task darf ja nicht schneller aufgerufen werden als die längste Bearbeitungszeit dauert.Oder wie soll das funktionieren?

Harald


----------



## philipp75 (24 November 2021)

ich habe das mal versucht und das PRG_PLC in eine definierte Task umgelagert, dann kommt der Fehler 4601
"Fehler 4601: Netzwerkvariablen 'UDP': Es ist keine zyklische oder freilaufende Task zum Netzwerkvariablenaustausch vorhanden."

Die NetVars werden natürlich auch in dem Hauptprogramm verarbeitet.


Vermutlich macht es Sinn, das große Programm zu zerteilen und ein paar weniger relevante Themen auszulagern (Emailversand bei Störungen, die beiden Socket Programme für den Wetterdienst und die Luft-WärmePumpe - das alles sind ja keine zeitkritischen Bestandteile.


----------



## Passion4Automation (24 November 2021)

PN/DP schrieb:


> Wenn das Programm in der freilaufenden Task zu lange dauert, dann wird es als zyklische Task auch nicht schneller. Oder wie soll das funktionieren?
> 
> Harald


Weil man die zyklische Task bei Wago besser anpassen kann, als die automatsich erstellte. Ansonsten ist da natürlich kein Unterschied.


----------



## Passion4Automation (24 November 2021)

philipp75 schrieb:


> ich habe das mal versucht und das PRG_PLC in eine definierte Task umgelagert, dann kommt der Fehler 4601
> "Fehler 4601: Netzwerkvariablen 'UDP': Es ist keine zyklische oder freilaufende Task zum Netzwerkvariablenaustausch vorhanden."
> 
> Die NetVars werden natürlich auch in dem Hauptprogramm verarbeitet.


Alles bereiningt und übersetzt???


----------



## Passion4Automation (24 November 2021)

philipp75 schrieb:


> ich habe das mal versucht und das PRG_PLC in eine definierte Task umgelagert, dann kommt der Fehler 4601
> "Fehler 4601: Netzwerkvariablen 'UDP': Es ist keine zyklische oder freilaufende Task zum Netzwerkvariablenaustausch vorhanden."
> 
> Die NetVars werden natürlich auch in dem Hauptprogramm verarbeitet.
> ...


Dürfte den PFC 200 normal nicht in die Knie zwingen, aber schaden tut das nicht wenn man sowas in einem extra Task legt.


----------



## philipp75 (24 November 2021)

ich versuche mich gerade mal dran. Muss mit meiner Familie noch eine "downtime" vereinbaren  Vorhin sind bei einem ersten Test die Lampen und Steckdosen ausgegangen-

Nach der Änderung bei den Tasks kam beim Versuch des programm uploads der Fehler 4601 --> Rückbau auf Alt-Zustand --> Online Change --> Lampen aus.


----------



## Passion4Automation (24 November 2021)

Das ist der Nachteil an der SPS, mit den dunklen Lampen .
Onlinechange ist nur bei ganz simplen Änderungen zu empfehlen, ansonsten die Kiste immer stoppen.


----------



## philipp75 (24 November 2021)

erstmal unglaublich vielen Dank für Eure Hilfe - das hat mir deutlich mehr Klarheit gebracht. Jetzt weiß ich wo ich ansetzen kann. Und das mit dem möglichen Masse-Problem prüfe ich dann wenn ich Softwareseitig nicht weiterkomme. 

Eine letzte Frage: in meinem Projekt habe ich ein paar Mal die Warnung "Ungültiger Watchausdruck" - ein Doppelklick schickt mich an eine Stelle in der Visu, die nichts mit der Variablen zu tun hat. Eine Globale Projekt Suche gibt mir keinen Treffer auf diese Variable.
Alle Rezepturen/Watchlisten sind gelöscht....

Wo kommt diese Warnung her?


----------



## PN/DP (24 November 2021)

philipp75 schrieb:


> Vermutlich macht es Sinn, das große Programm zu zerteilen und ein paar weniger relevante Themen auszulagern (Emailversand bei Störungen, die beiden Socket Programme für den Wetterdienst und die Luft-WärmePumpe - das alles sind ja keine zeitkritischen Bestandteile.


Wie ist das Programm eigentlich programmiert? Werden da vielleicht Reaktionen auf jedes Event sofort komplett ausprogrammiert/abgearbeitet, womöglich in Schleifen? Anstatt in Teilschritte/Schrittketten zu zerlegen? Und wenn viele Events zufällig zu schnell zusammen kommen dann braucht das Programm halt 400ms oder länger?
Es ist für mich noch nicht klar, wie diese immer wieder mal vorkommende hohe Zykluszeit zustande kommt.

Harald


----------



## Oberchefe (24 November 2021)

Ungültiger Watchausdruck kommt meiner Erfahrung nach dann, wenn eine Array-Variable mit Index in der Software angezeigt werden soll, der Index aber schon über das Array hinaus ist, was beispielsweise bei einer FOR-Schleife ganz normal ist und in dem Fall ignoriert werden kann.


----------



## Passion4Automation (24 November 2021)

Du hast wsl irgendwo in der Visu ein Element wo eine Variable drin steht die keine Referenz hat, also eine Leiche. Die Warnung sollte aber nicht ausschlaggebend sein.

Was mir noch einfällt.
Wenn du die DI,s über die 8202 einliest und über netvars zur SPS Beleuchtung sendest, musst du die Auswertung der Doppelklicks unbedingt in der 8202 machen und auch die Auswertung der Doppelklicks und die Weiterverarbeitung zu den DO,s sollten in der selben task sein. Da können auch die von dir beschriebenen Fehler auftreten.

Wenn man Task übergreifend Flanken oder Doppelklicks auswertet, sollte man mit Handshake arbeiten, nur so kann sichergestellt werden  dass auch alles abgearbeitet wurde.


----------



## Oberchefe (24 November 2021)

Ausschließlich zeitgesteuerte Tasks haben bei der Wago den Vorteil, dass immer ausreichend Zeit für die Kommunikation (z.B. mit Programmier-PC und HMI) bleibt.
Auf meiner (deutlich schwächeren) 750-841 habe ich:
-1 Sek Task für Regler
-2ms Task für Encoder einlesen (sehr wenig Code!)
- 350ms Task für TCP Kommunikation (ist bei der 841 noch blockierend!)
- 40ms Task für die "normale" Logik.


----------



## philipp75 (24 November 2021)

Vermutung: die langen Zykluszeiten entstehen, wenn ein Taster physikalisch hängen bleibt was schon hin und wieder mal vorkommt.
Doppelklicks gibts bei mir keine, nur gedrückt halten für Dimmen. Das würde meine Mitbewohner überfordern 

Schleifen gibts meine ich nicht - nur an einer Stelle gibts eine kleine FOR schleife in einem ST Programm, die mal über 3-4 indices drübergeht.

Es sind viele Netzwerke die z.B. selbstgebaute Bausteine hernehmen, alleine die LED Dimmer (64 Kanäle weiss, 16 Kanäle RGB) und nochmal 64 Steckdosen. Ob das ideal programmiert ist, kann ich nicht sagen, dazu fehlt mir das Fachwissen.

Es gibt 5 verschiedene Timer (heizung, beleuchtungssteuerung, etc.)


----------



## Oberchefe (24 November 2021)

> Vermutung: die langen Zykluszeiten entstehen, wenn ein Taster physikalisch hängen bleibt was schon hin und wieder mal vorkommt.



Dann würde mich mal der Code für einen Taster interessieren


----------



## PN/DP (24 November 2021)

Oberchefe schrieb:


> philipp75 schrieb:
> 
> 
> > Vermutung: die langen Zykluszeiten entstehen, wenn ein Taster physikalisch hängen bleibt was schon hin und wieder mal vorkommt.
> ...


Mich auch. Ob ein Taster gedrückt ist oder nicht sollte sich nur äußerst minimal auf die Zykluszeit auswirken.

Harald


----------



## philipp75 (24 November 2021)

Grobe Struktur:


Beispiel Flurlicht:





FB_DMX_MAX

```
Masterfader;
Tastenauswertung;
Visu_Farbwerte;

IF xZentral_AUS OR DMX_Select_Off  OR (Taste_kurz OR (Taste_lang OR (Richtungswechsel OR (bHelligkeitswert <> REAL_TO_BYTE(Akku)))))THEN

    Akku:=BYTE_TO_REAL(bHelligkeitswert);
    MinWert:=INT_TO_REAL(iMinWert);
    MaxWert:=INT_TO_REAL(iMaxWert);

    (*Grenzwertvorgabe*)

    IF MaxWert > 255 THEN
        MaxWert:=255;
    ELSIF MaxWert <MinWert THEN
        MaxWert := MinWert + rSchrittweite_uB;
    END_IF

    IF MinWert < 0 THEN
        MinWert := 0;
    ELSIF MinWert > MaxWert THEN
        MinWert := MaxWert - rSchrittweite_oB;
    END_IF

    (*Vorgabe der Dimmrichtung*)

    IF Richtungswechsel THEN
        IF (Dimm_rauf AND (Akku > (MinWert + 30)))THEN
            Dimm_rauf:= FALSE;
            Dimm_runter:=TRUE;
        ELSIF (Dimm_runter AND (Akku < (MaxWert - 30))) THEN
            Dimm_rauf:= TRUE;
            Dimm_runter:=FALSE;
        END_IF
    END_IF

    (* Verarbeitung  - kurzer Tastendruck*)
    (*(Taste_kurz  AND (Akku = 0)) OR*)

    IF    (Taste_kurz  AND (Akku = 0)) THEN
        IF xLetzter_Wert AND (letzter_Wert <>0)THEN
            Akku:=letzter_Wert;
        ELSE Akku := MaxWert;
        END_IF
    ELSIF (Taste_kurz AND (Akku > 0)) THEN
            Akku:=0;
    END_IF

    (* Verarbeitung  - langer Tastendruck*)

    IF Taste_lang THEN
        IF Dimm_rauf THEN
                IF Akku < MinWert THEN
                    Akku:=MinWert;
                ELSE
                    IF Akku<=rBereichsgrenze THEN
                        Akku := Akku + rSchrittweite_uB;
                    ELSIF Akku>rBereichsgrenze THEN
                        Akku := Akku + rSchrittweite_oB;
                    END_IF
                END_IF
                IF Akku > MaxWert THEN
                    Akku := MaxWert;
                END_IF
        ELSIF Dimm_runter THEN
                IF Akku<=rBereichsgrenze THEN
                    Akku := Akku - rSchrittweite_uB;
                ELSIF Akku>rBereichsgrenze THEN
                    Akku := Akku - rSchrittweite_oB;
                END_IF
                IF xAus_bei_Min THEN
                    IF ((Akku <= MinWert) AND (Akku <>0))THEN
                        Akku := 0;
                    END_IF
                ELSIF Akku < MinWert THEN
                    Akku := MinWert;
                END_IF
        END_IF
    END_IF

    (* Verarbeitung  - Zentral-Aus*)

    IF (xZentral_AUS OR DMX_Select_Off) THEN
        Akku:=0;
        IF Dimm_runter THEN
        Dimm_runter:=FALSE;
        DImm_rauf:=TRUE;
        END_IF
    END_IF



    (* letzten Helligkteiswert merken*)

    IF Akku >0 THEN
        letzter_Wert:=Akku;
        IF (NOT xLetzter_Wert_vor_MaxWert) AND letzter_Wert >MaxWert THEN
            letzter_Wert := MaxWert;
        END_IF
    END_IF

bHelligkeitswert:=REAL_TO_BYTE(Akku);
rProzentWert:=Akku/255*100;

    (*Werteübergabe am Masterfader*)

    bValue_in:=bHelligkeitswert;

END_IF
```


----------



## philipp75 (24 November 2021)

Dann hier noch "Masterfader":



Tasterauswertung:


----------



## Oberchefe (24 November 2021)

In dem Code vom Baustein kann ich keine Verwendung von "xTaste" erkennen?


----------



## philipp75 (24 November 2021)

gute Frage..... gerade nochmal nachgesehen, ist da nicht zu finden...


```
FUNCTION_BLOCK FB_DMX_MAX
(*****************************************************
DMX Baustein White
*****************************************************)

VAR_INPUT
    xTaste: BOOL;
    xZentral_AUS: BOOL:=FALSE;
    xLetzter_Wert: BOOL:=FALSE;
    xLetzter_Wert_vor_MaxWert: BOOL:=TRUE;
    xAus_bei_Min:BOOL:=FALSE;
    rSchrittweite_uB:REAL:=1;
    rSchrittweite_oB:REAL:=1;
    rBereichsgrenze:REAL:=150;
    iMinWert: INT:= 0;
    iMaxWert: INT:= 255;
    bMasterfader        :BYTE;                            (* Fadet alle Bausteine Global*)
    xTaste_Flash        :BOOL;                            (*Ausgang ist aktiv,  so lange Eingang TRUE ist .Ausgang immer mind 10 %,
                                                        oder der letzte gespeichterte Wert - Masterfader wird immer  überlagert *)
    XTaste_EIN        :BOOL;                            (*Einschalimpuls z.B. für Timer*)
    XTaste_Nacht        :BOOL;                            (* wenn Nacht True, dann immer 4 % Wert am ausgang - Nachtlichtsteuerung *)
    Masterfader_Funktion: BOOL;                    (* wenn True, dann immer Wirkt der Masterfader direkt auf den Ausgang *)
    DMX_Select_On    :BOOL;                            (* Einschaltimpuls über DMX Select Baustein *)
    DMX_Select_Off    :BOOL;                            (* Ausschaltimpuls über DMX Select Baustein *)


END_VAR

VAR_OUTPUT

    bDMX_out        : BYTE;
    rProzent        : REAL;
    dFarbe_Visu    : DWORD;
    Status_An_aus: BOOL;

END_VAR

VAR_IN_OUT

    bHelligkeitswert: BYTE;

END_VAR
VAR
    Akku:REAL;
    MinWert:REAL;
    MaxWert:REAL;
    letzter_Wert: REAL;
    Taste_kurz: BOOL;
    Taste_Lang: BOOL;
    TON_FBDimm: TON;
    Dimm_rauf: BOOL:=TRUE;
    Dimm_runter: BOOL;
    FTRIG_taste_lang: F_TRIG;
    FTRIG_taste: F_TRIG;
    Richtungswechsel: BOOL;

    rProzentwert:REAL;
    bValue_in    :BYTE;
    TP_X_Ein: R_TRIG;


END_VAR
```


----------



## Oberchefe (24 November 2021)

Also greift "Masterfader" auf Variablen außerhalb seines Bausteins zu -> unschön.

Aber ich kann noch keinen Showstopper erkennen.


----------



## philipp75 (24 November 2021)

ich gebs für heute auf, aber ich kann sagen dass die RGB Teile ähnlich gebaut sind. @Oberchefe, nochmals 1000 Dank für Deine Geduld!


----------



## philipp75 (24 November 2021)

Oberchefe schrieb:


> Also greift "Masterfader" auf Variablen außerhalb seines Bausteins zu -> unschön.
> 
> Aber ich kann noch keinen Showstopper erkennen.


Tut er das?
alle Werte in Masterfader werden als INPUT an FB_DMX_MAX übergeben meine ich


----------



## Oberchefe (25 November 2021)

> alle Werte in Masterfader werden als INPUT an FB_DMX_MAX übergeben meine ich





> FB_DMX_MAX
> 
> 
> Code:
> ...



Masterfader wird vom FB_DMX_MAX aus aufgerufen?


----------



## philipp75 (25 November 2021)

Ja -


----------



## philipp75 (25 November 2021)

kann man sich irgendwie die Zykluszeiten aller Unterprogramme im einzelnen aus der PLC_PRG Main ansehen oder muss ich jeden Programmaufruf mit irgendeinem Start / End Codeblock umgeben um das Delta zu messen?


----------



## Passion4Automation (25 November 2021)

Also ich weiß da nichts. Musst halt jedes PRG Schritt für Schritt mal deaktivieren.
Ich kenn mich mit Dmx nicht aus  aber kann mich erinnern das in der Vergangenheit andere user damit Probleme hatten. 
Wenn du deinen Fehler in diese Richtung eingrenzen kannst wäre ein Anruf beim Support nicht verkehrt.


----------



## Eigenheim_Bastler (26 November 2021)

Hallo

Ich hatte einmal ein ähnliches Problem, das mir Taster und vor allem Dimmer nicht mehr richtig reagierten.
Bei mir lag es am Summenstrom des K-Buses / Systemversorgung.
Ich hatte am ende noch eine zusätzliche Karte angesteckt und dies nicht kontrolliert.
Und dann häuften sich auch solche "Fehler", leider auch erst im Verlauf der nächsten Wochen und nicht unmittelbar.


----------



## holgermaik (26 November 2021)

Hallo Philipp
um den PFC auf über 200ms zu bekommen ist schon einiges nötig.
Um etwas konkretes dazu sagen zu können lade doch dein Programm mit den Bibliotheken hoch wenn du möchtest.

Hast du zum Linux noch etwas hinzuinstalliert (Docker, Phyton Scripte,..??)


----------

