TIA Ausgangssignale ändert sich nur bei zweitem "Anstoss"

M

MFreiberger

Level-3
Beiträge
3.275
Reaktionspunkte
923
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Zusammen,

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

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.

Code: 
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. :eek:

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!"
Zum Vergrößern anklicken....

VG

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.
 
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
 
Matze001 schrieb:
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
Zum Vergrößern anklicken....
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
 
Weiteres:

Das funktioniert:
Code: 
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:
Code: 
"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 :(
 
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?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Matze001 schrieb:
Weil "RBG1_DATA_DB".CTRLtoRBG_DRtoggleTELE im nicht funktionierenden Teil nie von Dir beschrieben wird...
Zum Vergrößern anklicken....
doch, wird beschrieben, allerdings zyklisch und nicht nur bei "IF = true":
MFreiberger schrieb:
Das funktioniert nicht:
Code: 
"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;
Zum Vergrößern anklicken....
Matze001 schrieb:
es gibt bei dir:

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

Vielleicht etwas unübersichtlich beschriftet?
Zum Vergrößern anklicken....
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.
 
MFreiberger schrieb:
doch, wird beschrieben, allerdings zyklisch und nicht nur bei "IF = true":
Zum Vergrößern anklicken....
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;
Zum Vergrößern anklicken....


Edit... ohje... ganz oben... Kopfschmerzen ... sorry
 
Matze001 schrieb:
Edit... ohje... ganz oben... Kopfschmerzen ... sorry
Zum Vergrößern anklicken....
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.
 
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?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
MFreiberger schrieb:
Hier nochmal zwei Screenshots zu dem Fall:


Funktioniert:

Anhang anzeigen 63120




Funktioniert nicht:

Anhang anzeigen 63121
Zum Vergrößern anklicken....
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.
 
koderko schrieb:
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).
Zum Vergrößern anklicken....
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.
 
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.
 
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

Code: 
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 ;
 
Zuletzt bearbeitet:
Moin Heinrich,

Heinileini schrieb:
womit willst Du das Togglen triggern?
Zum Vergrößern anklicken....
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.

Heinileini schrieb:
Soll der Zustand des ToggleBits wirklich in jedem Zyklus geändert werden?
Zum Vergrößern anklicken....
Nein. s.o.

Heinileini schrieb:
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.
Zum Vergrößern anklicken....
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).

Heinileini schrieb:
Das von Dir beschriebene Verhalten ist sehr, sehr merkwürdig.
Zum Vergrößern anklicken....
ja

Heinileini schrieb:
Rufst Du Deinen Code im OB1-Zyklus auf?
Zum Vergrößern anklicken....
ja

Heinileini schrieb:
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?
Zum Vergrößern anklicken....
Nein, das kann ich durch die Abfrage der rückgemeldeten Bits in der Gegenseite ausschließen.

Heinileini schrieb:
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.
Zum Vergrößern anklicken....
Schon probiert. Die Signalzustände werden sauber übertragen. Das Ausgangsbit wird auch nicht nochmals überschrieben (auch nicht die ganze übergeordnete Struktur).

Heinileini schrieb:
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.
Zum Vergrößern anklicken....
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.

Heinileini schrieb:
Gruss, Heinileini

Code: 
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 ;
Zum Vergrößern anklicken....
 
MFreiberger schrieb:
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.
Zum Vergrößern anklicken....
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.
MFreiberger schrieb:
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, ...).
Zum Vergrößern anklicken....
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?
MFreiberger schrieb:
Deshalb ist meine Vermutung, dass es was mit der iDEVICE-Kommunikation zu tun hat (SR bei SIEMENS ist schon angetrossen).
Zum Vergrößern anklicken....
Beide WatchDogs laufen doch über die iDevice-Kommunikation? Oder nur die eine der beiden Richtungen bzw. der eine der beiden WatchDogs?
MFreiberger schrieb:
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).
Zum Vergrößern anklicken....
(y)
MFreiberger schrieb:
Deshalb mache ich es auch nicht so. Das Toggeln, das die Verbindung prüft realisiere ich nicht mit zyklischen oder getakteten Triggern.
Zum Vergrößern anklicken....
:unsure: 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.
MFreiberger schrieb:
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.
Zum Vergrößern anklicken....
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?
 

Similar threads

P
Hilfe bei Bool Array vergleichen
2
Antworten
20
Aufrufe
9K
Rob1337
R
F
TIA Bereichslängen Fehler bei RFID FB
Antworten
0
Aufrufe
3K
FelixL
F
T
TIA Wörter werden vom FU nur teilweise richtig übersendet
Antworten
13
Aufrufe
4K
TaHan
T
P
CodeSys 3.5 / Raspberry / Socket-Connection auf Wärmepumpe
Antworten
5
Aufrufe
6K
philipp75
P
T
TIA Bereichslängenfehler SCL
Antworten
3
Aufrufe
4K
gravieren
G
Zurück
Oben