Timingproblem bei der EA-Kommunikation?

  • Hallo,


    ich habe hier eine 5.15 mit Multitasking. Einer der Hintergrundtasks läuft SPS-like zyklisch durch und macht die Anlagensteuerung, dabei werden die Ausgänge auch immer wieder ungefähr so überschrieben:


    setdo do_irgendwas, bool2num(bedingung1_erfüllt and bedingung2erfüllt and so on...);


    Die EA-Kopplung geht über DeviceNet Lean an einen Beckhoff Buskoppler.


    In zwei älteren (2010), quasi baugleichen Maschinen, funktioniert das seit Jahren im Produktionseinsatz. Jetzt wollten wir das noch einmal so bauen - und ich verliere unregelmäßig den Kontakt zur EA-Einheit mit dem Fehler 41555. Aber nur, wenn diese Task läuft.


    Habe versucht, statt DN Lean DN Lean polled zu nehmen und verschiedene Parameter ausprobiert, aber immer nur die Wahrscheinlichkeit verändert, mit der der Fehler reproduzierbar auftritt. Weg war er nie.
    Bin jetzt wieder zurück auf der ereignisgesteuerten Weise. Wenn ich meinen "SPS-Task" zwischendurch immer mal wieder ein paar Millisekunden mit WaitTime unterbreche, kommt der Fehler seltener. Das Unterbrechen EINMAL pro Zyklus bringt nichts, egal wie lange die Pause wird. Scheinbar verschluckt sich der Bus wegen Datenstau.


    Kennt einer noch ein paar Schrauben, an denen ich drehen kann? Wäre es hilfreich, jeden SetDO (und ein paar SetAO) so umzuprogrammieren, dass sie nur ausgeführt werden, wenn sich tatsächlich was ändert? Bevor ich den Aufwand treibe, wüsste ich gern, ob das was bringt... und ob der Lesebefehl, den ich dann (naheliegendst) wieder dafür verwenden würde, nicht ebenfalls zum Desaster beiträgt.
    Also konkret: wäre "if (doutput(do_irgendwas)<>bool2num(bedingung)) setdo do_irgendwas, bool2num(bedingung)" geeignet, für weniger Verkehr auf dem Bus zu sorgen? Oder müsste ich mir die Zustände der Ausgänge besser separat speichern?


    Grüße,
    Michael

  • ANZEIGE

  • hast du den Task ohne ein Waittime laufen?


    Nö, in der ursprünglichen Version war EIN Waittime von 10ms drin. Funktioniert aber so nicht mehr. Hatte dann mal testweise 0.5 Sekunden, dadurch kam der Fehler seltener, aber nicht nie. Was aber auch logisch ist, da der Zyklus seltener durchlaufen wurde.
    Heute habe ich einmal 8, zweimal 5 und einmal 10 Millisekunden zwischen die Aktionen verteilt, da war jetzt seit Stunden kein Fehler mehr. Und die 4 AO (à 16Bit) schreibe ich nur noch bei Änderung raus. Was mich aber noch nicht glücklich macht, denn bisher haben die sich noch nie geändert.


    Grüße,
    Michael

Hilfe und Support für ABB Roboter Programmierung, Konfiguration, Inbetriebnahme finden Sie hier im ABB Roboter Forum. ABB Rapid Programmierung ist einfach, die Roboterforum Community hilft sehr gerne.

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden