Step 7 S7 Kommunikation, BSEND zu langsam im OB35 Weckalarm (10ms)

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Versuche auch mal den OB35 z.B. auf 100 oder 200ms hochzusetzen, und dann in jedem Aufruf einen Zähler um 1 zu erhöhen und diesen mitzuschicken.

??? Im Gegenteil! Need4Speed möchte doch alle 10 ms senden und muss deshalb innerhalb von 10 ms mindestens 2-mal den SendeBaustein aufrufen, damit es innerhalb der 10 ms Intervalle zu einem positiven FlankenWechsel des Sendetrigger kommen kann.
Also doppelt so oft und nicht in 10- bis 20-mal so grossen Abständen!

Und auch nicht "in jedem Aufruf einen Zähler um 1 erhöhen", sondern nur bei einer positiven Flanke des Sendetrigger.

​

Genau das (2-mal innerhalb von 10 ms den SendeBaustein aufrufen) tut Need4Speed (nomen est omen ;o) ja auch:

der BSEND sendet definitiv beim jedem Aufruf- ich habe mir da mit einer "Holzhammermethode" beholfen, und zwar so,
dass ich den BSEND mit denselben Parametern (DB, lokale und remote ID; Ausnahme: Sendetrigger, den lasse ich hier auf "FALSE") 2x aufrufe: ...

... wobei allerdings die Behauptung "der BSEND sendet definitiv beim jedem Aufruf" definitiv falsch ist!
Die Aufrufe mit Sendetrigger=0 sind doch auch als Aufrufe mitzuzählen, obwohl sie definitiv kein Senden starten, sondern "nur" den Start im nächsten Aufruf mit Sendetrigger=1 ermöglichen.

... der erste Aufruf ist quasi zur Abfrage des Status (Done, Busy/Sending, Error), und falls der Status nicht "busy" ist,
dann im zweiten Aufruf mit dem Sendetrigger auf "TRUE"

Nicht wirklich: der erste Aufruf ist quasi die "VerschnaufPause" mit Sendetrigger=0, die unverzichtbar ist, wenn der SendeBaustein jemals wieder eine positive Flanke des Sendetrigger erkennen soll.

 

[Thomas_v2.1]

??? Im Gegenteil! Need4Speed möchte doch alle 10 ms senden und muss deshalb innerhalb von 10 ms mindestens 2-mal den SendeBaustein aufrufen, damit es innerhalb der 10 ms Intervalle zu einem positiven FlankenWechsel des Sendetrigger kommen kann.
Also doppelt so oft und nicht in 10- bis 20-mal so grossen Abständen!

Und auch nicht "in jedem Aufruf einen Zähler um 1 erhöhen", sondern nur bei einer positiven Flanke des

Sendetrigger.
​

Der Test den OB35 zu verlangsamen diente dazu, um festzustellen ob sein Programm generell dazu in der Lage ist in jedem Aufrufzyklus ein BSEND-Telegramm abzusenden. Darum den OB35 so langsam stellen, dass der BSEND in jedem Fall fertig werden dürfte, und auch einen Zähler pro OB35 Aufruf erhöhen. Dann sieht man ob der Partner wirklich jeden Aufruf mitbekommt.

Ich habe mal ein Testumgebung welche ich hier bei BSEND/BRCV für mein Wireshark-Plugin aufgesetzt hatte aktiviert. Kommunikationspartner für die BSEND/BRCV-Kommunikation sind eine Et200S-CPU und WinCC 7.3. BSEND mit 822 Bytes Sendedaten in der SPS im 10ms Zyklus aufgerufen, Kommunikationslast auf 50% eingestellt. Es kommt jedes Telegramm im WinCC an. Die SPS macht sonst allerdings nichts, d.h. Programm OB1 leer, keine anderen Kommunikationsfunktionen. Sobald auch nur eine anderweitige Kommunikationsfunktion wie Bausteinstatus oder Variablentabelle aktiviert sind, gehen OB35 Zyklen verloren.​

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Thomas
Ich empfinde es auch durchaus als "ambitioniert", knapp 100 KB/s von der PLC "so nebenbei" in die Weltgeschichte schicken zu wollen.
Schliesslich müssen die ja noch "gesichtet" werden, um zu entscheiden, welche 99,999% davon schnellstens wieder entsorgt werden können ;o)
Oder sollen die Daten in RealTime ausgewertet werden, um z.B. eine GantryAchse zu zaubern?
Ich finde, man sollte vorrangig versuchen, die DatenFlut (stark!) zu reduzieren und die PLC gar nicht erst in Verlegenheit zu bringen.

