TIA Ausgangssignale ändert sich nur bei zweitem "Anstoss"

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Zusammen,

irgendwie sehe ich grade die Ursache meines Problems nicht. Hoffentlich könnt ihr meinen Gedankenfehler eleminieren

Eckdaten:
Programmierumgebung: TIA V16 Upd 6
zwei Steuerungen:
1. 1515F-2 PN V2.8 515-2FM01-0AB0
2. 1515F-2 PN V2.9 515-2FM02-0AB0

Die Steuerungen sind über iDevice (1. Steuerung ist Device; 2. Steuerung ist Controller) gekoppelt.
Zur Prüfung der Kommunikation habe ich ein toggle-Bit vorgesehen.

Das Schreiben des ausgehenden toggle-Bits in der Steuerung 2 funktioniert nicht so, wie ich mir das vorstelle.

IF
    "STAWfromRBG1".ND_toggle_TELE <> "RBG1_DATA_DB".ND_toggleMem_TELE
THEN
    "RBG1_DATA_DB".ND_toggleMem_TELE := "STAWfromRBG1".ND_toggle_TELE;
    
    // Zur Signalprüfung
    //
    // "CTRLtoRBG1".DR_toggle_TELE :=
    // "CTRLtoRBG1".DR_toggle_TELE;
    
    
    // Signaltoggle 1
    //
    // "CTRLtoRBG1".DR_toggle_TELE :=
    // NOT "CTRLtoRBG1".DR_toggle_TELE;
    
    // "CTRLtoRBG1".DR_toggle_TELE :=
    // NOT "CTRLtoRBG1".DR_toggle_TELE;
    
    
    // Signaltoggle 2
    IF
        "CTRLtoRBG1".DR_toggle_TELE
    THEN
        "CTRLtoRBG1".DR_toggle_TELE := false;
    ELSE
        "CTRLtoRBG1".DR_toggle_TELE := true;
    END_IF;
    
    IF
        "CTRLtoRBG1".DR_toggle_TELE
    THEN
        "CTRLtoRBG1".DR_toggle_TELE := false;
    ELSE
        "CTRLtoRBG1".DR_toggle_TELE := true;
    END_IF;
END_IF;

// Signalprüfung 2

"CTRLtoRBG1".DR_toggle_TELE := "CTRLtoRBG1".DR_toggle_TELE;

Das toggeln des Bits funktioniert sowohl bei "Signaltoggle 1", als auch bei "Signaltoggle 2".
ABER: in beiden Fällen nur, wenn ich das Toggeln (manche werden sich schon bzgl. des Codes gewundert haben) doppelt programmiere.

Die IF-Abfrage (Signaltoggle 2) habe ich tatsächlich nur versuchsweise programmiert, macht aber natürlich das gleiche, wie die einfache Zuweisung (Signaltoggle 1). Aber in beiden Fällen muss ich die Codezeilen doppelt programmieren. Wahrscheinlich bin ich einfach nur zu dösig, um die Ursache zu finden. Programm komplett überzetzen/laden habe ich schon gemacht.

Wer kann den Finger in die Wunde legen und mir schnell sagen, warum es nicht funktioniert?

Armin Maiwald: "Ist doch klar!"

VG

MFreiberger

 

[Ralle]

"CTRLtoRBG1".DR_toggle_TELE ist ein iDevice-Output an das andere lDevice?
Ich würde mal testweise ein internes DB-Bit aus der eigenen Steuerung toggeln und am Ende dieses Bit dem Ausgang zuweisen also nicht direkt den Ausgang toggeln.

 

[Matze001]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich hab es grad mit brummen im Kopf gelesen, und nicht wirklich verstehen wollen (Habe Kopfschmerzen, aber externe Ursache...)

Meiner Meinung nach gibt es auf der zweiten Seite 3 Ansätze wie man arbeiten kann:

1. Man spiegelt das Togglebit einfach 1:1 ... immer
"RBG1_DATA_DB".ND_toggleMem_TELE := "STAWfromRBG1".ND_toggle_TELE;

2. Man spiegelt es invertiert:
"RBG1_DATA_DB".ND_toggleMem_TELE := NOT "STAWfromRBG1".ND_toggle_TELE;

