# S7 über Ethernet an PC (spezielles Protokoll)



## Hocheck (16 Februar 2010)

Hallo Liebe Community,

Sitze schon seit längerem an einem Tech-Projekt, das ziemlich viel im Bereich Simatic beeinhaltet.

Ich stehe nun wieder mal vor einem rießigen Berg von Fragezeichen
Es wird einfach gewiss daran liegen dass mir die technischen Grundlagen im Bereich Bussysteme fehlen...

Das Thema: S7 Verbindung über Ethernet an ein spezielles PC-Interface

Hardware: CPU variabel, gerne eine 315 DP/PN oder eben eine CPU mit CP
Bussystem: Ethernet
Protokoll: TCP, Ich habe mehrere TCP-Protokolle zu übertragen, beschränken möchte ich mich aber auf die ersten beiden:

1. Startprotokoll 12 Byte
2. Dateninformationsprotokoll 38 byte

Das Startprotokoll dient der Verbindungsaufnahme
Im Dateninformationsprotokoll möchte ich gerne Daten übertragen aus der SPS auf den PC. Leider kann ich an der Struktur der Protokolle nichts ändern, da das verwendete Interface die nur so "aufnimmt".

Habe noch die Socketnummer

Ich hoffe euch reichen die Informationen und es ist verständlich was ich machen möchte...


Jetzt nur meine Fragen:

1. Ist sowas überhaupt möglich, dass man von der S7 in einem gewissen Protokoll (Wie oben, ohne dies zu verändern) senden kann? Wenn ja wie? Wenn nein, welche alternative hätte ich?

2. Wäre so etwas auch über die Integrierte Ethernetschnittstelle eines Multi Panels möglich (über Visual Basic Script)?

3. Wenn mir die technischen Grundlagen fehlen (wovon ich ausgehe) gibt es irgendwelche guten Homepages (außer Wiki, da war ich) die mir weiterhelfen könnten- vielleicht FAQs von Siemens selbst(habe leider dazu nichts richtiges gefunden)


Ich hoffe wirklich das die Angaben reichen und mir wer hilft...

Gruß Hocheck


----------



## Hocheck (17 Februar 2010)

Hallo,

Habe folgenden Beitrag von Siemens gefunden:
ID 18843927
http://support.automation.siemens.c...objaction=csview&extranet=standard&viewreg=WW

Bringt mich sowas weiter? Ich versteh einfach immer noch nicht, wie ich die Daten so sende wie mir das Interface Protokoll vorgibt...


----------



## Grubba (17 Februar 2010)

Zu 1.
Ja, Du kannst beliebige Telegramme an einen PC versenden. Der Telegrammaufbau ist von Dir frei definierbar.

Zu 2.
Kann ich nicht sagen, aber so ein Panel kann schon von sich aus auf die Daten der Steuerung zugreifen

Zu 3.
Wenns darum geht, wie Du die Verbindung aufbaust, Daten sendest etc. ist die Online Hilfe von Step 7 ganz OK. Grundsätzliches zum Netzwerkaufbau oder über TCP/IP als solches findest Du dann wohl im INet. Google ist da Dein Freund.

Zum Schluss gibts auch noch die Möglichkeit, mittels einer freien Software (Libnodave, 10.000 Einträge nur hier im Forum) vom PC aus auf die S7 zuzugreifen. Der Vorteil ist, dass die SPS in diesem Fall garnichts machen muss. Der PC schreibt und liest dann ganz alleine ohne zutun der SPS.


----------



## Lars Weiß (17 Februar 2010)

Hocheck schrieb:


> Hallo,
> 
> Habe folgenden Beitrag von Siemens gefunden:
> ID 18843927
> ...



Ja, das würde dich weiter bringen. Beschreib doch mal was dein "Interface Protokoll" vorgibt.


----------



## Hocheck (17 Februar 2010)

@ Grubba 
Danke für deine schnelle Antwort.
Könntest du mir bitte irgendwie ein Beispiel oder so zeigen, wenn das nicht zu viel Aufwand wäre? Ich finde leider einfach nichts was ich so verwerten könnte...