Gruss, Heinileini

 

[Need4Speed]

Hallo Thomas,

vielen Dank, dass du das Szenario bei dir nachgestellt hast!

Ich habe mal ein Testumgebung welche ich hier bei BSEND/BRCV für mein Wireshark-Plugin aufgesetzt hatte aktiviert. Kommunikationspartner für die BSEND/BRCV-Kommunikation sind eine Et200S-CPU und WinCC 7.3. BSEND mit 822 Bytes Sendedaten in der SPS im 10ms Zyklus aufgerufen, Kommunikationslast auf 50% eingestellt. Es kommt jedes Telegramm im WinCC an. Die SPS macht sonst allerdings nichts, d.h. Programm OB1 leer, keine anderen Kommunikationsfunktionen. Sobald auch nur eine anderweitige Kommunikationsfunktion wie Bausteinstatus oder Variablentabelle aktiviert sind, gehen OB35 Zyklen verloren.

Dass Aufrufe des OB35 verloren gehen, sobald noch andere Kommunikationsfunktionen aktiv sind, ist natürlich etwas besorgniserregend. Ich habe es bei meinem Setup im Büro (nicht an der Maschine) getestet, da gehen erst mal keine Zyklen/Datenblöcke verloren.

Mein Setup ist

• eine 315 PN/DP und Linux PC an der Gegenstelle, beide am selben Switch
• OB35 auf 5ms eingestellt
• 4-fach kaskadierter Aufruf des BSEND (4x Puffer, 4x S7 Verbindung im NetPro)
• TUSEND mit 1472 (max) auch im OB35
• OB1 ruft eine Dummy Funktion auf (LOOP Schleife zum Beschreiben von 8000 Bytes eines DB)

Da kommen sowohl alle Datenblöcke über die BSEND Kaskade, als auch über TUSEND an. Aber morgen muss ich das natürlich noch an der Maschine testen, die hat eine rechte umfangreiche Ausstattung an PROFINET Teilnehmern (8x PN Device + 3x DP).

*) mit der BSEND Kaskade meine ich genau: ich rufe im OB35 BSEND 4x nacheinander auf, aber jeder BSEND Aufruf hat seinen eigenen SendePuffer (damit die Daten konsistent bleiben), und jeder BSEND hat seine eigene S7 Verbindung (passiv). Da beobachte ich dann, dass die BSEND "versetzt getriggert" werden. Allerdings ist der Zusammenhang nicht linear, also in dem Sinne, dass bei 2 BSEND Aufrufen doppelt so viele Datenblöcke übertragen werden können. Was genau sich da abspielt, müsste man mal in einer aufwändigen tcpdump/Wireshark Session nachvollziehen (vorausgesetzt man bekommt die Zeitstempel der Datenpakete gut aufgelöst, also am besten eine direkte Verbindung ohne Switch von CPU und PC).


VG, Jürgen

 

[Need4Speed]

Hallo Heinileini,

Genau das (2-mal innerhalb von 10 ms den SendeBaustein aufrufen) tut Need4Speed (nomen est omen ;o) ja auch:

genau- ich habe (leider) immer solche Themen: Zykluszeit zu lang, zu wenige Daten aus der CPU - aber langsam komme ich dem Siemens Zeug schon auf die Schliche, wobei: immer wenn man meint was verstanden zu haben, tun sich neue Abgründe auf, oder umgekehrt: je mehr ich weiss, desto mehr weiss ich, was ich nicht weiss ...

... wobei allerdings die Behauptung "der BSEND sendet definitiv beim jedem Aufruf" definitiv falsch ist!
Die Aufrufe mit Sendetrigger=0 sind doch auch als Aufrufe mitzuzählen, obwohl sie definitiv kein Senden starten, sondern "nur" den Start im nächsten Aufruf mit Sendetrigger=1 ermöglichen.

Nicht wirklich: der erste Aufruf ist quasi die "VerschnaufPause" mit Sendetrigger=0, die unverzichtbar ist, wenn der SendeBaustein jemals wieder eine positive Flanke des Sendetrigger erkennen soll.

