TIA Ausgangssignale ändert sich nur bei zweitem "Anstoss"

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

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.

Das ND wird in der einen Steuerung getoggelt (jede Signaländerung zeigt an, dass neue Daten geschrieben wurden). Das DR wird in der anderen Steuerung getoggelt (hier zeigt jede Signaländerung, dass die Daten verarbeitet wurden).

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?

Achtung. Nicht durcheinander werfen. Jede Richtung ist ein separater Kanal. Und in jedem Kanal ist dieser Handshake zur Übergabe der Daten aufgebaut (ND und DR).
Kanal 1 (vom Controller zum Device) funktioniert.
Kanal 2 (vom Device zum Controller) funktioniert nicht.

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

der WatchDog ist ein (von der Kommunikation über die Kanäle unabhängiges) ToggleBit, mit dem die Verbindung überwacht wird.

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.

Genau das will ich damit sagen.

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?

Na, das hast Du doch im vorhergehenden Zitat schon beschrieben. Wenn ich auf eine (Re-)Aktion warte, ist das für mich ereignisgetriggert. D.h. ich sende nicht aufgrund eines Zeittriggers.

Was sagt denn Deine KommunikationsLaufzeitMessung zu den benötigten Zeiten?

Habe ich in diesem Fall (noch) nicht programmiert. Halte ich zwar für "NiceToHave", bringt mich aber nicht wirklich weiter, da ich ja schon geprüft habe, ob die Signale sauber übertragen werden. Dazu reicht es m.E. zu erkennen, ob die Kommunikation überhaupt funktioniert (und das ist ja gegeben).

VG

Mario

 

[Heinileini]

Achtung. Nicht durcheinander werfen. Jede Richtung ist ein separater Kanal. Und in jedem Kanal ist dieser Handshake zur Übergabe der Daten aufgebaut (ND und DR).
Kanal 1 (vom Controller zum Device) funktioniert.
Kanal 2 (vom Device zum Controller) funktioniert nicht.

Ja, allerdings Achtung! Trotz aller Vorsicht sind wir anscheinend schon voll dabei, aneinander vorbei zu reden.
Mein Verständnis ist:
Kanal 1: Controller sendet an Device das ToggleBit C, das nur im Controller getogglet wird
Kanal 2: Device sendet an Controller das empfangene ToggleBit C unverändert zurück
Die Auswertung dieser beiden Kanäle ergibt den WatchDog 1.
Kanal 3: Device sendet an Controller das ToggleBit D, das nur im Device getogglet wird
Kanal 4: Controller sendet an Device das empfangene ToggleBit D unverändert zurück
Die Auswertung dieser beiden Kanäle ergibt den WatchDog 2.

der WatchDog ist ein (von der Kommunikation über die Kanäle unabhängiges) ToggleBit, mit dem die Verbindung überwacht wird.

Dieser WatchDog ist von den beiden von mir o.g. WatchDogs unabhängig und erhält in meiner Zählung die Nr 3.

Wahrscheinlich habe ich mit meinem letzten Beitrag zur Verwirrung beigetragen, weil ich für Deine Toggeleien einfach den Begriff "WatchDog" verwendet/missbraucht habe. Einen weiteren, also dritten WatchDog, der noch irgendwo am wirken ist, hatte ich damit nicht gemeint.

Also, in Kanal 1 und 2 insgesamt nur 1-mal togglen und unabhängig davon in Kanal 3 und 4 insgesamt nur 1-mal togglen.

Wahrscheinlich gibt es bei Dir Kanal 3 und 4 gar nicht. Macht nix, wäre ja auch doppelt gemoppelt.
Aber dann toggelst Du also doch in Kanal 1 und 2 schon zweimal. Warum? Das ist nicht nötig und stört zumindest die Übersichtlichkeit.

Das ND wird in der einen Steuerung getoggelt (jede Signaländerung zeigt an, dass neue Daten geschrieben wurden). Das DR wird in der anderen Steuerung getoggelt (hier zeigt jede Signaländerung, dass die Daten verarbeitet wurden).