3. Man erzeugt ein eigenes unabhängiges Tooglebit (z.B. Blinktakt)

Grüße

Marcel

 

[MFreiberger]

"CTRLtoRBG1".DR_toggle_TELE ist ein iDevice-Output an das andere lDevice?
Ich würde mal testweise ein internes DB-Bit aus der eigenen Steuerung toggeln und am Ende dieses Bit dem Ausgang zuweisen also nicht direkt den Ausgang toggeln.

auch schon versucht

 

[MFreiberger]

Ich hab es grad mit brummen im Kopf gelesen, und nicht wirklich verstehen wollen (Habe Kopfschmerzen, aber externe Ursache...)

Meiner Meinung nach gibt es auf der zweiten Seite 3 Ansätze wie man arbeiten kann:

1. Man spiegelt das Togglebit einfach 1:1 ... immer
"RBG1_DATA_DB".ND_toggleMem_TELE := "STAWfromRBG1".ND_toggle_TELE;

2. Man spiegelt es invertiert:
"RBG1_DATA_DB".ND_toggleMem_TELE := NOT "STAWfromRBG1".ND_toggle_TELE;

3. Man erzeugt ein eigenes unabhängiges Tooglebit (z.B. Blinktakt)

Grüße

Marcel

Ja, die Funktion eines ToggleBits ist mir klar.

Mein Problem ist, dass (anscheinend) das Invertieren eines Bits nicht beim ersten Befehl funktioniert, sondern, dass ich noch mal drohen muss, damit es tut, was ich will.

VG

MFreiberger

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hier nochmal zwei Screenshots zu dem Fall:


Funktioniert:






Funktioniert nicht:

 

[MFreiberger]

Weiteres:

Das funktioniert:

IF
    "STAWfromRBG1".ND_toggle_TELE <> "RBG1_DATA_DB".ND_toggleMem_TELE
THEN
    "RBG1_DATA_DB".ND_toggleMem_TELE := "STAWfromRBG1".ND_toggle_TELE;
    
  
    "RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE :=
    "CTRLtoRBG1".DR_toggle_TELE;
    
    "RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE :=
    NOT "RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE;
    
END_IF;

"CTRLtoRBG1".DR_toggle_TELE :=
"RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE;

Das funktioniert nicht:

"RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE :=
"CTRLtoRBG1".DR_toggle_TELE;

IF
    "STAWfromRBG1".ND_toggle_TELE <> "RBG1_DATA_DB".ND_toggleMem_TELE
THEN
    "RBG1_DATA_DB".ND_toggleMem_TELE := "STAWfromRBG1".ND_toggle_TELE;
    
    "RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE :=
    NOT "RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE;
    
END_IF;

"CTRLtoRBG1".DR_toggle_TELE :=
"RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE;

Also, wenn ich die Abfrage nicht direkt vor der Signaländerung programmiere, funktioniert es nicht. Und zwar wiedreholbar! Nicht, dass es mal geht, mal nicht, weil irgend ein Interrupt dazwischengrätscht.

I.M. stehe ich etwas auf dem Schlauch

 

[Matze001]

Weil "RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE im nicht funktionierenden Teil nie von Dir beschrieben wird...

es gibt bei dir:

"CTRLtoRBG1".DR_toggle_TELE
"RBG1_DATA_DB".ND_toggleMem_TELE
"RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE

Vielleicht etwas unübersichtlich beschriftet?

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Weil "RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE im nicht funktionierenden Teil nie von Dir beschrieben wird...

doch, wird beschrieben, allerdings zyklisch und nicht nur bei "IF = true":

Das funktioniert nicht:

"RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE :=
"CTRLtoRBG1".DR_toggle_TELE;

IF
    "STAWfromRBG1".ND_toggle_TELE <> "RBG1_DATA_DB".ND_toggleMem_TELE
THEN
    "RBG1_DATA_DB".ND_toggleMem_TELE := "STAWfromRBG1".ND_toggle_TELE;
  
    "RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE :=
    NOT "RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE;
  
END_IF;

"CTRLtoRBG1".DR_toggle_TELE :=
"RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE;

es gibt bei dir:

"CTRLtoRBG1".DR_toggle_TELE
"RBG1_DATA_DB".ND_toggleMem_TELE
"RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE

Vielleicht etwas unübersichtlich beschriftet?

Vielleicht.
Aber:
- "RBG1_DATA_DB".ND_toggleMem_TELE
=> hat mit der Problemstellung nichts zu tun, sondern triggert nur die Funktionalität.

- "CTRLtoRBG1".DR_toggle_TELE
=> ist die Bezeichnung des Ausgangs in der iDevice-Kommunikation

- "RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE
=> ist nur zum testen da und die Bezeichnung soll zeigen, dass hier der Inhalt der Ausgangsvariablen zwischengespeichert wird.

 

[Matze001]

doch, wird beschrieben, allerdings zyklisch und nicht nur bei "IF = true":

Wo? Ich sehe, dass es 2 mal gelesen wird... aber nie geschrieben.

"RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE :=
"CTRLtoRBG1".DR_toggle_TELE;

IF
"STAWfromRBG1".ND_toggle_TELE <> "RBG1_DATA_DB".ND_toggleMem_TELE
THEN
"RBG1_DATA_DB".ND_toggleMem_TELE := "STAWfromRBG1".ND_toggle_TELE;

"RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE :=
NOT "RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE;

END_IF;

"CTRLtoRBG1".DR_toggle_TELE :=
"RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE;

Edit... ohje... ganz oben... Kopfschmerzen ... sorry

 

[MFreiberger]

Edit... ohje... ganz oben... Kopfschmerzen ... sorry

Alles gut. Ich hänge (vor Allem wegen dem Wetter (Hitze)) auch etwas in der Uhr.

Noch zur Variablenbezeichnung:
Eigentlich erscheint mir die Variablenbezeichnung gar nicht so unübersichtlich. Für mich ist es sehr wichtig, dass die Variablen möglichst genau zeigen, wofür sie da sind. Ich muss hier zu einem PC und vier unterlagerten Steuerungen kommunizieren. Alles Telegrammverkehr mit Quittierungen. Und dann noch während des RetroFits Umschalten von einzelnen Verbindungen von einer Steuerung in andere Steuerungen. Da nehme ich ein wenig(!) Unübersichtlichkeit zugunsten von exakten Bezeichnungen in Kauf.

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wo? Ich sehe, dass es 2 mal gelesen wird... aber nie geschrieben.

Edit... ohje... ganz oben... Kopfschmerzen ... sorry

Ja, das wollte ich gerne rot markieren. Aber irgendwie hat das im Zitat nicht funktioniert.

 

[Ralle]

Mach das mal komplett ohne iDevice-E/A, also einfach mit ein paar DB-Bits.
Du liest ja einen iDevice-Ausgang und schreibst den dann wieder.
Vielleicht geht das gerade bei iDevice so nicht oder du hast gar einen Bug gefunden. Normalerweise warnt ja TIA immer vor dem Lesen von Outputs, speziell natürlich bei FB/FC, aber iDevice mag da auch speziell sein?

 

[MFreiberger]

Ich werde nochmal testen. Aber heute nicht mehr. Dazu muss ich frisch sein. Es wird mir gerade zu heiß

 

[koderko]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hier nochmal zwei Screenshots zu dem Fall:


Funktioniert:

Anhang anzeigen 63120




Funktioniert nicht:

Anhang anzeigen 63121

Moment...deine "Signalprüfung 2" gibt in beiden Fällen den wirklichen Zustand der Variable "CTRLtoRBG1"DR_toggle_TELE aus (deshalb ist das "TRUE" auch schwarz).

Die Istwerte der Variablen innerhalb des If-Konstrukts sind grau, das heißt, das sind die Zustände, die vorgeherrscht hatten zu dem Zeitpunkt, als deine If-Abfrage durchlaufen wurde. In genau diesem Zyklus wäre auch deine "Signalprüfung 2" "false" gewesen. Anscheinend gibt es aber noch einen schreibenden Zugriff auf "CTRLtoRBG1"DR_toggle_TELE, der dir die Variable sofort wieder auf "true" setzt.

Für mich sehen beide Szenarien aus, als würden sie funktionieren. Im ersten Screenshot "funktioniert" ist die Variable beim Eintritt in das If-Konstrukt nicht gesetzt, daher setzt du sie und setzt sie sofort wieder zurück.
Bei zweiten Screenshot "funktioniert nicht" ist die Variable beim Eintritt gesetzt, deshalb setzt du sie zurück.

 

[Ralle]

Moment...deine "Signalprüfung 2" gibt in beiden Fällen den wirklichen Zustand der Variable "CTRLtoRBG1"DR_toggle_TELE aus (deshalb ist das "TRUE" auch schwarz).

Wenn die oberste If-Abfrage korrekt ist, passiert genau ein Durchlauf und dann sieht man genau das, was bei diesem Durchlauf passiert ist "hellgrau". Das ist natürlich zum Zeitpunkt des Screenshots nicht mehr aktiv.
Aber ich denke, das ist nicht das Problem.

 

[koderko]

Genau, und diese hellgrauen Werte passen doch. Das Programm hat in beiden Fällen genau das gemacht, was es hat machen sollen.
Klar, das schwarze "TRUE" passt nicht zu den jeweils rot eingekästelten "FALSE", aber auch nur deswegen, weil das innerhalb des If-Konstrukts ein einmaliger Aufruf war, das was außerhalb passiert, passiert in jedem Zyklus.
Daher immer noch meine Vermutung, dass es einen weiteren Schreibzugriff auf "CTRLtoRBG1".DR_toggle_TELE gibt, der diese Variable wieder auf True setzt.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin Mario,

womit willst Du das Togglen triggern? Soll der Zustand des ToggleBits wirklich in jedem Zyklus geändert werden?
Ich hätte erwartet, dass das Bit nur dann umgeschaltet wird, wenn erkennbar wird, dass die "Gegenseite" die letzte Änderung empfangen und zurückgemeldet hat.
Eine Flanke dieser Rückmeldung sollte zum Togglen führen.

Das von Dir beschriebene Verhalten ist sehr, sehr merkwürdig.
Rufst Du Deinen Code im OB1-Zyklus auf?
Ich verstehe weder, warum es beim "einfachen" Togglen nicht funktioniert, noch, warum es beim doppelt gemoppelten Togglen doch togglet.
Ist es das Problem, dass die Anzeige und das menschliche Sehen zu langsam sind, um eine klare Ansicht zu erreichen?
Quasi ein StroboskopEffekt, der Unsinn vorgaukelt?
Ich würde vor der Toggelei die ToggleVariable testweise fest auf TRUE bzw. FALSE legen. Dann müsste man doch auf jeden Fall eine "ruhige" Anzeige beobachten können.
Und weiterhin den Zustand der ToggleVariable vor dem Festnageln auf TRUE bzw. FALSE beobachten! Vielleicht wird sie ja doch irgendwo überschrieben.

Falls Du wirklich in jedem Zyklus das Bit umschalten willst, ist das denn nicht viel zu "sportlich"? Hat die Gegenseite eine reproduzierbare Chance, das Bit rechtzeitig zu spiegeln oder invertiert zurückzuschicken? Und hat die togglende SPS eine reproduzierbare Chance, richtig zu reagieren?
Ist die ZyklusZeit der Gegenseite denn so viel kürzer als die ZyklusZeit der togglenden Seite?
Ich glaube nicht so recht daran.

Gruss, Heinileini

VAR_INPUT
    iRückMldg : BOOL ; // RückMldg des von anderer SPS gespiegelten (negierten?) Bits
END_VAR ; 

VAR_IN_OUT
    ioToggle  : BOOL ; // Ausgabe des ToggleBits an "static" und an andere SPS
END_VAR ;

VAR_TEMP
    tToggle   : BOOL ; // Kopie des eingelesenen ToggleBits
    tTrigger  : BOOL ; // TriggerBit zum Toggeln UND zum TOF starten
END_VAR ;

tToggle  := ioToggle ;
tTrigger := tToggle XOR NOT iRückMldg ; // NOT entfällt, wenn das Signal negiert zurück kommt
                                        // mit tTrigger ausserdem einen TOF triggern! ("TimeOut")
ioToggle := tToggle XOR tTrigger ;

 

[MFreiberger]

Moin Heinrich,

womit willst Du das Togglen triggern?

Das Toggeln wird mit dem Empfang eines Bits getriggert (ND steht für NewData). Also, wenn neue Daten bereit stehen, wird ND getoggelt. Durch das Toggeln von ND soll dan DR (DataRead) getoggelt werden, damit die Gegenseite weiß, dass die Daten gelesen wurden.

Soll der Zustand des ToggleBits wirklich in jedem Zyklus geändert werden?

Nein. s.o.

Ich hätte erwartet, dass das Bit nur dann umgeschaltet wird, wenn erkennbar wird, dass die "Gegenseite" die letzte Änderung empfangen und zurückgemeldet hat.
Eine Flanke dieser Rückmeldung sollte zum Togglen führen.

So ist es gedacht. BTW: in der "Gegenrichtung" (also Device/Controller getauscht) funktioniert es genau so. Diesen Kommunikationsweg habe ich zuerst programmiert inkl. Timeout und wiederantriggern, wenn irgend ein Bit hängen bleibt. Das funktioniert tadellos und robust (z.B. bei Verbindungsunterbrechungen, ...).
Deshalb ist meine Vermutung, dass es was mit der iDEVICE-Kommunikation zu tun hat (SR bei SIEMENS ist schon angetrossen).

Das von Dir beschriebene Verhalten ist sehr, sehr merkwürdig.

ja

Rufst Du Deinen Code im OB1-Zyklus auf?

ja

Ich verstehe weder, warum es beim "einfachen" Togglen nicht funktioniert, noch, warum es beim doppelt gemoppelten Togglen doch togglet.
Ist es das Problem, dass die Anzeige und das menschliche Sehen zu langsam sind, um eine klare Ansicht zu erreichen?
Quasi ein StroboskopEffekt, der Unsinn vorgaukelt?

Nein, das kann ich durch die Abfrage der rückgemeldeten Bits in der Gegenseite ausschließen.

Ich würde vor der Toggelei die ToggleVariable testweise fest auf TRUE bzw. FALSE legen. Dann müsste man doch auf jeden Fall eine "ruhige" Anzeige beobachten können.
Und weiterhin den Zustand der ToggleVariable vor dem Festnageln auf TRUE bzw. FALSE beobachten! Vielleicht wird sie ja doch irgendwo überschrieben.

Schon probiert. Die Signalzustände werden sauber übertragen. Das Ausgangsbit wird auch nicht nochmals überschrieben (auch nicht die ganze übergeordnete Struktur).

Falls Du wirklich in jedem Zyklus das Bit umschalten willst, ist das denn nicht viel zu "sportlich"? Hat die Gegenseite eine reproduzierbare Chance, das Bit rechtzeitig zu spiegeln oder invertiert zurückzuschicken? Und hat die togglende SPS eine reproduzierbare Chance, richtig zu reagieren?
Ist die ZyklusZeit der Gegenseite denn so viel kürzer als die ZyklusZeit der togglenden Seite?
Ich glaube nicht so recht daran.

Deshalb mache ich es auch nicht so. Das Toggeln, das die Verbindung prüft realisiere ich nicht mit zyklischen oder getakteten Triggern.

Das machen wir so:
Wir definieren wer Server und wer Client ist.
Der Server empfängt ein ToggleBit vom Client und sendet den Zustand 1:1 zurück.
Der Client empfängt das ToggleBit und prüft, ob es mit dem übereinstimmt, was gesendet wurde.
- Ja: 1:!1 zurücksenden
- Nein: warten. Nach x Sekunden Timeout melden.

Das hatten wir ja schon einmal diskutiert. So kann ich sogar die Kommunikationslaufzeit messen (was ich auch tue!). Wenn ich kein Bit, sondern ein int nehme, könnte ich sogar die Anzahl senden/empfangen zählen. Da diese Überwachung ereingis- und nicht zeitgetriggert ist, kommt es auch nicht zu fehlerhaften Timeouts und es müssen keine Takte (Triggertakt, SPS-Zyklus, ...) aufeinander abgestimmt werden.

BTW: SEW stellt inzwischen bei jedem MoviC-Antrieb in den Prozessdaten auch ein ToggleBit zur Verfügung. Da ist der Umricht gewissermaßen Server, denn das empfangene Bit wird 1:1 zurückgesendet.

Gruss, Heinileini

VAR_INPUT
    iRückMldg : BOOL ; // RückMldg des von anderer SPS gespiegelten (negierten?) Bits
END_VAR ;

VAR_IN_OUT
    ioToggle  : BOOL ; // Ausgabe des ToggleBits an "static" und an andere SPS
END_VAR ;

VAR_TEMP
    tToggle   : BOOL ; // Kopie des eingelesenen ToggleBits
    tTrigger  : BOOL ; // TriggerBit zum Toggeln UND zum TOF starten
END_VAR ;

tToggle  := ioToggle ;
tTrigger := tToggle XOR NOT iRückMldg ; // NOT entfällt, wenn das Signal negiert zurück kommt
                                        // mit tTrigger ausserdem einen TOF triggern! ("TimeOut")
ioToggle := tToggle XOR tTrigger ;

 

[Heinileini]

Das Toggeln wird mit dem Empfang eines Bits getriggert (ND steht für NewData). Also, wenn neue Daten bereit stehen, wird ND getoggelt. Durch das Toggeln von ND soll dan DR (DataRead) getoggelt werden, damit die Gegenseite weiß, dass die Daten gelesen wurden.

Zweimal togglen? Das ND und dann das DR? Beim ND gibt's nix zu togglen! Die Flanke von ND ist der Trigger für das einmalige Togglen des DR.

BTW: in der "Gegenrichtung" (also Device/Controller getauscht) funktioniert es genau so. Diesen Kommunikationsweg habe ich zuerst programmiert inkl. Timeout und wiederantriggern, wenn irgend ein Bit hängen bleibt. Das funktioniert tadellos und robust (z.B. bei Verbindungsunterbrechungen, ...).

Du togglest also auf beiden Seiten und spiegelst jeweils das empfangene ToggleBit?
In Gegenrichtung genauso, wie in der hier behandelten Richtung? Und in Gegenrichtung funktioniert es tadellos und in der umgekehrten Richtung treten die Probleme reproduzierbar auf? Zwei getrennte (?!) Überwachungen dieser Art parallel?
Warum nicht, doppelt hält bekanntlich besser.
Und in beiden Richtungen läuft das wirklich getrennt voneinander ab? Oder gibt's da irgendwo einen TippFehler, so dass sich die Abläufe beider Richtungen überschneiden?

Deshalb ist meine Vermutung, dass es was mit der iDEVICE-Kommunikation zu tun hat (SR bei SIEMENS ist schon angetrossen).

Beide WatchDogs laufen doch über die iDevice-Kommunikation? Oder nur die eine der beiden Richtungen bzw. der eine der beiden WatchDogs?

Nein, das kann ich durch die Abfrage der rückgemeldeten Bits in der Gegenseite ausschließen.

Schon probiert. Die Signalzustände werden sauber übertragen. Das Ausgangsbit wird auch nicht nochmals überschrieben (auch nicht die ganze übergeordnete Struktur).

Deshalb mache ich es auch nicht so. Das Toggeln, das die Verbindung prüft realisiere ich nicht mit zyklischen oder getakteten Triggern.

Diese Aussage verstehe ich nicht wirklich. Vermutlich willst Du mir damit sagen, dass Du einen Handshake realisierst, so dass beide Seiten auf die (Re-)Aktion der jeweilegen Gegenseite warten und kein zeitlicher Rahmen dafür vorgegeben ist, der eingehalten werden müsste.
Eine Nicht-Reaktion wird "lediglich" durch den TimeOut überwacht.

Das hatten wir ja schon einmal diskutiert. So kann ich sogar die Kommunikationslaufzeit messen (was ich auch tue!). Wenn ich kein Bit, sondern ein int nehme, könnte ich sogar die Anzahl senden/empfangen zählen. Da diese Überwachung ereingis- und nicht zeitgetriggert ist, kommt es auch nicht zu fehlerhaften Timeouts und es müssen keine Takte (Triggertakt, SPS-Zyklus, ...) aufeinander abgestimmt werden.

Ereignisgetriggert? Ist eine AlarmBehandlung im Spiel (OB weiss-nicht-welcher)? Oder ist das eine Umschreibung dafür, dass Du im OB1-Zyklus
ein Polling eines Bits ausführst, also in jedem Zyklus einmal das Bit abfragst?
Was sagt denn Deine KommunikationsLaufzeitMessung zu den benötigten Zeiten?