Guter Punkt!! Ich meinte bei "Aufruf" den OB35, und dadurch, dass der BSEND dort 2x aufgerufen wird, wird auch (naja, bei der 315, bei der 317 noch nicht) bei jedem OB35 Aufruf die Datenübertragung angestossen.

Den Hinweis auf die "Verschnaufpause" finde ich übrigens super!! Wenn der BSEND immer mit "REQ:=TRUE" aufgerufen würden, gäbe es ja keine Flanke! Von daher ist der Kontrollaufruf mit "REQ:=TRUE" um den Status zu bestimmen (Done/Busy) absolut essentiell.

VG, Jürgen

 

[Need4Speed]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Heinileini,

@Thomas
Ich empfinde es auch durchaus als "ambitioniert", knapp 100 KB/s von der PLC "so nebenbei" in die Weltgeschichte schicken zu wollen.
Schliesslich müssen die ja noch "gesichtet" werden, um zu entscheiden, welche 99,999% davon schnellstens wieder entsorgt werden können ;o)
Oder sollen die Daten in RealTime ausgewertet werden, um z.B. eine GantryAchse zu zaubern?
Ich finde, man sollte vorrangig versuchen, die DatenFlut (stark!) zu reduzieren und die PLC gar nicht erst in Verlegenheit zu bringen.

Gruss, Heinileini

Tja, die Daten brauche ich schon mit möglichst hoher Abtastrate (Stichwort Werkzeugüberwachung & Traceability im Bearbeitungszentrum), und 100KB/s finde ich jetzt auch nicht viel. Meine naive Rechnung war, dass da ja mindestens eine 10MBit Ethernet-Verbindung ist (vermutlich eher 100Mbit) - da müssten dann theoretisch max 1260KB/s möglich sein, bei 100MBit entsprechend 12,5MB/s - aber natürlich muss diese kleine CPU die Daten ja auch noch bereit stellen.

-------------------

Mein Stand im Moment ist, dass ich mit TUSEND=1472Bytes und Ob35=2ms aktuell konsistent 736KB/s aus der CPU in den PC bekomme - mir reichen aber schon 100KB/s zu glücklich sein

VG, Jürgen

 

[Heinileini]

Moin Jürgen!

Es ist sicherlich gut, wenn man die theoretischen Grenzen alle kennt.
Nicht nur, um das Maximum herauskitzeln zu können, sondern auch - normalerweise - um "reichlich" Reserve für eine unvorhergesehene Häufung "widriger Umstände" bereitzustellen.

"WerkzeugÜberwachung" mit einer Aktualität von 10 ms? Willst Du die LeistungsAufnahme des SpindelAntriebs überwachen?
WZ-BruchErkennung oder "adaptive Control"? Musst Du die Messwerte dann noch glätten, damit sie aussagekräftig werden?
Das könnte man in die PLC verlagern …
Wie viele Daten (Bytes) benötigst Du wirklich im 10-ms-Takt? Könnte mir vorstellen, dass viele der Daten, die Du benötigst, sich in einem viel langsameren Takt bzw. gar nicht in irgendeinen Takt, sondern "sporadisch" ändern und nur "bei Bedarf" - also bei einer Änderung - gesendet werden müssen.
Wäre das ein Ansatz, 2 "TelegrammTypen" bzw. 2 DatenSatzTypen, einen für schnelle und einen für langsame Änderungen einzuplanen? Wäre mehr Aufwand im PLC-Programm, aber - zumindest im Durchschnitt - weniger ByteSchaufelei auf der Schnittstelle und weniger "DatenMüll".

Dient der Aufwand für "ForschungsZwecke" beim BAZ-Hersteller oder soll damit beim Anwender des BAZ etwas bewirkt werden?

Gruss, Heinileini

PS:
Senden bei jedem zweiten Aufruf des SendeBausteins war wohl etwas zu hoch gegriffen.
Bei jedem dritten (oder seltener) dürfte eher passen:
- einen oder mehrere, um "done" abzuwarten/aufzuschnappen, und ggfs das TriggerSignal wegzunehmen
- einen, um das rückgesetzte TriggerSignal an den SendeBaustein zu übergeben
- einen, um das wieder gesetzte TriggerSignal an den SendeBaustein zu übergeben

 

[Clyde82]

Hi,