Habe bei Siemens nun die Möglichkeit gefunden, dass man über die Bausteine FB 63 TSEND, FB 64 TRCV Daten tauschen kann. Dazu muss man den FB 65 TCON mit UDT 65 Parametrieren. Aber irgendwie wüsste ich nicht wie ich da ein eigen definiertes Protokoll erstellen sollte...

Zu den theoretischen Dingen- Habe mich heute den gesamten Tag eingelesen und viele Dinge rund um den Aufbau TCP/IP  OSI schicht usw gelernt... Jedoch bringt mir das nicht den nötigen Ansatz um irgendwie einen Anfang zu bekommen...


----------



## Grubba (17 Februar 2010)

> Habe bei Siemens nun die Möglichkeit gefunden, dass man über die Bausteine FB 63 TSEND, FB 64 TRCV Daten tauschen kann. Dazu muss man den FB 65 TCON mit UDT 65 Parametrieren. Aber irgendwie wüsste ich nicht wie ich da ein eigen definiertes Protokoll erstellen sollte...
> 
> Zu den theoretischen Dingen- Habe mich heute den gesamten Tag eingelesen und viele Dinge rund um den Aufbau TCP/IP OSI schicht usw gelernt... Jedoch bringt mir das nicht den nötigen Ansatz um irgendwie einen Anfang zu bekommen...


 
Also:

So ganz einfach in ein paar Sätzen ist das Ganze wohl nicht so einfach zu erklären, deshalb hier nur ein grundsätzlicher Aufbau:

Jetzt aber mal was positives vorweg:
Das Schichtenmodell zu verstehen kann zwar sehr nützlich sein, ist für Dich als User der Anwendungsschicht aber nicht zwingend notwendig.

Angenommen, die SPS soll die Verbindung aufbauen:

Hast Du eine PN-CPU (also mit integriertem Ethernetanschluss) musst du im SPS-Programm die Verbindung aufbauen. Das geht mit dem FB TCON, wie Du schon rausgefunden hast. Dieser FB benötigt natürlich Informationen über Deine Verbindung. Diese holt er sich aus einem Datenbaustein. Vorlage für den Datenbaustein ist eine Struktur vom Typ UDT65.
UDT65 ist einfach mal so als Standardvorgabe angegeben. Theoretisch kann die auch UDT12345 sein. Von Siemens gibts dazu eine PC-Software, die die Verbindungsdaten für Dich erstellt. Heisst Open Communication Wizard und ist, man glaubts ja nicht, umsonst. Kann man bei Siemens saugen.
Auf der PC-Seite benötigst Du dann einen TCP-IP Server, zu dem die SPS die Verbindung aufbauen soll. 
Steht die Verbindung, kannst Du mit den Bausteien FB 63 TSEND und FB 64 TRCV Daten senden und empfangen.

Was das Protokoll angeht:
Mit dem Sendebaustein werden i.a. Daten aus einem DB versendet. Die Datenanordnung im DB entspricht deinem Protokoll.
Sind z.B. im DB die ersten 10 Werte vom Typ Real und danach die nächsten 10 Werte Integer, werden diese Werte in einem Rutsch an den PC versendet. Dieser muss natürlich den Protokollaufbau kennen, weil er ja die Werte auf seiner Seite wieder zusammenbauen muss.

Was muss denn auf der PC-Seite mit den Daten passieren?
 Und mal so nebenbei: Musst Du auch die PC-Seite programmieren? 

Die SPS Seite ist auch ohne grosse Vorkenntnisse relativ schnell zusammengebaut. Musst Du auch die PC-Seite programmieren, und Du noch keine PC-Programmierung gemacht hast, wirds schon schwieriger.

Ich empfehle Dir mal, die Siemens Page noch mal zu löchern, der Link den Du angegeben hast, passt da schon gut. 

Zum Testen des Verbindungsaufbaus kann ich Dir ein kleines Programm vorschlagen, was einen TCP-Server bereitstellt. Zu diesem Programm könntest Du dann die Verbindung aufbauen, um zumindest schon mal das zu testen.