Mach uns das Leben doch nicht so schwer, Mario! Bitte nur in einer der beiden SPS togglen!

... (jede Signaländerung zeigt an, dass neue Daten geschrieben wurden) ...

Aha, das wäre dann aber ein weiteres getoggletes Bit, das nur die Änderung der übrigen an den Controller übertragenen Daten meldet! *)

Habe ich in diesem Fall (noch) nicht programmiert. Halte ich zwar für "NiceToHave", bringt mich aber nicht wirklich weiter, da ich ja schon geprüft habe, ob die Signale sauber übertragen werden. Dazu reicht es m.E. zu erkennen, ob die Kommunikation überhaupt funktioniert (und das ist ja gegeben).

Dass die Signale sauber übertragen werden, ist super. Nun änder bitte noch die Logik so, dass die Signale einfach und eindeutig bleiben (s.o.)!
Auch, wenn nur eine der beiden SPS togglet, kannst Du in beiden SPS die Zeiten zwischen den Flanken des empfangenen Signals messen und zur Bildung einer TimeOutFunktion auswerten.

Häwenaissuiikend!

Heinileini

PS:
*) Statt das ToggleBit des Controllers im Device noch mal zu toggeln, würde ich es im Device einfach negieren und an den Controller zurückschicken. Dann müsstest Du im meinem BeispielCode aus #18 das NOT noch entfernen, wie dort im Kommentar bereits erwähnt.
Das Negieren ist eindeutiger als ein Togglen bei einer beliebigen Flanke und dürfte genau Deinen Zweck erfüllen.

 

[Oberchefe]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie stellst du bei der ganzen Toggelei sicher, dass die schnellere CPU (das I-Device?) nicht zweimal hintereinander toggelt ohne dass die langsamere CPU das mitbekommt?
Wenn jede CPU unabhängig von der anderen neue Daten melden will, dann solltest du ein Byte/SINT/USINT in jeder Richtung spendieren, welches jeweils in der sendenden CPU hochgezählt wird und in der empfangenen CPU auf Änderung überprüft wird.

 

[Heinileini]

Wie stellst du bei der ganzen Toggelei sicher, dass die schnellere CPU (das I-Device?) nicht zweimal hintereinander toggelt ohne dass die langsamere CPU das mitbekommt?

Wie ich geschrieben hatte: bezogen auf das empfangene Signal NICHT verwenden, um die Rückmeldung zu toggeln, sondern es einfach nur negieren bzw. - wie vorher besprochen - einfach nur spiegeln.
Ich plädiere dafür, NICHT ein und dasselbe ToggleBit in zwei (oder mehr) verschiedenen Bedeutungen zu verwenden.
Falls man es trotzdem für vertretbar hält, muss man sich zusätzlich Gedanken machen, wann man das gespiegelte oder negierte Bit frühestens wieder an den Partner zurückschickt und man muss ggfs damit warten, bis man tatsächlich neue Daten ausgibt.
Das Zusammenfassen von zwei Bedeutungen führt hier dazu, dass keine der beiden Bedeutungen eindeutig verwendet geschweige denn eindeutig entschlüsselt werden kann.
Darum grundsätzlich lieber einfach, eindeutig und übersichtlich mit vorhersagbaren Folgen.

Wenn jede CPU unabhängig von der anderen neue Daten melden will, dann solltest du ein Byte/SINT/USINT in jeder Richtung spendieren, welches jeweils in der sendenden CPU hochgezählt wird und in der empfangenen CPU auf Änderung überprüft wird.

Auf das Aufbohren auf die ZählerVariante hatte Mario ja bereits hingewiesen.
Das ist flexibler und "besser", je nach dem, was man benötigt und was man daraus macht, überschreitet aber in jedem Fall den in diesem Thread beschriebenen Zweck bzw. FunktionsUmfang.

 

[MFreiberger]

Ja, allerdings Achtung! Trotz aller Vorsicht sind wir anscheinend schon voll dabei, aneinander vorbei zu reden.
Mein Verständnis ist:
Kanal 1: Controller sendet an Device das ToggleBit C, das nur im Controller getogglet wird
Kanal 2: Device sendet an Controller das empfangene ToggleBit C unverändert zurück
Die Auswertung dieser beiden Kanäle ergibt den WatchDog 1.
Kanal 3: Device sendet an Controller das ToggleBit D, das nur im Device getogglet wird
Kanal 4: Controller sendet an Device das empfangene ToggleBit D unverändert zurück
Die Auswertung dieser beiden Kanäle ergibt den WatchDog 2.

Dann habe ich es nicht gut beschrieben.
Es gibt ein ToggleBit, das genauso funktioniert, wie Du es beschrieben hast. Allerdings nur einmal und in der Variante "WatchDog2"

DANEBEN werden Daten übertragen. Diese Datenübertragung ist unidirekt, deswegen werden zwei Kanäle verwendet.

Kanal 1:
Controller sendet Daten, Device quittiert (und darf selber keine Daten senden)

Kanal 2:
Device sendet Daten, Controller quittiert (und darf selber keine Daten senden)

Damit die Übertragung konsistent funktioniert, gibt es zwei Bits (ND = NewData; DR = DataRead).
Der Sender toggelt das ND-Bit bei jedem Sendevorgang; der Empfänger wertet es aus. Wenn der Empfänger die Daten gelesen hat, toggelt er das DR-Bit und der Sender wertet es aus.

So ist sichergestellt, dass der Sender nur dann neue Daten sendet, wenn das Übertragungsfach frei ist.

Dass die Signale sauber übertragen werden, ist super. Nun änder bitte noch die Logik so, dass die Signale einfach und eindeutig bleiben (s.o.)!
Auch, wenn nur eine der beiden SPS togglet, kannst Du in beiden SPS die Zeiten zwischen den Flanken des empfangenen Signals messen und zur Bildung einer TimeOutFunktion auswerten.

PS:
*) Statt das ToggleBit des Controllers im Device noch mal zu toggeln, würde ich es im Device einfach negieren und an den Controller zurückschicken. Dann müsstest Du im meinem BeispielCode aus #18 das NOT noch entfernen, wie dort im Kommentar bereits erwähnt.
Das Negieren ist eindeutiger als ein Togglen bei einer beliebigen Flanke und dürfte genau Deinen Zweck erfüllen.

Diese ganzen Informationen sind gut, aber sie beziehen sich (soweit ich das erkenne) nur auf den "WatchDog" und wie man damit umgeht. Das ist aber nicht mein Problem.
Mein Problem ist, dass der Mechanismus, den ich für Kanal 1 programmiert habe (s.o.), so nicht für Kanal 2 funktioniert.

VG

Mario

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie stellst du bei der ganzen Toggelei sicher, dass die schnellere CPU (das I-Device?) nicht zweimal hintereinander toggelt ohne dass die langsamere CPU das mitbekommt?
Wenn jede CPU unabhängig von der anderen neue Daten melden will, dann solltest du ein Byte/SINT/USINT in jeder Richtung spendieren, welches jeweils in der sendenden CPU hochgezählt wird und in der empfangenen CPU auf Änderung überprüft wird.

Der einzige Vorteil, den ich von einem andern Datentypen hätte, als einem Bool, wäre, dass ich noch mitzählen könnte, wie oft kommuniziert wird. Das schafft meiner Meinung nach aber keine relevanten Zusatzinformationen, sondern nur ein Overhead an Daten.

Zum Prinzip des Toggelns:

- Partner 1 liest den Zustand des eingehenden Bits und sendet den invertierten Zustand über das ausgehende Bit (1:!1), wenn das eingehende Bit den gleichen Zustand, wie das ausgehenden Bit hat.

IF
    "STAWfromRBG1".TOGGLE = "CTRLtoRBG1".TOGGLE
THEN
    "CTRLtoRBG1".TOGGLE := NOT "STAWfromRBG1".TOGGLE;
END_IF;