da was Harald schreibt wollte ich auch gerade sagen. Wenn du im Zyklus X den Sendeanstoß bringt wird erst im Zyklus X+1 das done gesetzt, heißt du musst entweder alle 5ms den Aufruf starten, das done sofort nach dem Aufruf setzen oder einen 2ten Weckalarm mit vllt. etwas Phasenverschiebung verwenden um das DONE ich sag mal bei X+1/2 abzurufen.

mfg Clyde

 

[Need4Speed]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Clyde,

sprint aus deiner Sicht was dagegen, den BSEND oder TSEND (oder TUSEND) 2x direkt hintereinander aufzurufen? Beim ersten Aufruf immer mit "_REQ:=FALSE". Dieser erste Aufruf dient für mich dazu, den Status bzw. ERROR bzw. DONE abzufragen - ausserdem hat es den schönen Nebeneffekt, dass die Flanke "gelöscht" wird (REQ = TRUE vom vorigen Aufruf). Nur falls DONE = TRUE und ERROR = FALSE, dann stosse ich den Sendeauftrag an.

Was hälst du davon?

VG, Jürgen

 

[PN/DP]

DONE kann man nicht setzen, weil das ist ein Ausgang von BSEND.
Der Ausgang DONE kann durchaus schon sofort beim ersten Aufruf gesetzt sein - bzw. muß sogar, sonst hätte man gar keine Chance für senden in jedem Zyklus bzw. bei jedem zweiten BSEND-Aufruf.
Das 2x hintereinander aufrufen des BSEND braucht man weniger für Statusabfragen sondern um die Flankenerkennung des REQ vom BSEND zu befriedigen, damit der nächste Aufruf mit REQ=1 (im nächsten Zyklus) direkt wieder ein Sendeanstoss ist.

Harald

 

[Heinileini]

… oder einen 2ten Weckalarm mit vllt. etwas Phasenverschiebung verwenden um das DONE ich sag mal bei X+1/2 abzurufen.

Einen 2. WeckAlarm mit gleicher Frequenz und Phasenverschiebung?

Man nehme einen WeckAlarm mit doppelter Frequenz und einen "HilfsMerker", der bei jedem Aufruf des OB "umgeknipst" wird (z.B. per XOR).
Über diesen "HilfsMerker" bewirkt man dann, dass abwechselnd einer von zwei SendeBausteinAufrufen durchlaufen wird.
Also z.B. alle 5 ms ein BausteinAufruf, jedoch nur alle 10 ms Senden starten und ebenfalls alle 10 ms - aber um 5 ms versetzt - die o.g. "VerschnaufPause" mit rückgesetztem TriggerSignal.

 

[Need4Speed]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Harald,

DONE kann man nicht setzen, weil das ist ein Ausgang von BSEND.

Das verstehe ich - mein Beitrag oben meinte auch, dass ich den {B|T|TU}SEND mit REQ:=FALSE aufrufe um a) wegen (dein guter Hinweis!)
der Flankenerkennung, aber b) halt auch um zu prüfen ob der Sende-FB bereit ist (DONE auch TRUE) ist bzw. kein Fehler (ERROR ist FALSE).

Am besten wäre vermutlich zu prüfen, ob DONE gleich TRUE und ERROR und BUSY jeweils FALSE sind, dann sollte der FB auf jeden Fall wieder bereit für den nächsten Sendeauftrag sein.

Der Ausgang DONE kann durchaus schon sofort beim ersten Aufruf gesetzt sein - bzw. muß sogar, sonst hätte man gar keine Chance für senden in jedem Zyklus bzw. bei jedem zweiten BSEND-Aufruf.
Das 2x hintereinander aufrufen des BSEND braucht man weniger für Statusabfragen sondern um die Flankenerkennung des REQ vom BSEND zu befriedigen, damit der nächste Aufruf mit REQ=1 (im nächsten Zyklus) direkt wieder ein Sendeanstoss ist.
Harald

100% ack


VG, Jürgen

 

[Heinileini]

Moin Jürgen!

Dieser Thread hat angefangen, "unübersichtlich" zu werden.
Für mein Verständnis sind noch 3 Fragen offen bzw. noch nicht klar genug beantwortet bzw. noch nicht klar genug gestellt.
1. Deine Frage, ob man den SendeBaustein (oder allgemeiner irgendeinen Baustein) mehrfach im selben Zyklus aufrufen kann bzw. darf.
2. Unsere Frage, wie der Stand der Dinge bei Dir jetzt ist - kommst Du nun klar oder gibt es noch "KlärungsBedarf" und wenn ja, welchen?
3. Was soll passieren, wenn der SendeBaustein meldet "Fertig, aber mit Fehler"?

Zu Frage 1: Grundsätzlich ja. Manchmal - in "extremen" Fällen - ist es sogar nötig. Siehe Deinen AnwendungsFall.

Zu Frage 3: Für mein Verständnis ist die Unterscheidung, ob fertig mit Fehler oder fertig ohne Fehler für Dein PLC-Programm unerheblich. Es sei denn, Du möchtest davon eine Fehlermeldung ableiten.
Mit dem ZeitStempel hast Du vorgesorgt, dass der Empfänger "Unregelmässigkeiten" feststellen kann.

Gruss, Heinileini

 

[Need4Speed]

Hallo Heinileini,

Moin Jürgen!

Dieser Thread hat angefangen, "unübersichtlich" zu werden.
Für mein Verständnis sind noch 3 Fragen offen bzw. noch nicht klar genug beantwortet bzw. noch nicht klar genug gestellt.
1. Deine Frage, ob man den SendeBaustein (oder allgemeiner irgendeinen Baustein) mehrfach im selben Zyklus aufrufen kann bzw. darf.
2. Unsere Frage, wie der Stand der Dinge bei Dir jetzt ist - kommst Du nun klar oder gibt es noch "KlärungsBedarf" und wenn ja, welchen?
3. Was soll passieren, wenn der SendeBaustein meldet "Fertig, aber mit Fehler"?

Zu Frage 1: Grundsätzlich ja. Manchmal - in "extremen" Fällen - ist es sogar nötig. Siehe Deinen AnwendungsFall.

Zu Frage 3: Für mein Verständnis ist die Unterscheidung, ob fertig mit Fehler oder fertig ohne Fehler für Dein PLC-Programm unerheblich. Es sei denn, Du möchtest davon eine Fehlermeldung ableiten.
Mit dem ZeitStempel hast Du vorgesorgt, dass der Empfänger "Unregelmässigkeiten" feststellen kann.

Gruss, Heinileini

Sorry, dass ich diese Woche so ruhig war, aber wie so oft ist "no news = good news", also in dem Sinne, dass es soweit ganz gut läuft.

zu 1. - genau, Aufruf 1x zum Rücksetzen der Flanke und ermitteln von BUSY/DONE/ERROR, und dann nochmal um einen neuen Auftrag anzustossen
zu 3. wenn es einen Fehler gibt, dann bisher nur, wenn die Verbindung nicht mehr aktiv ist - dann springe ich zum Aufruf von TDISCON und anschliessend TCON - dann geht es wieder (passiert z.B. beim Warmstart - könnte/sollte man vermutlich im OB100 lösen - aber der Verlust von ein paar Datenpaketen nach dem Wiederanlauf ist in meinem Fall nicht so dramatisch)

zu 2. - ich habe mich für den TUSEND im OB35 bei 10ms entschieden - das klappt soweit, weil TUSEND (UDP) sehr schnell ist. Leider kommt es (aktuell) alle paar Sekunden vor, dass ein paar Datenpakete verloren gehen (ich muss noch herausfinden ob a) tatsächlich UDP Pakete verloren gehen, oder ob der TUSEND ab und zu noch BUSY ist (WAIT), weil b) auf dem PROFINET anderen Daten Priorität haben) - das versuche ich diese Woche noch zu machen.

Was für mich jetzt noch offen ist: in der HW Konfiguration des PROFINET kann man ja den Anteil der PROFINET Kommunikation 100% auf 87.5% herunter setzten (und noch BuB Kommunikation aktivieren) - diese beiden Ansätze versuche ich jetzt noch zu testen.

An der Stelle allen Foristen hier vielen Dank - ich habe eine Menge gelernt und bin fast am Ziel!!

VG, Jürgen

 

[Need4Speed]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Heinileini,

"WerkzeugÜberwachung" mit einer Aktualität von 10 ms? Willst Du die LeistungsAufnahme des SpindelAntriebs überwachen?
WZ-BruchErkennung oder "adaptive Control"? Musst Du die Messwerte dann noch glätten, damit sie aussagekräftig werden?
Das könnte man in die PLC verlagern …

