-> Hier kostenlos registrieren
Glaskugel kaputt...
DALI THREAD - Von Anfänger zu Anfänger "WAGO" bezogen
- Ersteller KingHelmer
- Erstellt am
-> Hier kostenlos registrieren
-> Hier kostenlos registrieren
Hi, Sensoren sind keine dabei, über den Wago IO-Check kann ich alles ein bzw. ausschalten.
Die LED`s sind OK.
für mich wäre es interessant, ob ich z.B. nach xready warten muss, um das update-bit zu setzen o.ä.
Könnte es sein, daß im Taskmanager die Dali-Prio ganz vorne stehen muss?
Momentan läuft der Dali Master-Aufruf freilaufend. das Senden erfolgt direkt nach dem xready Signal.
Die LED`s sind OK.
für mich wäre es interessant, ob ich z.B. nach xready warten muss, um das update-bit zu setzen o.ä.
Könnte es sein, daß im Taskmanager die Dali-Prio ganz vorne stehen muss?
Momentan läuft der Dali Master-Aufruf freilaufend. das Senden erfolgt direkt nach dem xready Signal.
Moin Andy,
die DALI-Module sollten nicht im freilaufenden Task laufen. Ich gehe davon aus, dass Du schon mit Codesys 3.5 arbeitest? Das Tasksystem ist oft eine Fehlerursache. Um das richtig zu konfigurieren, muss man das gesamte Projekt Deines Controllers kennen. Ich würde einen separaten Task anlegen nur für DALI, der alle 70ms aufgerufen wird in der Prio 12. Die Prio 15 ist am besten für alle Aufgaben, die nicht zeitkritisch sind. Deine DALI-Klemme kannst Du mit einem Braunkohlebagger vergleichen. Die Förderbänder sind der Klemmenbus. Die Geschwindigkeit der Förderbänder Deine Taskzeit. Dreht sich das Baggerrad und die Förderbänder laufen zu langsam, kommt es zu Verstopfungen. Laufen sie zu schnell, fliegt was aus der Kurve. Deswegen muss die Geschwindigkeit passen. Im freilaufenden Task würde ich nie Kommunikationsklemmen betreiben. Das Beispiel ist natürlich sehr weit hergeholt. Was meinst Du eigentlich, Du sendest mit xReady? Mich würde da einmal Dein Code interessieren. DALI versendet automatisch seine Telegramme bei Interaktion an den Bausteineingängen.
die DALI-Module sollten nicht im freilaufenden Task laufen. Ich gehe davon aus, dass Du schon mit Codesys 3.5 arbeitest? Das Tasksystem ist oft eine Fehlerursache. Um das richtig zu konfigurieren, muss man das gesamte Projekt Deines Controllers kennen. Ich würde einen separaten Task anlegen nur für DALI, der alle 70ms aufgerufen wird in der Prio 12. Die Prio 15 ist am besten für alle Aufgaben, die nicht zeitkritisch sind. Deine DALI-Klemme kannst Du mit einem Braunkohlebagger vergleichen. Die Förderbänder sind der Klemmenbus. Die Geschwindigkeit der Förderbänder Deine Taskzeit. Dreht sich das Baggerrad und die Förderbänder laufen zu langsam, kommt es zu Verstopfungen. Laufen sie zu schnell, fliegt was aus der Kurve. Deswegen muss die Geschwindigkeit passen. Im freilaufenden Task würde ich nie Kommunikationsklemmen betreiben. Das Beispiel ist natürlich sehr weit hergeholt. Was meinst Du eigentlich, Du sendest mit xReady? Mich würde da einmal Dein Code interessieren. DALI versendet automatisch seine Telegramme bei Interaktion an den Bausteineingängen.
Hallo,
ich bin in Codesys 2.3 unterwegs.
siehe Steuerungsconfig hängen die Dali Module über Profibus an der PLC.
Das Programm hatte ich ursprünglich nicht selbst geschrieben, muss es jetzt aber reparieren.
Siehe unten der Code. Über den (momentan freilaufenden ) PRG_Trockenkanal werden die FB`s der 6 Module aufgerufen.
Diese steuern je 2 mal 16 Vorschaltgeräte mit den selben werten an.
Mittlerweile habe ich die 16 EVG`s immer in Gruppen zusammengefasst, um Datenmengen zu verringern. Hat auch nicht viel gebracht.
Danke für Dein Interesse.
Das Ganze ist in eine Beschichtungsanlage integriert... und ist ein prozesskritisches Merkmal.. d.h., bleibt der Fehler stehen, gehen die Lampen auf 100 % und das produzierte material ist Schrott.
Drum freue ich mich über jeden Input.
ich bin in Codesys 2.3 unterwegs.
siehe Steuerungsconfig hängen die Dali Module über Profibus an der PLC.
Das Programm hatte ich ursprünglich nicht selbst geschrieben, muss es jetzt aber reparieren.
Siehe unten der Code. Über den (momentan freilaufenden ) PRG_Trockenkanal werden die FB`s der 6 Module aufgerufen.
Diese steuern je 2 mal 16 Vorschaltgeräte mit den selben werten an.
Mittlerweile habe ich die 16 EVG`s immer in Gruppen zusammengefasst, um Datenmengen zu verringern. Hat auch nicht viel gebracht.
Danke für Dein Interesse.
Das Ganze ist in eine Beschichtungsanlage integriert... und ist ein prozesskritisches Merkmal.. d.h., bleibt der Fehler stehen, gehen die Lampen auf 100 % und das produzierte material ist Schrott.
Drum freue ich mich über jeden Input.Anhänge
-> Hier kostenlos registrieren
Das heißt, der Code läuft nicht auf einem WAGO-Controller direkt? Die Klemmen sind mit einem Profibus-Koppler an einem PFC 200 angebunden?
Hi, die rote Linie ist die Maschinengeschwindigkeit, die orangene der Status Lampen (Strom, nicht strom) und die grauen bzw blauen sind die Kommunikationsfehler. Ich verstehe nicht, warum gerade das Modul 2 soooo rumspinnt. Die Zykluszeiten sind ja alle gleich. Oder wird der Task immer da von was anderem unterbrochen?
Ich versuche morgen mal was mit den 70 ms.. Vielleicht hilfts.
Ich versuche morgen mal was mit den 70 ms.. Vielleicht hilfts.
Anhänge
-> Hier kostenlos registrieren
Mit Profibus bin ich leider raus, da habe ich keine Erfahrungen. Deine PLC ist aber ein PFC200 von WAGO, soweit ich das aus der Steuerungskonfig ersehen kann. Definitiv ist es so, dass die Prio 30 von allen Task die kleinste Prio hat. Alles was davor kommt, unterbricht diesen Task. Ich vermute, dass die Klemme ihre Daten nicht so schnell loswird und es deshalb zu Stau und Verlusten kommt und die Mailbox einen Fehler auswirft. In der Situation CDS2.3 und PFC200 würde ich den DALI in die Prio 10 legen und mit 70ms aufrufen. Allerdings muss man sich das Gesamtkonstrukt der Task ansehen. In Deinem Screenshot sehe ich schon mehr als 13 angelegte Task. Die Anlage würde ich gerne einmal live mit dem PLC-Browser sehen wollen, wie die Zykluszeiten sich verhalten. Bei mir verdichtet sich der Eindruck, dass Du ein Taskproblem hast. Jeder Task mit höherer Prio unterbricht die anderen Task. Dazu kommt noch das Betriebssystem und die Netzwerkkarte, die auch einen Interrupt verursacht. Aktuell würde ich vermuten, Dein Dalitask wird ständig unterbrochen und kommt deshalb nur schwer klar.
Hallo,
ich habe jetzt das Programm mit 30 ms zyklus laufen. Ich checke eine Werteänderung alle 500 ms und 80ms danach mache ich das Update.
Der Master und der Senddimmvalue laufen also beide im 30ms Takt, das Update alle 500 ms.
Bis jetzt sieht es ganz gut aus,... aber jetzt muss ich mal warten, wie es über die Zeit aussieht.
Was mich noch immer wundert, wo der Zusammenhang der Fehler mit dem Einschalten der Lampen gelegen hat.
Geschrieben habe ich ja die ganze Zeit.
Andi
ich habe jetzt das Programm mit 30 ms zyklus laufen. Ich checke eine Werteänderung alle 500 ms und 80ms danach mache ich das Update.
Der Master und der Senddimmvalue laufen also beide im 30ms Takt, das Update alle 500 ms.
Bis jetzt sieht es ganz gut aus,... aber jetzt muss ich mal warten, wie es über die Zeit aussieht.
Was mich noch immer wundert, wo der Zusammenhang der Fehler mit dem Einschalten der Lampen gelegen hat.
Geschrieben habe ich ja die ganze Zeit.
Andi
-> Hier kostenlos registrieren
Wertänderung alle 500ms? Ist der Prozess so kritisch? Der Klemmenbus kann nur 10ms im besten Fall. Der Master und der DALI-Baustein müssen zwingend im selben Task laufen, sonst gibt es Probleme. Wenn es jetzt funktioniert, freue ich mich, Dir geholfen zu haben. Wenn der Controller trotzdem mal etwas mehr Luft benötigt, bis 70ms kann man mit DALI schon gehen. Es gibt kein Patent-Rezept, man muss es ein wenig ausprobieren. Am besten kannst Du die Zykluszeiten über den PLC-Browser beobachten (Hier ohne Linux) oder im Linux selbst auf der Konsole über "HTop"
Warum der Fehler beim einschalten der Lampen passiert...ich kann nur mutmaßen. Wenn ich Dein Programm recht gelesen habe, schaltest Du DALI-Kurzadressen einzeln und keine kompletten Datengruppen? der DALI ist kein Formel 1, mit 1.200 Baud ist er recht langsam. Wenn Du viele Befehle auf den Bus ballerst, brauchen die eine Weile und die Klemme ist beschäftigt. Wenn dann noch Rückinfos aus den EVG´s kommen...gibts Panik und ´die weiße Flagge wird geschwenkt. Daher muss genug Speed am "Förderband" sein, damit die Daten rechtzeitig verarbeitet werden.
Warum der Fehler beim einschalten der Lampen passiert...ich kann nur mutmaßen. Wenn ich Dein Programm recht gelesen habe, schaltest Du DALI-Kurzadressen einzeln und keine kompletten Datengruppen? der DALI ist kein Formel 1, mit 1.200 Baud ist er recht langsam. Wenn Du viele Befehle auf den Bus ballerst, brauchen die eine Weile und die Klemme ist beschäftigt. Wenn dann noch Rückinfos aus den EVG´s kommen...gibts Panik und ´die weiße Flagge wird geschwenkt. Daher muss genug Speed am "Förderband" sein, damit die Daten rechtzeitig verarbeitet werden.
Hallo,
wir hatten jetzt mal die Anschlüsse von Klemme2 an Klemme1 und umgekehrt gesteckt. Die Fehler kamen wieder bei Modul 2, (eigendlich frisch getauscht) Also wirds an den EVG`s und Verkabelung nicht liegen.
Wir haben jetzt alle nochmal neu gesteckt und kontrolliert. sehen wir morgen, obs was gebracht hat. Sonst testen wir nochmal eine neue Karte.
Ich glaube langsam, daß die Programmierung der ausschlaggebende Faktor ist, obwohl die gesamtfehlermeldungen stark zurückgegangen sind.
Dank Deiner Hilfe.. Merci.
Ich rühre mich morgen noch einmal..
wir hatten jetzt mal die Anschlüsse von Klemme2 an Klemme1 und umgekehrt gesteckt. Die Fehler kamen wieder bei Modul 2, (eigendlich frisch getauscht) Also wirds an den EVG`s und Verkabelung nicht liegen.
Wir haben jetzt alle nochmal neu gesteckt und kontrolliert. sehen wir morgen, obs was gebracht hat. Sonst testen wir nochmal eine neue Karte.
Ich glaube langsam, daß die Programmierung der ausschlaggebende Faktor ist, obwohl die gesamtfehlermeldungen stark zurückgegangen sind.
Dank Deiner Hilfe.. Merci.
Ich rühre mich morgen noch einmal..
So,.. hat alles noch nix gebracht. Fehler 108 (Mailbox konnte nicht initialisiert werden) ist führend,
Fehler 13 (Eingangspuffer voll) ist deutlich weniger geworden.
Inzwischen haben wir je Modul 4 Gruppen gebildet, die angesprochen werden. Sollte also viel weniger Stress bedeuten.
Fehler 13 (Eingangspuffer voll) ist deutlich weniger geworden.
Inzwischen haben wir je Modul 4 Gruppen gebildet, die angesprochen werden. Sollte also viel weniger Stress bedeuten.
-> Hier kostenlos registrieren
Die Fehler tauchen im Abstand von 1-5 min auf.