29.09.2010 18:37 | |
Beiträge: 8 Bewertung: (0) |
Hallo liebes Forum, ich doktor hier schon einige Zeit an einer Verbindung zwischen den beiden o.g. Steuerungen herum. Einiges habe ich schon zum Laufen gebracht, eine wichtige Sache allerdings noch nicht. Ich habe die Kommunikation zwischen der Profinetschnittstelle und der CoDeSyssteuerung über FB63, FB64, FB65, FB66 lauffähig und kann Daten übertragen. Das funkioniert tadellos! Hierbei habe ich mich an die BeitragsID 29737950 gehalten. Nun möchte ich das ganze gerne noch über die selbe CPU aber in Verbindung mit dem CP343-1-IT Modul umsetzten. Anbei ein Screenshot meiner Hardwarekonfiguration. Ich habe die Verbindung in NetPro konfiguriert. Ich weiß, dass ich hierfür andere Bausteine benötige FC5 (AG_SEND) und FC6 (AG_RECV). Das Management des Verbindungsauf- und abbaus wird hier ja vom CP-Modul selbst gehandhabt. Ist es richtig, dass (vorrausgesetzt die Verbindung ist korrekt in NetPro konfiguriert) ich in der "Spezialdiagnose" des CP-Moduls sofort eine korrekt aufgebaute Verbindung erkennen kann (selbst ohne weitere Programmteile)? Adresseinstellungen: CPU PN: 192.168.0.1 CP343: 192.168.0.10 CoDeSys: 192.168.0.2 Ich möchte über den Port 2000 kommuizieren. Leider sehe ich in der "Spezialdiagnose" des CP-343-1-IT die Meldung "Passiver Verbindungsaufbau läuft" oder bei Änderung in eine aktive Verbindung "Abgebaut". Ich habe auch schon mit den Einstellungen herumgespielt und die Verbindung von "TCP-Verbindung" auf "ISO-on-TCP" umgestellt (um das CoDeSysProgramm gleich zu lassen da die ISO-on-TCP Verbindung via PN Schnittstelle tadellos funktioniert!). Hier habe ich bei der lokalen TSAP in der HEX-Eingabe die führenden Bytes E0.02. eingefügt. Beim Partner habe ich die 2000 (dez) nicht verändert.Ich habe auch schon versucht die führenden Bytes auf E0.04. zu ändern da mein CP-Modul auf Steckplatz 4 montiert ist. Ich habe in meiner Verzweiflung auch schon die CoDeSys Steuerung deaktiviert und versucht via Hyperterminal eine Verbindung aufzubauen. Der Weg meiner Versuche ist mit Misserfolgen gepflastert! Anbei mein S7-Projekt. Vielleicht kann sich jemand einen Reim darauf machen wieso mein Vorhaben scheitert. Dankeschön Grüße BKow DateianhangTcp_s7_c.zip (192 Downloads) |
30.09.2010 14:01 | |
Beigetreten: 01.08.2007 Letzter Bes: 29.08.2024 Beiträge: 1698 Bewertung: (84) |
Hallo, wenn die Client -Station (CoDeSys)nicht im gleichen Projekt liegt, muss man eine unspezifizierte Verbindung in der S7-CPUeinrichten. Hier ein FAQ für eine ISO on TCP Verbindung mit den Send/Receive Bausteinen(FC5/6) Hier eine Beschreibung für eine unspezifizierte VerbindungalsS7 - Verbindung Gruß Eleu ------------------------------ Ergänzung und ISO on TCP in S7-Verbindung geändert: Wenn Du eine ISO on TCP - Verbindung projektierst wird m. Wissens standardmäßig der Port 102 für die Kommunikation verwendet. Wenn Du selber Port Adressen vergeben möchtest kannst Du z.B. eine TCP-Verbindung projektieren. |
Zuletzt bearbeitet von: Eleu am: 30.09.2010 14:46Zuletzt bearbeitet von: Eleu am: 30.09.2010 14:43 |
|
Für diesen Beitrag bedanken sich1 Benutzer |
01.10.2010 06:57 | |
Beigetreten: 01.08.2007 Letzter Bes: 29.08.2024 Beiträge: 1698 Bewertung: (84) |
Hallo, hier meine Idee. Ich habe das erst kürzlich selber noch probiert und dasbei mirnoch mal kurz aufgebaut. Die Kommunikation Hyperterminal <-> S7 SPS funktioniert bei meiner Teststellung Im Anhangdas S7-Projektinkl. die Verbindung mit Hyperterminal als Datei. Im S7 Projekt müsstest Du in der HW-Konfig die CPU und denCPtauschen In der Verbindungsprojektierung die IP-Adressen. (In der gespeichertenTelnet Verbindung auch) Wenn Du dann die Bausteine in die CPU lädst und die Telnet Sitzung startest musst Du nur noch über die VAT 1 im Projekt irgendwelche Zeichen in DB201.DBB0 - 7 übertragen. Diese Zeichen müssten dann im Hyperterminal im Sekundentakt angezeigt werden.
Wenn das damit nicht geht, muss es m.E. an der Konstellation mit der PN CPU liegen. Vielleicht muss man da bei zusätzlichen CP`s auch mit T-Bausteinen arbeiten ???? Viel Erfolg. Melde dich mal zurück, ob es geklappt hat. Gruß Eleu DateianhangSend_Receive.zip (182 Downloads) |
Für diesen Beitrag bedanken sich1 Benutzer |
01.10.2010 13:33 | |
Beiträge: 8 Bewertung: (0) |
Hallo Eleu! super! Vielen vielen Dank! Es funktioniert mit deinem Projekt sofort. Einzigster Unterschied zu meinem Projekt ist, dass du keine Partner IP-Adresse und Port eingestellt hast im NetPro.Das scheint des Rätsels Lösung zu sein! Ich kann jetzt Daten von S7 zur CoDeSys Steuerung übertragen. Die CoDeSys Steuerung spiegelt die einkommenden Daten und schickt Sie wieder raus (8Byte). Leider habe ich jetzt noch einen Fehler am AG_RECV Baustein Fehler 16#8184 Error=TRUE. Ich habe zufällig ein anderes Post von dir gefunden wo du das selbe Problem hattest Post von Eleu.Wie ich sehe hast du die Änderung des Eingangs "RECV" schon in dein Beispielprojekt das duhier gepostetschon einfließen lassen. Das original Projekt von Siemens nutzt hier wenn ich mich recht erinnern kann ein ANY Pointer. Ich habe somit 8 Bytes des Arrays "RCVBLK" am Eingang "RECV" anliegen. Hast du hier noch eine Idee woran es klemmen kann? Habe auch schon versucht den Eingang "RECV" in ein Merkerbereich zu legen oder in ein DB. Auf der CoDeSys Seite schicke ich stets nur 8 Byte (ich hoffe später sind hier auch mehr möglich?) Grüße und nochmals vielen Dank BKow |
05.10.2010 08:18 | |
Beigetreten: 01.08.2007 Letzter Bes: 29.08.2024 Beiträge: 1698 Bewertung: (84) |
Hallo BKow
8184 bedeutet das ein unzulässiger Datentyp für den Parameter RECV angegeben wurde. Mit meinem Clientklappt es mit dem Senden zum Server (SPS) ? Hierbei kann ich immer 8 Byte senden.. Wichtig: Bei TCP/IP muss die Nutzdatenlänge im Datagramm genau so groß sein, wie der projektierteEmpfangsbuffer Andernfallskommen die Daten unkoordiniert, hintereinander gereiht in der SPS an. Wenn Du die Größe des Empfangsbuffer vergrößern möchtest, kannst Du dasdirekt bei der lokalen Variable#RCVBLKim FB200 indem Du das Array 0..7 einfach vergrößerst. Vielleicht noch ein Tipp: Ich habe bei meinen Teststellungen herausfindenkönnen, dass bei einer projektierten UDP Verbindung die Längeder gesendetenNutzdaten vom Clientkleiner sein dürfen als der projektierte Empfangsbuffer. Die ankommenden Daten werden immer amAnfang des projektierten Bereicheseingetragen. Was das angeht, ist alsoeine UDP-Verbindung m.E.unkritischer. Wieso das bei UDP geht und beiTCP/IP nicht, weiß ich nicht genau. Ich vermute, es liegt daran, dass bei UDP die Daten paketorientiert übertragen werden, und nicht wie bei TCP/IPstreamorientiert. Vielleicht kann das jemand genauerklären ? Man muss bei einer UDP-Verbindung beachten, dass man imDB vom BeispielprojektIP und Port Adresse eintragen muss. Also für das Senden von der SPS -> Client.Hier ein Link dazu. Wenn Du mit deiner CoDeSys auch eine UDP Verbindung erstellen kannst, würde ich dir das empfehlen. Ist CoDeSys ein PC als SPS ? Welche Hochsprache verwendet CoDeSys denn ?
Gruß Eleu |
Zuletzt bearbeitet von: Eleu am: 05.10.2010 08:27 |
|
Für diesen Beitrag bedanken sich1 Benutzer |
05.10.2010 13:01 | |
Beiträge: 8 Bewertung: (0) |
Hallo Eleu, CASE switch OF 2: [/code] |
Zuletzt bearbeitet von: BKow am: 05.10.2010 13:54Zuletzt bearbeitet von: BKow am: 05.10.2010 13:16 |
|
Folgen Sie uns auf