Link:
http://www.sps-forum.de/showpost.php?p=140305&postcount=8

Hast Du eine S7 mit extra CP, wird die Verbindung über NetPro eingerichtet. 

Poste dann nochmal, was Du hast und wo das erste Problem (von vielen) auftaucht.


----------



## Hocheck (17 Februar 2010)

Hallo Grubba diese Erklärung war wohl nun ein Meilenstein für mich:TOOL:

Mein Problem war immer zu verstehen wie ich das Protokoll erstellen soll mit dem überhaupt die Daten aus einem Datenbaustein gesendet werden können. Dass das Interface die ankommenden Daten aus einem Datenbaustein als solches (Protokoll) ansieht wusste ich nicht Dachte es würde dies nur als reine Daten (I/O) interpretieren... Hoffe du verstehst wie ich das meine...

Die Beschreibung der Protokolle werde ich also in einen DB legen und dann je nachdem was ich senden möchte dies über einen Anypointer zusammenstellen und dem FB 63 TSEND übergeben- (wenn ich alles richtig verstanden habe)

Die Verbindung erstelle ich so wie du mir freundlicherweise erklärt hast

Wie die Daten abgegriffen werden ist bereits in einem C-Programm geschreiben worden- muss ich zum Glück nicht machen, da meine C-Kenntnisse leider noch sehr beschränk sind... Das Interface dient eigentlich der Kommunikation mit einem speziellen Regler- Sollte nun im Rahmen meiner Recherche für die SPS benutzbar gemacht werden... 

Ich werde dich auf dem laufenden halten... werde bestimmt noch einige Fragen haben, aber jetzt habe ich wenigstens den Einstieg 


@ Lars:

Es gibt 20 einzelne Protokolle.. 18 Datenprotokolle (wovon ich höchstens 2 brauche) Dann noch 1 Startprotokoll und 1 Dateninfoprotokoll.
Jedem Protokoll sind 3 Byte vorgelagert.
1. Byte: Länge des Protokolls
2. Byte: Art des Protokolls (Also welches der 20 Protokolle nach dem 3. Byte folgt)
3. Byte: Sicherheitsbyte (Verwendung unbekannt)


----------



## Grubba (17 Februar 2010)

> Die Beschreibung der Protokolle werde ich also in einen DB legen und dann je nachdem was ich senden möchte dies über einen Anypointer zusammenstellen und dem FB 63 TSEND übergeben- (wenn ich alles richtig verstanden habe)



.. das klären wir jetzt lieber doch nochmal...

Der FB TSend hat einen Eingang "DATA".
Daten, die dieser FB sendet, müssen hier bereitgestellt werden, wie Du schon richtig bemerkt hast, als AnyPointer.

Angenommen, die Daten, die Du versenden möchtest, stehen in DB1. Der soll mal 20 Byte lang sein.

Die ersten 4 Werte sind vom Typ Real, und die nächsten 2 vom Typ Integer.
Dann sieht der DB1 so aus:

Startadresse  Variablenname
Byte 0          RealVar_1
Byte 4          RealVar_2
Byte 8          RealVar_3
Byte 12        RealVar_4
Byte 16        IntVar_1
Byte 18        IntVar_2

oder so ähnlich.

Willst Du alles in einem Rutsch versenden, musst Du als Länge 20 angeben (Eingang Len) und der Eingang Data wäre P#DB1. DBX0.0 BYTE 20.

Dann wird der DB mit dieser Struktur versendet und in dieser Reihenfolge kommen sie dann auch am PC an. Der PC muss sich dann auch an diese Reihenfolge halten, sprich er muss wissen, das die ersten 4 Bytes die er bekommt, die Variable RealVar_1 bilden. 
Wie Du die Daten im DB anordnest kannst Du Dir ja aussuchen, sprich Dein eigenes Protokoll festlegen.


----------



## Hocheck (18 Februar 2010)

Hallo,

erst einmal vielen Dank für die Klarstellung...

Hätte da schon das erste Problem...

Verlangt werden folgende Datentypen auf Interface Seite:

