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

Seite 4 von 6 ErsteErste ... 23456 LetzteLetzte
Ergebnis 31 bis 40 von 56

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

  1. #31
    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


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo Flinn,


    danke mal für deinen Post.

    Aber wie kann man den Puffer des AG_RECV selber kreieren?

    Wie würdest du das ganze Progammtechnisch aufbauen?


    Danke schon mal für deine Hilfe!

  2. #32
    Registriert seit
    25.08.2003
    Beiträge
    332
    Danke
    46
    Erhielt 54 Danke für 46 Beiträge

    Lächeln

    Zitat Zitat von Grubba Beitrag anzeigen
    So, auf ein letztes...

    Habe überlesen, das Du ja eine Endekennung des Telegramms bekommst. Wenn Du jetzt wirklich immer nur 1 Byte ausliest, könnte es so evtl. doch so gehen:

    - Ziel DB anlegen, mit genug Bytes für maximales Telegramm
    - AnyPointer basteln, der nach jedem NDR die Zieladresse in Deinem Ziel-DB um 1 erhöht, (aber immer noch 1 Byte gross)
    - Nach Empfang der Endekennung Pointer wieder auf 1. Byte im Ziel-DB zurücksetzen.

    Ist ähnlich wie der letzte Vorschlag von Lars, dass Problem sehe ich darin, das der Siemens FB die aktuellen Empfangsdaten da ablegt, wo die alten Empfangsdaten aufhören. Wenn die Sende und Empfangslänge übereinstimmen - wunderbar. Ansonsten gibts immer einen Versatz von Empfang zu Empfang. Bei Empfangslänge von 1 hast Du dieses Problem halt nicht.
    Hi 3DA,
    ich würde das so machen, wie Grubba schon angedacht hat, siehe oben.
    Mit jedem NDR das empfangene Byte in ein DB kopieren, hierbei die DBB-Ziel-Adresse jeweils um ein Byte inkrementieren. Anschließend mit einer Schleife die Anfangskennung suchen (durch byteweisen Vergleich der Headerdaten). Wenn Anfangskennung gefunden, Anfangsposition merken. Jetzt Endekennung suchen. Wenn gefunden, dann Endeposition merken. Dann Anypointer zusammenbauen (mit Länge = Endeadresse - Anfangsadresse) und Quelldaten auf einen Arbeits-DB kopieren und weiterverarbeiten. Jetzt Pointer wieder auf Byteadresse Null setzen.

    Viel geschrieben, ist aber im Prinzip genau das, was Grubba meinte.

    Sendet das PC-Programm eigentlich zyklisch in gewissen Zeitabständen?
    Was soll bei ungültigen Telegrammen passieren? Verwerfen?
    Quittierst du Telegramme zurück? Dann könnte der PC nochmals senden.

    Gruß
    Flinn

  3. #33
    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

    Hallo,


    also der Ansatz mit dem Byteweise auslesen scheint sehr gut zu sein.

    Hab das mal so probiert. Mein Problem ist jetzt nur, bei RECV

    P#DB6.DBX2.0 BYTE 8 funktioniert das wunderbar. Aber wenn ich dort nur

    1 Byte angebe, geht der AG_RECV Baustein gleich auf ERROR=1.

    Fehlercode=16#8184. und das PC programm kann auch garnicht mehr

    verbinden.

    Noch ne Frage: Wie würde ihr den Any-Pointer programmieren, um das

    aus dem Empfangs- in einen ArbeitsDB zu kopieren? Kenn mich leider

    mit AnyPointern nicht so recht aus...

    Noch zum PC Programm:

    Es schickt ca. 7 verschiedene Telegramme mit teilweise verschiedenen

    Längen. Header sind aber im 8 Zeichen. Und die Telegramme mit gleichem

    Header sind auch immer gleich lang bzw. weiß ich den Header, weiß

    ich auch die Länge des Telegramms. Würde das die Sache vereinfachen?


    Danke mal im Voraus...


    Gruß

  4. #34
    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

    bzw. Fehlermeldung 16#80b1 wenn ein Telegramm vom PC kommt.

    Dieses Phänomen ist erst weg, wenn ich min. 8 Byte RECV angebe.

    Weiß jemand warum das so ist/sein kann?

  5. #35
    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

    Hab gerade noch mal bei Siemens nachgesehen. Da steht, das nicht alle CPs das Byteweise abholen aus dem Empfangspuffer erlauben. Evtl. hast Du so ein Teil erwischt

    Es schickt ca. 7 verschiedene Telegramme mit teilweise verschiedenen
    Längen. Header sind aber im 8 Zeichen. Und die Telegramme mit gleichem
    Header sind auch immer gleich lang bzw. weiß ich den Header, weiß
    ich auch die Länge des Telegramms. Würde das die Sache vereinfachen?
    Na logisch !

    Die Länge Deines Headers ist ja anscheinend immer 8 Byte lang. Den holst Du Dir mit einem Empfangsauftrag ab. (ab 8 Bytes scheint das mit Deinem CP ja zu funktionieren)
    Daraus ermittelst Du dann die Länge des Telegramms. Dann rufst Du noch einmal den Receive-FB auf und trägst als die Empfangslänge die Restlänge des Telegramms ein (Den Header hast Du ja schon abgeholt) Dieser Auftrag holt dann den Rest des Telegramms ab. Fertig

  6. #36
    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

    Hallo Grubba,


    hab das mal so probiert, mit den 2 AG_RECV Bausteinen. Bringt er aber immer Fehlermeldung. Wie du schon gesagt hast, kann es sein, dass das nicht mit jedem CP geht?

    Hab ne 343-1 Lean --> also die Sparversion quasi...


    Weiß jemand ob das mit der Karte überhaupt geht?

    Weil wenn ich ein 27 Byte Telegramm zur SPS schicke und mit dem ersten AG_RECV nur 8 Byte abfrage, geht dieses direkt auf Fehler und speichert die 8 Bytes auch nicht in den angegebenen Datenbereich?!


    Grüße

  7. #37
    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

    Du hast doch geschrieben:
    Hab das mal so probiert. Mein Problem ist jetzt nur, bei RECV
    P#DB6.DBX2.0 BYTE 8 funktioniert das wunderbar.
    Also geht das doch mit den 8 Byte ?

  8. #38
    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

    Ja richtig. Aber da hatte ich nur 1 AG_RECV verwendet, der die Daten dann im 8 Byte Rhytmus abgeholt hat.

    Jetzt mit dem 2ten AG_RECV holt der erste vom Telgramm garnichts mehr ab, obwohl der 2te noch garnicht aktiv geschaltet ist.(habe die 2 AG_RECV gegeneinander verriegelt)

    Hab sonst aber auch nichts verändert.

    An was könnte das liegen? Die ID und LADDR etc. müssen ja bei den beiden AG_RECV gleich sein oder? Habe lediglich die Parameter RECV ERROR STATUS und LEN mit anderen Variablen gefüttert?!

  9. #39
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.224
    Danke
    533
    Erhielt 2.698 Danke für 1.950 Beiträge

    Standard

    Versuchs mal mit einem AG_RECV und mach die LEN Variablel. Vielleicht paßt bei der Verriegelung etwas nicht und in deinem Fall müßte es eigentlich auch mit einem AG_RECV funktionieren.

    PS: Ich denke, bei dem Umschalten zwischen 2 Bausteinen, muß man sehr vorsichtig zu werke gehen. NDR ist einen Zyklus da. Umschalten darf man wahrscheinlich erst, wenn der Baustein, sein NDR auch wieder zurückgesetzt hat, also frühestens einen Zyklus später.
    Geändert von Ralle (19.06.2009 um 09:58 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. #40
    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


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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?

Ä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
  •