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

Seite 5 von 6 ErsteErste ... 3456 LetzteLetzte
Ergebnis 41 bis 50 von 56

Thema: TCP/IP Telegrammaustausch mit PC variable Telegrammlänge

  1. #41
    Registriert seit
    12.02.2008
    Ort
    Westfalen (Dort wo's Schwarzbrot gibt)
    Beiträge
    417
    Danke
    8
    Erhielt 87 Danke für 72 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Wenn jetzt nicht mal mehr der erste Aufruf was abholt, muss der 2. Aufruf ja doch irgendwie vonstatten gehen. Bist Du ganz sicher, das der nicht doch noch aufgerufen wird? Du musst die Aufrufe ja überspringen, ein Enable hat der FC ja nicht.

    Eine andere Möglichkeit wäre es, den FC generell nur einmal im Prog zu verwenden und pro Durchlauf mit geänderten Parametern zu versehen.

    Poste doch mal was Du hast, vielleicht sieht man dann, woran es hapert.

  2. #42
    3DA ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    07.07.2008
    Beiträge
    20
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Sorry muss meine Aussage nochmal korrigieren:


    Hab jetzt nochmal nur 1 AG_RECV verwendet und dabei folgendes raus gefunden.

    Ich verwende zum testen ein Programm ähnlich wie der HyperTerminal namens Hercules.

    Mit dem kann man sich über IP und Socket verbinden und Telegramme senden/empfangen. Mit diesem Prog funktioniert das wunderbar, ein 30 Byte Telegramm zu senden und dann mit dem AG_RECV 8-Byteweise abzuholen. Verwende ich aber das Programm, mit dem ich dann im endeffekt kommunizieren muss, geht der AG_RECV auf Störung, sobald der Datenbereich kleiner als das zu empfangene Telgramm ist. Sprich: es kommt ein 30 Byte Telegramm und ich kann alle Speicherbereich über 30 Byte angeben--> es funktioniert, aber sobald ich 29 Byte oder kleiner nehm, geht er auf Störung mit Fehlermeldung 16#80b1?!

    Keine Ahnung warum... an was könnte das liegen?

  3. #43
    Registriert seit
    12.02.2008
    Ort
    Westfalen (Dort wo's Schwarzbrot gibt)
    Beiträge
    417
    Danke
    8
    Erhielt 87 Danke für 72 Beiträge

    Standard

    Kann ich mir so auch nicht erklären. Vielleicht sendet das Testprogramm nur einmal per Mausklick, das Originalprog zyklisch ?

    Hier mal ein Link. Derjenige hatte das gleiche Problem wie Du:

    http://www.automation.siemens.com/fo...de&PageIndex=1

    Ansonsten wirklich mal Deinen Code reinstellen.

  4. #44
    3DA ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    07.07.2008
    Beiträge
    20
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Also das eignetliche Prog sendet nur 1 Telegramm, und das in einem Zeitabstand von vielleicht 3-4 sec. also völlig zeitunkritisch. Mein AG_RECV Aufruf sieht folgendermaßen aus:

    CALL "TCP_RECEIVE" (FC6)
    ID :=2
    LADDR :=W#16#100
    RECV :=P#DB6.DBX2.0 BYTE 8
    NDR :=#RecvNewData
    ERROR :=#RecvError
    STATUS:=#RecvStatus
    LEN :=#RecvLength
    NOP 0

    Wie gesagt, ich kapier halt nicht, wieso der Speicherbereich zu klein Fehler kommt, weil der doch auf den Speicher des Bausteins selber bezogen ist oder? Und der müsst doch > 200 Byte sein und mein Telegramm hat maximal 30 Byte.

    Hilft dir der Bausteinaufruf was? Weil alles andere hab ich mittlerweile schon rausgeworfen.

  5. #45
    Registriert seit
    12.02.2008
    Ort
    Westfalen (Dort wo's Schwarzbrot gibt)
    Beiträge
    417
    Danke
    8
    Erhielt 87 Danke für 72 Beiträge

    Standard

    Tja, wenn ich noch nen CP hätte würd ichs ja selber mal testen...

    So, meine letzten Versuche vor Feierabend:

    -Dein Empfangs-DB ist aber auch 8 Byte oder größer ?

    -Unter Netpro die Verbindung auch als TCP-Verbindung projektiert ? (nicht evtl. Iso on TCP?)

  6. #46
    3DA ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    07.07.2008
    Beiträge
    20
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Also der Empfangs-DB ist größer als 8 Byte.

    Ja TCP Verbindung ist richtig eingestellt, sonst würde es ja bei einer größeren RECV auch nicht funktionieren.

    Ist das ein Problem, wenn der DB größer ist, als der angegebene Bereich?!


    Wie Feierabend??!

  7. #47
    Registriert seit
    22.05.2005
    Ort
    sonniges Maifeld
    Beiträge
    1.067
    Danke
    77
    Erhielt 205 Danke für 159 Beiträge

    Standard

    ----------
    "Man kann auf seinem Standpunkt stehen, aber man sollte nicht darauf sitzen" - Erich Kästner

  8. #48
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.220
    Danke
    533
    Erhielt 2.696 Danke für 1.948 Beiträge

    Standard

    Zitat Zitat von Grubba Beitrag anzeigen
    Kann ich mir so auch nicht erklären. Vielleicht sendet das Testprogramm nur einmal per Mausklick, das Originalprog zyklisch ?

    Hier mal ein Link. Derjenige hatte das gleiche Problem wie Du:

    http://www.automation.siemens.com/fo...de&PageIndex=1

    Ansonsten wirklich mal Deinen Code reinstellen.
    Besonders der Hinweis, mit der Umschaltung zu warten, solange der Auftrag noch läuft, wäre wichtig. (letzter Post im Beitrag!)
    Geändert von Ralle (19.06.2009 um 13:18 Uhr)
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  9. #49
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.220
    Danke
    533
    Erhielt 2.696 Danke für 1.948 Beiträge

    Standard

    Zitat Zitat von 3DA Beitrag anzeigen
    Also der Empfangs-DB ist größer als 8 Byte.

    Ja TCP Verbindung ist richtig eingestellt, sonst würde es ja bei einer größeren RECV auch nicht funktionieren.

    Ist das ein Problem, wenn der DB größer ist, als der angegebene Bereich?!


    Wie Feierabend??!
    Glaub ich nicht, hab ich auch immer größer.

    PS: Es ist dir aber sicher klar, daß du den Any

    RECV :=P#DB6.DBX2.0 BYTE 8

    dynamisch erzeugen mußt, da ja die Byteanzahl, (also LEN) genau dort festgelegt wird!

    Byte 8 für den Kopf
    Byte xx, dann für die unterschielich langen Resttelegramme.
    Geändert von Ralle (19.06.2009 um 13:21 Uhr)
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  10. #50
    Registriert seit
    22.05.2005
    Ort
    sonniges Maifeld
    Beiträge
    1.067
    Danke
    77
    Erhielt 205 Danke für 159 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von 3DA Beitrag anzeigen
    Noch ne Frage am Rande...

    wenn ich anstatt eines CP-343-1 Lean eine CPU315-2PN/DP einsetze und mit TSEND bzw. TRECV arbeite, würde das das empfangen von variablen Telegrammlängen vielleicht vereinfachen?

    Habe leider mit TSEND/TRECV null Erfahrung.

    Kann da jemand mehr dazu sagen?
    Das Thema hat zwar schon etwas Staub angesetzt, aber mir ist grad eben aufgefallen das die Profinet-Cpu´s mit ihren Bausteinen für die offene TCP-Kommunikation den Datenempfang über TCP mit verschiedenen Telegrammlängen beherschen.

    Am T-Recieve muss für den Parameter LEN = 0 angegeben werden.
    "Man kann auf seinem Standpunkt stehen, aber man sollte nicht darauf sitzen" - Erich Kästner

  11. Folgender Benutzer sagt Danke zu Lars Weiß für den nützlichen Beitrag:

    IBFS (31.08.2009)

Ähnliche Themen

  1. S7 Variable in Java Variable umwandeln
    Von maxi81 im Forum HMI
    Antworten: 0
    Letzter Beitrag: 26.11.2010, 17:55
  2. Telegrammlänge Ethernet/IP
    Von Michitronik im Forum Feldbusse
    Antworten: 2
    Letzter Beitrag: 16.04.2010, 20:12
  3. INT Variable
    Von snowkopp im Forum Simatic
    Antworten: 6
    Letzter Beitrag: 21.09.2009, 22:59
  4. Antworten: 7
    Letzter Beitrag: 05.03.2008, 07:38
  5. OP7 Variable
    Von godi im Forum HMI
    Antworten: 5
    Letzter Beitrag: 25.04.2006, 22:09

Stichworte

Lesezeichen

Berechtigungen

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