Protokolllänge = 1 Byte, vorzeichenlose Ganzzahl
Protokollart = 1 Byte, vorzeichenlose Ganzzahl
Zeittrigger = 6 Byte vorzeichenlose Ganzzahl
Information = 23 Byte ASCII Zeichen
Datum = 8 Byte Gleitkommazahl

Nun stellt sich die Frage wie passt das mit den Datentypen der S7 überein?!
Die Integer Variablen der S7 haben ja 16 bit- Wie mach ich aus einer S7 INT (16 bit) eine Ganzzahl (8 bit vorzeichenlos)?! Ohne dass der andere Teil einer INT Variable schon als neue 8 bit Ganzzahl interpretiert wird... 

Und wie verhält sich das mit dem ASCII Zeichen? Die haben ja 7 bit...




Hätte jetzt gedacht (DB):
Adresse          Name              Typ                 Anfangswert
0.0                   Länge              Byte                B#16#0
1.0                   Art                    Byte                B#16#0
2.0                   Trigger             Byte                ???
3.0                   Trigger             Byte                ???
…
8.0                   Trigger             Byte                ???
9.0                   Info                 char oder string?!


----------



## Grubba (18 Februar 2010)

> Zeittrigger = 6 Byte vorzeichenlose Ganzzahl
> Information = 23 Byte ASCII Zeichen
> Datum = 8 Byte Gleitkommazahl



Was die ASCII Zeichen angeht, kann ich Dich beruhigen, die haben schon 8 Bit, also  1 Byte.
Die ASCII Zeichen kannst Du einfach als Bytes darstellen. Dann per kleinem Algorithmus den Byte-Wert des Zeichens ermitteln.

Tja, mit den Ganzzahlen hörts bei der S7 bei 4Byte (DINT) auf.

Die 8 Byte Gleitkommazahl kann die S7 natürlich auch nicht, der Typ Real hat auf S7 Seite nur 4 Byte.

Da die S7 ohnehin nur mit maximal 4 Byte breiten Datentypen arbeitet, stellt sich zumindest mir erstmal die Frage, welche Werte ihr denn aus der S7 rausbekommen wollt, die z.B. 6 Byte breit sind. Denn dann müsstest Du ja schon auf der S7 mit solchen Zahlen hantieren.

Z.B. die 6 Byte breite Ganzzahl. Schon auf der SPS müsstest Du die Standard-Datentypen verlassen und dir eigenen Funktionen bauen, die mit einer 6Byte breiten Zahl arbeiten. Macht das Sinn oder möchte der PC-Mensch einfach nur seinen PC-Datentyp erhalten?

Wenn das nicht nötig sein sollte, sende dem PC doch einfach nur 4Byte breite Ganz und Fließkommazahlen, die auf dem PC zu wandeln ist eine Zeile Code.

Wenns aus irgendwelchen Gründen doch nötig sein sollte, kann man sich natürlich auch ein solches Format selber basteln. Dazu müsstest Du den gewünschten Wert selbst in 6 Byte stückeln und diese Bytes manuell auf die 6 Bytes im DB verteilen.


Das würde ich an Deiner Stelle erstmal klären.


----------



## Hocheck (19 Februar 2010)

Werde das klären wegen den Datenformaten... da hast du vollkommen recht!

Aber zum Verständnis nochmal…Also du meinst dann folgendes:
Wenn man zum Beispiel 1 Protokoll mit:
Protokolllänge = 1 Byte, vorzeichenlose Ganzzahl
Protokollart = 1 Byte, vorzeichenlose Ganzzahl
Information = 23 Byte ASCII Zeichen
Nehmen würde, dann sähe das im DBXX so aus?!:
Adresse        Name          Typ              Anfangswert
0.0               Länge           Byte             B#16#0
1.0               Art               Byte             B#16#0
2.0               Zeichen_1     Byte             B#16#0
3.0               Zeichen_2     Byte             B#16#0
…
25.0                       Zeichen_23    Byte             B#16#0
 
Ausführlich deklariert würde das Protokoll dann in AWL so zusammengestellt und sollte TEST übertragen:
//Sync
L              B#16#1A             //1Ah = 26 Byte Protokolllänge
T             DBXX.DBB 0
L              B#16#0                // Art 0 gleich dieses Protokoll
T             DBXX.DBB 1
//Info Hex Zahlen aus ASCII Tabelle
L     B#16#54                     //54hex ASCII Zeichen für T   
T     DXX.DBB  2              
 L     B#16#45                     //45hex ASCII Zeichen für E 
T     DBXX.DBB    3              
 L     B#16#53                     //53hex ASCII Zeichen für S   
 T     DBXX.DBB    4              
 L     B#16#54                     //54hex ASCII Zeichen für T 
 T     DBXX.DBB   5      
 L     B#16#0                     //54hex ASCII Zeichen für \0 
 T     DBXX.DBB   6     
//Ende

Die Antwort des Interfaces könnte erfolgen und ich könnte mit Hilfe von AWL die gesendeten Hex Zahlen wieder abfragen und rausfinden welche ASCII Zahl gesendet wurde… Stimmt das so?


----------



## Grubba (19 Februar 2010)

Das ist so korrekt, denke ich mal.

Wie Du siehst, wird alles gut....


----------



## Hocheck (22 Februar 2010)

Danke dir 

Werde das erstmal so umsetzen und dann schauen wie es funktioniert.
Habe mit dem Verbindungswizard schon mal eine Verbindung hergestellt und sobald ich die Möglichkeit habe möchte ich mal den Laptop mit der 315 PN verbinden.. Dazu würde ich das Connection Programm von dir benutzen (Danke dafür!)

Habe noch 2 Bilder angehängt, wo der UDT konfiguriert wird... Könntest du da mal kurz drauf schauen ob dies korrekt ist?

Bin folgendermaßen vorgegangen:

Habe wie von dir beschrieben den Kommunikations- Wizard heruntergeladen und bin folgendermaßen vorgegangen:
1. Neue Verbindung
2. ISO on TCP 
3. Nur Kommunikationspartner A und Kommunikationspartner ist keine S7 CPU
Ab dann siehe Bilder

Partner B soll der PC sein mit dem Port 3000 von deiner Connection Software
Für die S7 315 PN habe ich den Port 2000 (Siemens??) angegeben
Ist das dafür richtig parametriert oder muss bei Kommunikationspartner B unter Lokale TSAP-ID ein hacken hin?

Der Unterschied Passiv oder Aktiv bezieht sich doch darauf welcher Teilnehmer die Verbindung aufbauen soll, oder?


----------



## Grubba (22 Februar 2010)

> Habe wie von dir beschrieben den Kommunikations- Wizard heruntergeladen und bin folgendermaßen vorgegangen:
> 1. Neue Verbindung
> 2. ISO on TCP
> 3. Nur Kommunikationspartner A und Kommunikationspartner ist keine S7 CPU
> ...



Als Verbindung mußt Du TCP native auswählen. ISO on TCP ist eine Erweiterung des TCP Protokolls und wird nicht direkt vom PC unterstützt, wenn man es mal einfach beschreiben soll. Dazu würde man (meines Wissens nach) auf PC Seite einen Treiber brauchen. Unterschied zum "normalen" Protokoll ist der, dass bei ISO on TCP die Länge der Sendedaten mit übertragen werden.

*Dann im nächsten Menu:*
[x]  Nur Kommunikationspartner A projektieren
[x]  Kommunikationspartner B ist  keine S7 CPU 
auswählen.

*Im nächsten Menu:*
Komm-Partner A: 
Aufbau : Aktiv
und die Schnittstelle auswählen.

Komm-Partner B:
Die IP des PC eintragen

*Im nächsten Menu:*
Komm Partner B:

Portnummer eintragen, z.B. 2000. Dez. kann so bleiben.

*Im nächsten Menu:*
Namen vergeben und fertig.


----------



## Hocheck (27 Februar 2010)

Vielen Dank Grubba!
Konnte nach deiner STEP by STEP Methode eben endlich mal nach längerer Pause eine Verbindung aufbauen!!! funktioniert bestens mit TCON...

 Benutze nun noch Jochens SPS Tester (zu finden hier im Forum) womit ich die Daten am PC empfangen und auch senden kann… Hatte nun damit vorgehabt ein Protokoll zu Testen, da ich das 
Interface nicht auf dem PC installiert habe.

Nur wieder Probleme mit den Datentypen..

Habe in einem DB verschiedene Variablen deklariert, die ich über TCP an den PC senden möchte.
BSP
Adr.                       Typ                        Anfangswert
0.0                         Bool                      True
0.1                         Bool                      True
0.2                         Bool                      True
0.3                         Bool                      …
0.4                         Bool
0.5                         Bool
0.6                         Bool
0.7                         Bool                      True
1.0                         Byte                      B#16#31
2.0                         Int                          1
4.0                         String[1]                 ‚1‘

Die Bool Operanten (Alle True = 255) bilden zusammen dieses  y Zeichen von der ASCII Tabelle (Wert 255 dez)
Das Byte 1 liefert das ASCII Zeichen 1 (wie gewollt)

Und der String Operant liefert eine 1 im SPS Tester (auch ASCII?!)


Die Int Variable wird garnicht geschrieben.

Kann es dann einfach sein, dass der SPS Tester nur auf ASCII Zeichen reagiert?!
Wenn das der Fall ist wäre meine Frage fast schon beantwortet.

Nur das Interface dass ich ansprechen muss braucht ja auch eine1 Byte Ganzzahl (vorzeichenlos) mit Wert 33.
Kann man dann einfach Byte: B#16#21 angeben und das Interface schnallt das, oder wird das wieder als ASCII Zeichen interpretiert?


Hoffe du verstehst was ich meine... Konnte mit den zugehörigen Programmierern sprechen, die können nämlich das Interface nicht ändern, da es sonst konflikte mit den anderen Bauteilen gibt...


Sonst funktioniert das prima =) Vielen Dank dir!!


----------



## Grubba (1 März 2010)

> Und der String Operant liefert eine 1 im SPS Tester (auch ASCII?!)


 
Bei Strings auf der S7 musst Du aufpassen. Hast Du z.B. den String "HALLO", hätte der auf der S7 von 5+2 Byte. 5 Byte für das "HALLO" und 2 Byte für zusätzliche Information. Die S7 stellt jedem String 2 Bytes voran, in einem steht die maximale Länge, im anderen die aktuelle Länge des Strings. 
Erhältst Du also eine 1 ist das durchaus richtig, da die aktuelle Länge (als auch die maximale Länge) 1 ist. Befrag mal die STEP7 Hilfe nach Datentyp STRING.



> Die Int Variable wird garnicht geschrieben.



Schreib doch in die INT Variable mal einen anderen Wert. Vielleicht erkennst Du dann im Empfangstelegramm irgendwo eine Änderung der Daten. Vielleicht ist die 1, von der Du glaubst sie sei der String, doch die Integer Variable?



> Kann es dann einfach sein, dass der SPS Tester nur auf ASCII Zeichen reagiert?!
> Wenn das der Fall ist wäre meine Frage fast schon beantwortet.



Die Empfangsseite weiss ja erstmal garnicht, welchen Datentyp sie empfängt. Ein Byte kann ein ASCII Zeichen darstellen, oder ein Bitfolge oder einen Ganzzahlwert oder oder...
Deshalb muss der Empfänger auch wissen, an welcher Stelle im Telegramm er welche Daten welchen Typs vorfindet. 

Den SPS-Tester hab ich nicht gefunden, stell doch mal den Link rein. 



> Hoffe du verstehst was ich meine... Konnte mit den zugehörigen Programmierern sprechen, die können nämlich das Interface nicht ändern, da es sonst konflikte mit den anderen Bauteilen gibt...


*ROFL*


----------



## Hocheck (1 März 2010)

Ok hast recht, ich glaube die wollen das Interface einfach nicht ändern

unten als Anhang das nette Programm... Wie gesagt, ich kann wohl nur Bytes, Strings und chars darein übertragen- werden dann von dem Proggi als ASCII Zeichen interpretiert...


----------



## Grubba (1 März 2010)

Das Programm startet bei mir nicht, bzw. wirft nen Fehler.

Hab dir mal eine geänderte Version vom Connect-Programm angehängt, ist zum spielen ganz nützlich.

Zeigt dir byteweise die Empfangsdaten an, denke mal, dass der SPS-Tester das auch macht.

Probiers evtl. mal aus, und stell mal nen Screenshot rein, dann kann man sehen, wo was empfangen wird.


----------



## thomass5 (1 März 2010)

wollte mir gerade das Prog mal ansehen, und dann dies:


----------



## Grubba (2 März 2010)

Hmmm...

Kann ich Dir nicht erklären 

Kann nur versichern, das da keine Viren, Spyware oder was auch immer drin sind.
Habs gerade auch noch mit McAffee (aktuelle Version, da automatische Updates auf Firmenrechner) scannen lassen, der hat nichts gemeldet.
Hört sich vielleicht arg doof an, das ich das eigenen Prog scannen lasse, aber wer weiss schon, ob sich nicht doch was auf den eigenen Rechner geschlichen hat. Also von meiner Seite ist alles I.O.


----------



## Oberchefe (2 März 2010)

> Kann ich Dir nicht erklären



Die Meldung kommt bei der connect.exe auch schon, denke mal daß das Programm, was das Öffnen von Ports angeht, ein Verhalten ähnlich dem gemeldeten Trojaner an den Tag legt.


----------



## thomass5 (3 März 2010)

Hallo,
werd mir heute mal mit einer virtuellen Maschine die Datei runterladen. Die Meldung kam schon, als ich die zip-Datei runtergeladen habe.
Thomas


----------



## Hocheck (9 März 2010)

Danke für die Hilfe…

Konnte nun einiges erreichen… Habe ein Programm zum schauen auf den Bus installiert und kann somit die ankommenden Ethernet Telegramme anschauen. (alles für ein Telegramm) 
Jetzt soll ich ja die unterschiedlichen Telegramme losschicken und da kommt mal wieder ein Problem…
So sieht ein Sendevorgang aus
Telegramm 1 
Telegramm 2
Telegramm 3
Die Telegramme sollen aber auch einzeln und unabhängig voneinander versendet werden können.

Ich benutze ja die T-Bausteine. Dann war mein erster Lösungsansatz, dass ich mir eine Any-variable erstellt habe, diese habe  ich anhand einer Schrittkette erst für Telegramm 1 deklariert und anschließend einen Merker am REQ Eingang des TSEND Bausteins gesetzt. Das erstellte Programm wurde gesendet. Über einen Merker am DONE Ausgang habe ich den 2. Schritt der Schrittkette eingeleitet und den REQ  Merker zurückgesetzt. Nun wird das 2. Telegramm in den Any-Pointer geladen und ein REQ erneut gesetzt bis der DONE Ausgang kommt usw…

Nur das Problem: 
Gesendet wird das Erste Protokoll vollständig, aber die folgenden 2 werden mit einer willkürlichen Bytezahl über den Bus versendet. Sogar manchmal ein Telegramm 4 mal hintereinander.
Getestet habe ich die Anypointer  Auswahl mit einem Blockmove schon und dieser hat funktioniert…


Daraufhin habe ich dann die nächste Variante versucht und einfach 3 TSEND Bausteine eingefügt. Diese absolut mit einem Pointer versehen. Einen Merker zum REQ des ersten TSEND erstellt. Die anderen beiden TSEND Bausteine werden über den jeweils vorherigen DONE Merker gesetzt, der auf den folgenden REQ geht.

Was läuft da schief?


----------



## Grubba (9 März 2010)

Hast Du auch den Parameter LEN angepasst und nicht nur den Pointer?


----------



## Hocheck (9 März 2010)

Hallo,

Jap da habe ich auch einfach immer eine INT Variable #LEN genommen und diese halt immer am Ende der Anypointer deklaration mit geschrieben...


----------