- Partner 2 liest den Zustand des eingehenden Bits und sendet den gleichen Zustand über das ausgehende Bit (1:1), wenn das eingehende Bit den invertierten Zustand zum ausgehenden Bit hat.

IF
    "STAWfromGW".TOGGLE <> "CTRLtoGW".TOGGLE
THEN
    "CTRLtoGW".TOGGLE := "STAWfromGW".TOGGLE;
END_IF;

Jetzt kann man noch auf beiden Seiten auswerten, ob die Kommunikation aktiv ist (Timeout ~1s):
- Bei Partner 1, wenn eingehendes und ausgehendes Bit 1s lang den invertierten Zustand haben.
- Bei Partner 2, wenn eingehendes und ausgehendes Bit 1s lang den gleichen Zustand haben.

Bei dieser Art des Toggelns sind Zykluszeiten, zeitliche Trigger, schnellerer oder langsamerer Partner völlig irrelevant. Man könnte sogar die Laufzeit messen:
- Partner 1: nach welcher Zeit hat das eingehende Bit den gleichen Zustand, wie das ausgehende Bit
- Partner 2: nach welcher Zeit hat das eingehende Bit den Invertierten Zustand, wie das ausgehende Bit


VG

MFreiberger

 

[MFreiberger]

So, SIEMENS hat geantwortet:

Sehr geehrter Herr Freiberger,

vielen Dank für Ihre Service.-Anfrage.

Ich habe mir den Beispielcode angeschaut und kann nicht ausschließen, dass es sich hier um einen Fehler von unserer Seite handelt. Zur weiteren Untersuchung würde ich Sie bitten mir das Projekt zukommen zu lassen. [..]

Na, dann will ich das Programm mal versandfertig machen...

VG

 

[Matze001]

Wir freuen uns auf ein Update...
/remindme 10years

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kanal 1:
Controller sendet Daten, Device quittiert (und darf selber keine Daten senden)

Kanal 2:
Device sendet Daten, Controller quittiert (und darf selber keine Daten senden)

Wann darf Device bzw. Controller denn selber wieder Daten senden? Reagiert wird doch immer nur auf eine Flanke des einen Bits mit einer Flanke des anderen Bits. Und die Flanke des "anderen" Bits hat doch zwei Bedeutungen:
- Quittierung, dass Daten gelesen wurden und ausserdem bzw. gleichzeitig,
- dass Daten geschrieben bzw. bereitgestellt wurden.
Warum sollen sich jetzt beide Bedeutungen gegenseitig ausschliessen?
Ausser bzw. zwischen den Flanken der ToggleBits passiert doch nicht anderes, womit ein Ablauf in weitere Phasen eingeteilt werden könnten?
Mit dem Quittieren und dem Befüllen des Puffers, muss jede Seite warten, bis die andere Seite meldet "ich habe etwas geschickt" UND die eigene Seite neue Daten liefern kann.

 

[MFreiberger]

Moin Heinrich,

erstmal vielen Dank, dass Du mir gedanklich so unter die Arme greifst!

Wann darf Device bzw. Controller denn selber wieder Daten senden?

Zunächst einmal immer nur, wenn der Empfänger gelesen hat.
Darüber hinaus (auch initial), wenn für eine Zeit x (1m)
- Das DR-Bit nicht geändert wurde (Daten nicht gelesen)
- UND
- das ND-Bit geändert wurde (neue Daten geschrieben)
- ODER das ND-Bit für eine Zeit x (30s) nicht geändert wurde