Genau, wir brauchen hier die aktuelle Drehzahl, Lage & Position, Drehmoment (aus der Leistungsaufnahme), und Temperatur. Durch die (hoffentlich) äquidistante Messung entfällt das Glätten hoffentlich und wir können die Zeitreihen direkt in die Algorithmik füttern bzw. im Nachgang diverse Signalverarbeitungsmethoden zur Rauschunterdrückung und zum Ableiten von Merkmalen anwenden.

Wie viele Daten (Bytes) benötigst Du wirklich im 10-ms-Takt? Könnte mir vorstellen, dass viele der Daten, die Du benötigst, sich in einem viel langsameren Takt bzw. gar nicht in irgendeinen Takt, sondern "sporadisch" ändern und nur "bei Bedarf" - also bei einer Änderung - gesendet werden müssen.
Wäre das ein Ansatz, 2 "TelegrammTypen" bzw. 2 DatenSatzTypen, einen für schnelle und einen für langsame Änderungen einzuplanen? Wäre mehr Aufwand im PLC-Programm, aber - zumindest im Durchschnitt - weniger ByteSchaufelei auf der Schnittstelle und weniger "DatenMüll".

Den "Datenmüll" würden wir dann im Datenlogger "entsorgen"; aber erst mal möchte ich schon alles haben. Da es hier ja vor allem um eine BAZ bzw SINUMERIK/NCU geht und das PN nicht so umfangreich ist, hoffe ich, dass wir wirklich alle Daten über PN abgreifen können. Falls nicht, müssen wir in Richtung Service-Schnittstelle (X127, etc.) überlegen.

Dient der Aufwand für "ForschungsZwecke" beim BAZ-Hersteller oder soll damit beim Anwender des BAZ etwas bewirkt werden?

Wir arbeiten mit einem Hersteller und einem Anwender/OEM, und es soll damit wirklich was bewirkt werden - konkret geht es allerdings weniger um die Werkzeugüberwachung, sondern vielmehr darum, die Qualität der Bearbeitung (Prozessfestigkeit sozusagen) zu dokumentieren, überwachen und ggf. Massnahmen zu ergreifen.

Die Analysen die wir hier machen sind im Bereich der multivariaten statistischen Methoden im Kontext von "machine learning" mit big data, also viele Bearbeitungsvorgänge anlernen und dann Anomalien zu erkennen. Diese sprengen natürlich die Rechenkapazitäten einer SIMATIC CPU und müssen erst mal out-of-band (Serververbund) gerechnet werden; aber wenn dann mal klar ist, welches Verfahren die besten Ergebnisse liefert, dann soll es in der Tat wieder näher an die Maschine oder sogar in die PLC.

Falls du mehr wissen möchtest ---> PM bitte.

VG, Jürgen

 

[Heinileini]

@Jürgen
Wenn ich Dich richtig verstanden habe, hängt sich Dein Senden auf, sobald eine SendeAktion mal nicht innerhalb der geforderten 10 ms fertig wird.
Um zum "regulären" Betrieb zurückkehren zu können, müsstest Du aber in der PLC den FehlerZustand erkennen können.
Ich denke, ich würde das Thema genau so angehen, wie Du es schreibst.
Alle 10 ms OB 35 durchlaufen und dort
zuerst den SendeBaustein mit REQ=False aurufen,
dann die Rückmeldungen des Bausteins auswerten bzw. abspeichern und
dann den SendeBaustein mit REQ=True aufrufen (unabhängig davon, ob der SendeVorgang mit oder ohne Fehler oder überhaupt fertig geworden ist).
Nach dem Aufruf mit REQ=True bleiben bis zum Aufruf mit REQ=False knappe 10 ms für das Senden bis zum erneuten Starten des Senden.
Tritt ein Fehler auf, so dass Du den nächsten SendeAuftrag nicht nach 10 ms starten kannst, so ist es eh zu spät, um irgendwie korrigierend eingreifen zu können.
In diesem (hoffentlich seltenen) Fall dann nach der TDISCON/TCON-Prozedur wieder wie gehabt. OB 100? Weiss ich nicht. Ich tendiere eher dazu alles im OB 35 "zusammenzuhalten".
Gruss, Heinileini