Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Ergebnis 1 bis 8 von 8

Thema: Libnodave Timeout

  1. #1
    Registriert seit
    19.07.2004
    Beiträge
    414
    Danke
    44
    Erhielt 34 Danke für 20 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Zottel, nochmal eine Frage

    Ich habe DaveInterface^.Timeout := 2000000; // 2 Sekunden

    und folgenden Code :

    Code:
    function TMaschine.NextJob: Integer;
    begin
      Result := -1;
      if TestPing(FIpAdresse, PollTimeOut) then begin
        case FJobIndex of
          0: Result := DaveReadBytes(DaveConnection, DaveInputs, 0, 0,  128, @EData[0]);      // EB 0 - 127
          1: Result := DaveReadBytes(DaveConnection, DaveOutputs, 0, 0,  2, @AData[0]);       // AB 0 - 127
          2: Result := DaveReadBytes(DaveConnection, DaveFlags, 0, 0, 128, @MData[0]);        // MB 0-127
          3: Result := DaveReadBytes(DaveConnection, DaveFlags, 0, 128, 128, @MData[128]);    // MB 128 - 255
          4: Result := DaveReadBytes(DaveConnection, DaveDB, 1, 0, 150, @DB1Data[0]);         // DB1 DBB 0 - 149
          5: Result := DaveReadBytes(DaveConnection, DaveDB, 1, 150,  148, @DB1Data[150]);    // DB1 DBB 150 - 298
          6: Result := DaveReadBytes(DaveConnection, DaveDB, 35, 0, 150, @DB35Data[0]);       // DB35 DBB 0 - 149
          7: Result := DaveReadBytes(DaveConnection, DaveDB, 35, 150, 150, @DB35Data[150]);   // DB35 DBB 150 - 299
          8: Result := DaveReadBytes(DaveConnection, DaveDB, 35, 300, 150, @DB35Data[300]);   // DB35 DBB 300 - 449
          9: Result := DaveReadBytes(DaveConnection, DaveDB, 20, 0,  103, @DB20Data[0]);      // DB20 DBB 0 - 102
          10: Result := DaveReadSZL(DaveConnection, $19, 0, @SzlData[0]);                     // SZL Led - Abbild
          100: Result := DaveWriteBytes(DaveConnection, DaveDB, 1, 48, 4, @DB1Data[48]);      // DB1 DBB 48 - 51
        end;
        Inc(FJobIndex);
        if FJobIndex < 100 then begin
          if FJobIndex > 10 then
            FJobIndex &#58;= 0;
        end else begin
          if FJobIndex > 100 then
            FJobIndex &#58;= 0;
        end;
      end;
    end;
    Wenn direkt im Lesen von Variablen aus der Steuerung nun der CP ausgeht, kommt mein Programm nie wieder ??
    Gilt das TimeOut nicht auch für DaveReadBytes... Kann es sein, das, wenn der CP ausfällt mitten in DaveReadBytes ein Programmhänger entsteht ???? Früher,mit dem Seriellen Adapter, habe ich das so nie gesehen. Bin mir aber nicht sicher...

    Und lach nicht, mit dem Ping vor dem Lesen, habe ich eine schnellere Reaktion bei ausgefallenem CP (?)
    Für richtiges Chaos,braucht man sehr schnelle Computer.
    Und wieso einfach... .... wenn es auch Siemens gibt



    Zitieren Zitieren Libnodave Timeout  

  2. #2
    Registriert seit
    19.06.2003
    Beiträge
    2.200
    Danke
    85
    Erhielt 259 Danke für 175 Beiträge

    Standard

    Wenn direkt im Lesen von Variablen aus der Steuerung nun der CP ausgeht, kommt mein
    Programm nie wieder ??
    Ist das eine Feststellung oder eine Frage?

    Gilt das TimeOut nicht auch für DaveReadBytes
    Nein, nicht wenn es eine TCP/IP-Verbindung under Windows ist. Die handhabt winsock2 mit default-Einstellungen.
    ... Kann es sein, das, wenn der CP ausfällt mitten in DaveReadBytes ein Programmhänger entsteht ????
    Du meinst, daß das Programm "hängt"? Ja das könnte wohl sein, daß die Funktion receive() aus winsock2.dll nie zurückkehrt. Ich muß es mal systematisch probieren. Habe aber keinen CP und die Simulation eines CP auf Linux ist so schnell, daß es schwer ist, mitten im Senden den Stecker zu ziehen. Und der TCP/IP -Stack von Linux gut genug, um das Paket nachzureichen, wenn der Stecker wieder reingesteckt wird...
    Und lach nicht, mit dem Ping vor dem Lesen, habe ich eine schnellere Reaktion bei ausgefallenem CP (?)
    Ist das eine Feststellung oder eine Frage?
    Ich habe sowas ähnliches an ganz anderer Stelle: Aus einem Linux-Programm sende ich Daten an eine AS400. Das passiert nur alle 20-60 Minuten. Da bekam ich timeouts. Das passiert nicht, wenn ich sie vorher "pinge"... Habe es nicht näher untersucht. Auf jeden Fall sind Ethernet-Switches dazwischen. Möglicherweise "lernen" sie beim 1. Ping die Route neu und vergessen sie zwischenzeitlich. Möglicherweise setzt die AS400 irgenetwas zur Handhabung der Ethenet-Schnittstelle oder verbindungsspezifische Sachen auf niedrige Prioirtät. Kann sein, daß so ein Ping auch den CP weckt.

    [/quote]
    Zitieren Zitieren Re: Libnodave Timeout  

  3. #3
    Avatar von Lazarus™
    Lazarus™ ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    19.07.2004
    Beiträge
    414
    Danke
    44
    Erhielt 34 Danke für 20 Beiträge

    Standard

    Aha,dann ist es nicht ein logischer Fehler meinerseits. Also bei Verwendung von einem MPI-Adapter passiert das auch nicht...

    Schade... Ist schon doof,wenn der Anwender später die Maschine Abends ausmacht und das BDE ergurgelt sich... Na mal sehen, was man da machen kann,an die Funktion receive() aus winsock2.dll komme ich ja so nicht ran, um das abzufangen ...

    Sorry für die Fragezeichen (?) und ?? sollten Ratlosigkeit symbolisieren :P
    Für richtiges Chaos,braucht man sehr schnelle Computer.
    Und wieso einfach... .... wenn es auch Siemens gibt




  4. #4
    Avatar von Lazarus™
    Lazarus™ ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    19.07.2004
    Beiträge
    414
    Danke
    44
    Erhielt 34 Danke für 20 Beiträge

    Standard

    Ja, ist wohl wirklich so, unter TCPIP kommt der Aufruf DaveReadBytes(...)
    nie mehr wieder, wenn der CP aussteigt... Wenn mein Debugger nicht gelogen hat (Bediener vor PC ist kein Assembler Freak) , hängt das irgendwo ausserhalb deiner Routinen im OS... Wüsste gern, wie man das lösen könnte. Einen Weg muss es ja geben...

    Gibt es eigentlich einen Unterschied, ob man das mit Prodave/LibNoDave oder S7-SAPI macht ??? Weil, wenn man irre viele Variablen mit WinCC in sehr kurzen abständen pollt, läuft das recht flott. Mit den eigenen Routinen ist das eher Zeitlupe... Mache ich was falsch, oder ist das Protokollbedingt ??

    Wieder viele Fragen *ggg*, aber nützt ja nix
    Für richtiges Chaos,braucht man sehr schnelle Computer.
    Und wieso einfach... .... wenn es auch Siemens gibt




  5. #5
    Registriert seit
    19.06.2003
    Beiträge
    2.200
    Danke
    85
    Erhielt 259 Danke für 175 Beiträge

    Standard

    Zitat Zitat von Lazarus™
    Ja, ist wohl wirklich so, unter TCPIP kommt der Aufruf DaveReadBytes(...)
    nie mehr wieder, wenn der CP aussteigt... Wenn mein Debugger nicht gelogen hat (Bediener vor PC ist kein Assembler Freak) , hängt das irgendwo ausserhalb deiner Routinen im OS... Wüsste gern, wie man das lösen könnte. Einen Weg muss es ja geben...
    Habe gestern folgendes probiert: testISO_TCP -b -d <IP-von-der-Linux-Box> auf Win2000 laufen lassen. Vorher in nodave.c vor und hinter den recv()-Aufrufen Zeilen eingefügt wie 'log1("before recv\n")';, 'log1("back from recv\n")';
    Auf der Linux-Kiste lief isotest4 (CP-Simulation).
    Dann im laufenden Benchmark Stecker gezogen. Programm hing 2-3 Minuten. Dann gab's aber timeout-Meldungen. Das Programm hing also nicht in "alle Ewigkeit".

    Gibt es eigentlich einen Unterschied, ob man das mit Prodave/LibNoDave oder S7-SAPI macht ??? Weil, wenn man irre viele Variablen mit WinCC in sehr kurzen abständen pollt, läuft das recht flott.
    Keine Ahnung, wie WinCC das macht. Generell kann es auch nicht mehr. Die Begrenzung auf
    PDU-Länge- 18 bytes pro Lesezufriff ist S7-spezifisch, da kann auch WinCC nicht anders.
    Oder zeichne mal den Datenaustauch von WinCC mit Ethereal auf. Natürlich diie vollständigen Pakete.
    Mit den eigenen Routinen ist das eher Zeitlupe... Mache ich was falsch, oder ist das Protokollbedingt ??
    Was sagt der Benchmrk (testISO_TCP -b)?
    Zu deinen Blocklängen: Wie groß ist die PDU-Länge mit deinem CP?
    testISO_TCP -d zeigt das an:
    ** Partner offered PDU length
    und dann 240 oder 480.
    Die solltest du auch ausnutzen.

  6. #6
    Avatar von Lazarus™
    Lazarus™ ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    19.07.2004
    Beiträge
    414
    Danke
    44
    Erhielt 34 Danke für 20 Beiträge

    Standard

    Nochmal ich

    Ist es möglich in deiner Lib parallel zu Read,Write, OpenSock... eine Timeoutgeschichte zu machen ??? Also ich meine wenn abgelaufen, Abbruch und die Funktion kommt mit einem Fehler zurück ???

    Also ich meine ein Timeout auf dem Untersten Level vom Protokoll...

    Nur so eine Idee,weiss garnicht ob das ginge...

    Also bei mir zumindest, kommt bei einem Read nie mehr ne Antwort. Ich habe schon Stunde gewartet über Nacht. Bix. Kommt nie wieder zurück.
    Ich denke es liegt an Windows...

    Übrigens die 0.8 funzt auch gut, die Unit ist ok unter Delphi. Und die Komponente funktioniert auch...
    Für richtiges Chaos,braucht man sehr schnelle Computer.
    Und wieso einfach... .... wenn es auch Siemens gibt




  7. #7
    Registriert seit
    19.06.2003
    Beiträge
    2.200
    Danke
    85
    Erhielt 259 Danke für 175 Beiträge

    Standard

    Zitat Zitat von Lazarus™
    Ist es möglich in deiner Lib parallel zu Read,Write, OpenSock... eine Timeoutgeschichte zu machen ???
    Paraleel würde, wenn ich es richtig verstehe, darauf hinauslaufen, parallele threads zu starten, einer wartet auf recv(), der andere zählt die Zeit und killt den ersten, wenn's zu lange dauert. Nein, das werde ich nicht tun. Erstens müßte ich mir die ganze threading-Sache von Windows reintun, zweitens würde es die Bibliothek ziemlich verkomplizieren. Das kann man sicher auf Anwender-Ebene genauso machen: einer wartet auf daveReadBytes(), der andere zählt die Zeit und killt den ersten, wenn's zu lange dauert.
    Also ich meine ein Timeout auf dem Untersten Level vom Protokoll...
    Nur so eine Idee,weiss garnicht ob das ginge...
    Ich hatte das oben dargestellte Ergebnis meiner Versuche so verstnaden, daß es durchaus ein timeout für recv auf Windows-Ebene gibt. Mein Programm (unter Win2000, nur die CP-Simulation lief unter Linux) kam ja zurück.
    Nur diese Zeit ist (unter Windows) nicht mit daveSetTimeout beeinflußbar (was anders sein sollte).
    Welche Windows-Version benutzt du?
    Die andere Frage ist, ob ein realer CP irgendetwas (beim Aufbau der TCP/IP-Verbindung) übermittelet, was Windows veranlaßt "ewig" zu warten.
    Übrigens die 0.8 funzt auch gut, die Unit ist ok unter Delphi. Und die Komponente funktioniert auch...
    Gut zu hören.

  8. #8
    Avatar von Lazarus™
    Lazarus™ ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    19.07.2004
    Beiträge
    414
    Danke
    44
    Erhielt 34 Danke für 20 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Also im Moment XPSP2, habe noch nicht getestet, ob es unter Win2K oder so anders aussieht. Das werde ich mal machen...

    Hast recht, ich kann meinen Thread ja auch überwachen *an Kopf klatsch*,
    also manchmal sieht man den Wald vor lauter Bäumen garnich...
    Für richtiges Chaos,braucht man sehr schnelle Computer.
    Und wieso einfach... .... wenn es auch Siemens gibt




Ähnliche Themen

  1. Antworten: 0
    Letzter Beitrag: 09.09.2010, 00:27
  2. S7-Graph Timeout, Unplausible Eingänge, Einzelschritt
    Von element. im Forum Programmierstrategien
    Antworten: 6
    Letzter Beitrag: 11.11.2009, 12:36
  3. libnodave timeout Problem
    Von Key im Forum Hochsprachen - OPC
    Antworten: 26
    Letzter Beitrag: 31.03.2009, 14:42
  4. libnodave und Timeout
    Von HeizDuese im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 06.01.2009, 15:06
  5. timeout am SEW-Umrichter
    Von Lubro im Forum SEW-EURODRIVE
    Antworten: 7
    Letzter Beitrag: 01.10.2008, 19:29

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •