warum läuft dieser einfach FUP nicht ganz korrekt

forellengarten

Level-1
Beiträge
217
Reaktionspunkte
1
Zuviel Werbung?
-> Hier kostenlos registrieren
wäre mal jemand von euch so nett und wirft auf das angefügte testprogramm (PDF) einen blick: ein Taster wird entprellt und schaltet einen verbraucher ein und aus.

in der Codesys-Simulation läuft das alles einwandfrei. auf der beckhoff-SPS flackert der Ausgang ca. im halb-sekundentakt. warum nur??:confused:
 

Anhänge

  • FUP.pdf
    78,3 KB · Aufrufe: 97
Zuletzt bearbeitet:
auch diese Version bringt keine Verbesserung

interessanterweise bringt auch die Version mit einem OR-Gatter am Ausgang (logisch mit 1 verknüpft) keine Verbesserung. Der DigitalOut-Port blinkt anstatt einfach nur EIN zu sein :confused::confused::confused:
 

Anhänge

  • FUP - mit OR-Gatter.pdf
    80,3 KB · Aufrufe: 13
Zuviel Werbung?
-> Hier kostenlos registrieren
in der Codesys-Simulation läuft das alles einwandfrei. auf der beckhoff-SPS flackert der Ausgang ca. im halb-sekundentakt. warum nur??:confused:
Wenn es in der Simulation funktioniert und in der SPS nicht könnte es vielleicht an der Anbindung an die E/As liegen. Anstelle des Screenshot als PDF hättest Du mal lieber Dein TwinCAT Projekt hoch geladen Code und Konfiguration.

PS: Hast Du das Projekt bereits bereinigt und neu übersetzt?
 
Wenn es in der Simulation funktioniert und in der SPS nicht könnte es vielleicht an der Anbindung an die E/As liegen. Anstelle des Screenshot als PDF hättest Du mal lieber Dein TwinCAT Projekt hoch geladen Code und Konfiguration.

PS: Hast Du das Projekt bereits bereinigt und neu übersetzt?


alles probiert. kreuz und quer. seit einem tag probiere ich herum und drehe mich im kreis. im anhang nochmal die originaldateien....

im Anhang die Dateien zwecks Überprüfung. Danke!
 

Anhänge

  • TwinCat.zip
    23,2 KB · Aufrufe: 8
ok. dann das gleich nochmal in einer anderen komprimierung (abwärtskompatibel).


Eines konnte ich jedoch mittlerweile rausfinden: ich hatte als Zykluszeit 200ms eingestellt. ändere ich dies auf 20ms ist kein Fehler mehr feststellbar (kann auch mit dem Multimeter keine Frequenz mehr messen).
Jetzt habe ich das ganze mal testweise auf 100ms Zykluszeit gestellt und... der Fehler tritt noch gelegentlich aus (ca. alle 10sec geht der Digitalausgang mal kurz auf Low). Irgendwie eine sehr unzufriedenstellende Sache.

Warum der Fehler auftritt. Wo die Grenze liegt zwischen geht/geht nicht bleibt allerdings ein Rätsel, um dessen Auflösung ich euch sehr dankbar wäre!
 
Zuletzt bearbeitet:
Ich hab zwar keine Ahnung was dein Toggle macht, aber zum Entprellen eines Einganges habe ich bis jetzt immer eine Einschaltverzögerung genommen, d.h. ich würde einen TON anstatt des TOF verwenden.

Georg
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hab zwar keine Ahnung was dein Toggle macht, aber zum Entprellen eines Einganges habe ich bis jetzt immer eine Einschaltverzögerung genommen, d.h. ich würde einen TON anstatt des TOF verwenden.

Georg


danke georg. das klärt nur leider die frage nicht. außerdem hebt das letzte OR-Gatter ohnehin jede davorliegende Schaltung auf, da es mit "1" verknüpft ist und daher immer eine "1" am ausgang ausgibt. Toggle kommt übrigens direkt aus der oscat.lib.
 
Ich hatte vor Jahren mal das Problem, dass meine Ausgänge nicht mehr reagiert haben. Grund dafür war, dass ich meine Ausgänge zu langsam aktualisiert habe und deshalb ein interner Watchdog zugeschlagen hat. Kann mir aber kaum vorstellen, dass das bereits nach 200 ms der Fall ist.
 
Wenn ich mich mal einschalten darf, das Problem ist nicht der FUP Baustein sondern die 200 ms Taskzeit. Die Taskzeit sollte deutlich unter 100 ms liegen. TC arbeitet Task Synchron. Wenn eine Task sehr langsam ist schlagen zum Beispiel der Watchdog des Feldbussystems zu. Beim K-Bus wie hier schon nach 100ms. Das heißt du solltest nicht unnötigerweise 200 ms nutzen sondern 10 ms oder 20 ms. Du kannst eine 2te Task mit 200 ms laufen lassen aber die IOs über die schnelle Task.

Das erklärt ja auch warum der Fehler dann nur noch selten bei 100 ms auftritt. Mal schafft er das in genau 100ms mal sind es etwas mehr als 100ms und dann tritt ein Watchdogfehler auf.

Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn ich mich mal einschalten darf, das Problem ist nicht der FUP Baustein sondern die 200 ms Taskzeit. Die Taskzeit sollte deutlich unter 100 ms liegen. TC arbeitet Task Synchron. Wenn eine Task sehr langsam ist schlagen zum Beispiel der Watchdog des Feldbussystems zu. Beim K-Bus wie hier schon nach 100ms. Das heißt du solltest nicht unnötigerweise 200 ms nutzen sondern 10 ms oder 20 ms. Du kannst eine 2te Task mit 200 ms laufen lassen aber die IOs über die schnelle Task.

Das erklärt ja auch warum der Fehler dann nur noch selten bei 100 ms auftritt. Mal schafft er das in genau 100ms mal sind es etwas mehr als 100ms und dann tritt ein Watchdogfehler auf.

Gruß


Hallo Feldbus,
danke daß du dich eingeschaltet hast:TOOL:. Meine Vermutung ging bereits in diese Richtung, jedoch habe ich keine Literatur darüber gefunden. Dann liegt es wohl tatsächlich daran und es ist einfach nicht zulässig eine derart langsame Zykluszeit vorzugeben. Ich hab viel über die Sache nachgedacht und herumexperimentiert, weil ich vermeiden möchte, daß in Zukunft bei meiner Steuerung "Zufallsfehler" auftreten.
 
Wenn du mehr wissen willst dazu suche im TCInfoSystem danach...

CX1100-00xx: Architektur der Netzteile

Das kannst du auch für den CX9000 übernehmen.

Gruß
 
Zuviel Werbung?
-> Hier kostenlos registrieren

super, ihr seid echt der hammer! danke. werde noch genauer nachlesen, habe aber schon den ersten interessanten teil gefunden:

... werden alle Ausgänge in den sicheren Zustand (alle Ausgänge auf "Null") gesetzt. Gleichzeitig wird der Wert im Register "Watchdog Error Counter" inkrementiert. Die Standardeinstellung für diesen Wert beträgt 100ms. Soll ein anderer Wert verwendet ....

super. Das war eine echte Hilfe. Danke! :TOOL:
 
Zurück
Oben