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

Seite 4 von 4 ErsteErste ... 234
Ergebnis 31 bis 34 von 34

Thema: ISO-On-TCP zwischen CP343-1 und PC

  1. #31
    jeito ist offline Neuer Benutzer
    Themenstarter
    Registriert seit
    31.10.2008
    Beiträge
    8
    Danke
    0
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Auf der PC-Seite verwende ich die 10 ISO8073-TPDUs (preferred Class 0). Die entsprechenden Sequenzen für "open request", "connection request", "data exchange" und "close connection" mit den zugehörigen Fehlerbehandlungssequenzen habe ich aus dem Siemens-Handbuch übernommen, jeweils für PC->S7 und S7->PC.

    @argv_user:
    Danke für den Hinweis! Jetzt dämmerts bei mir auch, dass die TSAP-Adressierung in den TPDU-Headern alleine nicht ausreicht, um die Daten aus der S7 auszulesen. Bitte auch nicht hauen: Ich hatte in der Tat den ersten Teil im Handbuch "Send/Receive-Schnittstelle" etwas flüchtig durchgelesen und mich mehr auf die Sequenzen gestürzt. Jetzt wird mir auch klar, dass man durch die entsprechende DB-Adressierung u.U. auch die FC5 und FC6 bei "S7 passiv" weglassen kann, wie es anfangs von dir vorgeschlagen wurde.

  2. #32
    Registriert seit
    10.06.2009
    Beiträge
    64
    Danke
    36
    Erhielt 24 Danke für 13 Beiträge

    Standard

    Hallo jeito

    > Ein paar Hintergründe zu meinen Fragen:
    > Das mit "PC=aktiv" und "S7=passiv" war eine Projektvorgabe: ich
    > programmiere einen embedded Controller unter VxWorks, der nur über
    > einen Ethernet-Port mit der "Außenwelt" verbunden ist. Darüber soll er
    > gesteuert werden (in diesem Fall von einer S7) und auch Messdaten
    > senden (an die S7). Die S7-Umgebung ist Neuland für mich. Es geht mir
    > hier nur um den Datenaustausch von Steuer- und Messdaten, die ich
    > irgendwie simulieren, d.h. auch verändern muss.

    OK, jetzt wird' klarer

    Die S7 kommandiert, der Controller soll was tun.
    In diesem Fall würde ich die S7 zum client und den Controller zum Server machen.

    Ich denke auch, Du ersparst Dir einiges wenn Du in diesem Fall trotzdem Send-Receive nimmst, denn dann brauchst Du keines der Server-Protokolle zu realisieren sondern kannst einfach Rohdaten schieben.
    Was darin steht, ist dann deine Sache und Du kannst sie interpretieren wie Du willst. ( Eine Sende-Anforderung für Parameter xx, z.Beispiel, also quasi ein Fetch )

    Wichtig: Verpasse den Daten einen Header, damit Du sicher bist, was Du bekommst. ( Kein Mensch mit klarem Verstand würde eine Multiprozessing-Kommunikation ohne timeout programmieren - Siemens hat's getan.
    Irgendwo hier läuft eine Parallel-Diskussion zum Thema variable Datenlänge, sollte für Dich auch interessant sein. )

    Auch hier der Vorteil von S7 als Client (per Send): Wenn die S7 beim Controller 20 Bytes bestellt hat, dann erwartet sie eben .. 20 Bytes - womit das Telegrammlängenproblem beim Receive gelöst wäre.

    > @heisch:
    > D.h., der Client muss wissen, welchen DB er aus der S7 ausliest, wenn er
    > Daten anfordert? Dazu müsste ich die Speicheradresse wissen und bei der
    > Anfrage mitsenden (ähnlich wie bei Modbus). Falls ja, wie funktioniert
    > sowas?

    Jow, genau so. argv user hat's schon geschrieben:
    Du forderst z.B. einen DB, beginnend ab byte 4 Anzahl 20 Bytes an.
    Oder : Schreibe die folgenden Daten nach DB 12, beginnend ab byte 4 Anzahl 20 Bytes, <daten >

    Die entsprechenden Protokolle, in die das verpackt wird, sind das S7-Protokoll bzw. das S5-kompatible Protokoll.

    S5 -.. scheidet aus, denn das können die aktuellen CPs nur als server, bleibt also das S7-Protokoll .. und das ist nicht offengelegt, mußt Du also re-engineeren.
    Deshalb (s.o.) : bau Dir für den o.a. Zweck lieber selbst ein Protokoll, das geht mit Sicherheit schneller.

    > Zu deiner Homepage: Arbeiten deine convert_lib mit dlls (wie libondave)
    > oder könnte ich den Code auch für VxWorks-RTOS verwenden?

    Die convert_lib liefere ich als C-quellcode, sollte also gehen, wenn dein C-compiler nicht all zu rudimentär ist.
    ( Vor Jahren haben wir sie mal aus Jux im C-Builder eingebaut, es mußten nur die Bibliotheken-includes angepasst werden.)


    Gruss Werner
    Geändert von heisch (24.06.2009 um 00:00 Uhr)

  3. #33
    Registriert seit
    07.07.2004
    Beiträge
    3.285
    Danke
    38
    Erhielt 584 Danke für 382 Beiträge

    Beitrag

    Hallo,

    Zitat Zitat von heisch
    bleibt also das S7-Protokoll .. und das ist nicht offengelegt, mußt Du also re-engineeren.
    Aber den Begriff "LibNoDave" hast Du doch schon mal irgendwo gelesen, oder ?

    Gruß

    Question_mark
    ''Ich habe wirklich keine Vorurteile.
    Meine Meinung ist nur die Summe der Erfahrungen" ... (Question_mark)
    Zitieren Zitieren ?  

  4. #34
    Registriert seit
    10.06.2009
    Beiträge
    64
    Danke
    36
    Erhielt 24 Danke für 13 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Question_mark Beitrag anzeigen
    Hallo,



    Aber den Begriff "LibNoDave" hast Du doch schon mal irgendwo gelesen, oder ?

    Gruß

    Question_mark
    Jow, da kann er's auch raus-engineeren.

    Gruss Werner

Ähnliche Themen

  1. Antworten: 2
    Letzter Beitrag: 13.01.2011, 17:34
  2. Antworten: 5
    Letzter Beitrag: 20.04.2010, 21:09
  3. Antworten: 1
    Letzter Beitrag: 02.03.2010, 15:02
  4. Antworten: 3
    Letzter Beitrag: 27.12.2007, 19:26
  5. Antworten: 2
    Letzter Beitrag: 24.02.2006, 17:57

Lesezeichen

Berechtigungen

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