SenderCode:

    "RBG1_DATA_DB".timeoutDR_toggle.TON(IN :=
                                        "STAWfromRBG1".DR_toggle_TELE = "RBG1_DATA_DB".DR_toggleMem_TELE // Empfang wurde nicht bestätigt
                                        AND
                                        ("RBG1_DATA_DB".ND_toggle_SND_TELE_mem <> "CTRLtoRBG1".ND_toggle_TELE // neue Daten wurden gesendet
                                        OR "RBG1_DATA_DB".timeoutND_toggle.Q)
                                        AND "STAWfromRBG1".DS_enable_TELE
                                        AND NOT "RBG1_DATA_DB".SND_BUFFER_STATE_TELE.EMPTY,
                                        PT := t#1m);
    
    
    "RBG1_DATA_DB".timeoutND_toggle.TON(IN :=
                                        "RBG1_DATA_DB".ND_toggle_SND_TELE_mem = "CTRLtoRBG1".ND_toggle_TELE // "neue Daten wurden gesendet" noch nicht getriggert
                                        AND "STAWfromRBG1".DS_enable_TELE
                                        AND NOT "RBG1_DATA_DB".SND_BUFFER_STATE_TELE.EMPTY,
                                        PT := t#30s);
    
    IF
        "STAWfromRBG1".DR_toggle_TELE <> "RBG1_DATA_DB".DR_toggleMem_TELE // die letzten Daten wurden gelesen
        AND "STAWfromRBG1".DS_enable_TELE
        AND NOT "RBG1_DATA_DB".SND_BUFFER_STATE_TELE.EMPTY
    THEN
        "RBG1_DATA_DB".DR_toggleMem_TELE := "STAWfromRBG1".DR_toggle_TELE;
        
        "POOL_fifoBuffer"(Ix_en := true,
                          Ix_mode := false,
                          Iv_initialValue := "MFR_DATA_DB".RBG_TELEempty,
                          Oi_error => #Ti_FIFO_error,
                          IOs_STATE := "RBG1_DATA_DB".SND_BUFFER_STATE_TELE,
                          IOv_item := "TELEtoRBG1",
                          IOv_buffer := "RBG1_SND_BUFFER_DB".TELE);
        
      
        "CTRLtoRBG1".ND_toggle_TELE := NOT "CTRLtoRBG1".ND_toggle_TELE;
        "RBG1_DATA_DB".ND_toggle_SND_TELE_mem := NOT "CTRLtoRBG1".ND_toggle_TELE;
        
    END_IF;
    
    
    IF
        "RBG1_DATA_DB".timeoutDR_toggle.Q
    THEN
        "RBG1_DATA_DB".DR_toggleMem_TELE := NOT "STAWfromRBG1".DR_toggle_TELE;
    END_IF;

EmpfängerCode:

IF
    "STAWfromGW".ND_toggle_TELE <> "eTELE_GW_DATA_DB".ND_toggleMem
THEN
    "eTELE_GW_DATA_DB".ND_toggleMem := "STAWfromGW".ND_toggle_TELE;
    
    "eTELE_rcvBox_DB".TELE_rcv := #Tac_empty;
    
    FOR #i := 0 TO 119 DO
        "eTELE_rcvBox_DB".TELE_rcv[#i] := "TELEfromGW".DATA[#i];
    END_FOR;
    
    "POOL_copy"(Oi_RetValSerialize => #T_RetVal[9].Serialize,
                Oi_RetValDeserialize => #T_RetVal[9].Deserialize,
                IOv_source := "eTELE_rcvBox_DB".TELE_rcv,
                IOv_target := "eTELE_eTeleBuffer".general.item."CHAR");
    
    "eTELE_RingBuffer_IDB"(Ix_req := TRUE,
                           Iv_initialValue := "eTELE_eTeleBuffer".general.initVal,
                           Oi_error => #Ti_RetVal_Ringpuffer,
                           Oi_lastEntryIndex => "eTELE_eTeleBuffer".general.index,
                           IOv_item := "eTELE_eTeleBuffer".general.item,
                           IOv_buffer := "eTELE_eTeleBuffer".general.buffer);
    
    "eTELE_rcvBox_DB".TELE_rcvOk.ITEM := "eTELE_rcvBox_DB".TELE_rcv;
    "eTELE_rcvBox_DB".TELE_rcvOk.DateTime := "MAIN_CLOCK_DB".Lokalzeit;
    "eTELE_rcvBox_DB".TELE_rcvOk.occ := true;
    
    // Datensatz gelesen melden
    //
    "CTRLtoGW".DR_toggle_TELE := NOT "CTRLtoGW".DR_toggle_TELE;

END_IF;

Reagiert wird doch immer nur auf eine Flanke des einen Bits mit einer Flanke des anderen Bits.

Im Prinzip: ja.

Und die Flanke des "anderen" Bits hat doch zwei Bedeutungen:
- Quittierung, dass Daten gelesen wurden und ausserdem bzw. gleichzeitig,
- dass Daten geschrieben bzw. bereitgestellt wurden.

Also:
DR => Quittierung, dass Daten gelesen wurden
ND => Quittierung, dass Daten geschrieben wurden

Warum sollen sich jetzt beide Bedeutungen gegenseitig ausschliessen?

Die Frage verstehe ich nicht.

Ausser bzw. zwischen den Flanken der ToggleBits passiert doch nicht anderes, womit ein Ablauf in weitere Phasen eingeteilt werden könnten?

ja...?

Mit dem Quittieren und dem Befüllen des Puffers, muss jede Seite warten, bis die andere Seite meldet "ich habe etwas geschickt" UND die eigene Seite neue Daten liefern kann.

Nein. Denn, wenn man erstmal einen Kanal für sich betrachtet, ist dieser unidirektional. Der Empfänger muss warten, bis neue Daten geschrieben wurden; der Sender muss warten, bis die Daten gelesen (verarbeitet) wurden.
Allerdings wird das Senden per timeout zusätzlich angestossen, wenn er weiß, dass er neue Daten gesendet hat, diese aber nicht verarbeitet wurden. Hier sollte man vielleicht noch mit abfragen, ob die Verbindung steht (Auswertung des WatchDogs).

VG

Mario

Nebenbei: mein eigentliches Problem nimmt SIEMENS gerade unter die Lupe. Man schrieb mir, dass man das Verhalten mit TIA V15.1 Upd7 (noch) nicht nachvollziehen konnte..... Dann kam eine zweite Mail, in der man mir mitteilte, dass man sich vertan hat (ich benutze ja TIA V16 Upd6) und man es noch einmal testen will.

 

[Heinileini]

Nebenbei: mein eigentliches Problem nimmt SIEMENS gerade unter die Lupe.

Moin Mario,

ich hatte ja den Verdacht, dass Dein "eigentliches Problem" auf eine Art StroboskopEffekt beim Beobachten zurückzuführen ist.
Unterschiedliche zeitliche Gegebenheiten in den beiden SPS könnten möglicherweise auch dazu führen, dass in einer SPS alles so läuft, wie erwartet und in der anderen scheinbar nicht.
Es kann natürlich auch sein, dass eine Siemens-Macke dahinter steckt ... warten wir's ab, ob Siemens tatsächlich noch eine Ursache findet.

Gruss, Heinileini

 

[TP-Inc]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe den Thread gelesen und ehrlich gesagt nicht ganz verstanden. Ich verwende seit Jahren I-Device und mache nichts anderes als eine CPU spiegelt, die andere invertiert. Warum so kompliziert? Oder habe ich was verpasst?

 

[PN/DP]

Ich schätze daß da irgendein methodischer Fehler dahintersteckt, falls da tatsächlich ein Problem ist. Die Codestücken sind mir allerdings zu groß, um den Kern des Problems zu verstehen oder gar den Fehler zu sehen.

Harald

 

[Thomas_v2.1]

Ich würde auch empfehlen, sich für den Austausch ein Sequenzdiagramm anzufertigen wie das bei solchen Dingen üblich ist. Daran lassen sich besser grundsätzliche Denkfehler erkennen, als an fertigem Code.

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,

kleines Update: Ein Service-Mitarbeiter von SIEMENS hat sich den Fall heute remote angesehen. Jetzt durfte ich ihm die Traces, die wir in der Session mitgeschnitten haben und einen Abzug der Speicherkarte der Steuerung schicken und er gibt den Fall weiter an die Entwicklung.

VG

MFreiberger