TCP/IP 343 LEAN Übertragene Daten nicht in der Richtigen abfolge

[Björn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe die Komunikation zwischen dem LMS 100 von Sick und der CPU 315 2dp mit CP343-Lean am laufen. Senden und Empfangen von Telegrammen Funktioniert.
Ich habe jetzt nur das Problem das die Daten sich in der Datenbank mit jedem Senden und Empfangen verschieben.
Ich nutze zur zeit das Beispiel von der Siemens Seite mit FC5 und FC6 und dem FB200
http://support.automation.siemens.c...ND_RCV.zip?func=cslib.csFetch&nodeid=29512338

Aussehn sollte es so im DB201
Siehe 2ter Beitrag



Bei den Kurzen Telegrammen ist das nicht so ein grosses Problem.Könnte mir ja die 02 und 03 im DB heraussuchen.02 Steht hier für Start des Telegrammes 03 für Ende des Telegramms.

Aber ich bekomme auch Daten mit einer Länge von ca 3000 Byte übertragen und da möchte ich in der DB gerne bei Adresse 0.0 B#16#02 stehn haben.
Hat jemand eine Idee woran es liegt das sich die Daten verschieben in der DB.
Was mich auch wundert ist das ich bei RECV im FC6 nicht nur einen Datenbereich von 16 Byte (Beispiel oben) zur verfügung stellen muss sondern das es ehr 20 Byte sein müssen damit der FC6 keinen Fehler 80B1H Zielbereich ungültig ausgibt.​

Braucht ihr noch weitere Infos um mir Helfen zu können?​

 

[Björn]

Hm irgentwie klappt das mit der Datenbank als Tabelle nicht
So sollte es aussehn:
0,0 B # 16 # 2
1,0 B # 16 # 73
2,0 B # 16 # 52
3,0 B # 16 # 41
4,0 B # 16 # 20
5,0 B # 16 # 4C
6,0 B # 16 # 43
7,0 B # 16 # 4D
8,0 B # 16 # 73
9,0 B # 16 # 74
10,0 B # 16 # 61
11,0 B # 16 # 74
12,0 B # 16 # 65
13,0 B # 16 # 20
14,0 B # 16 # 30
15,0 B # 16 # 3

Beispiel wie es zum Teil Aussieht
0,0 B # 16 # 4C
1,0 B # 16 # 43
2,0 B # 16 # 4D
3,0 B # 16 # 73
4,0 B # 16 # 74
5,0 B # 16 # 61
6,0 B # 16 # 74
7,0 B # 16 # 65
8,0 B # 16 # 20
9,0 B # 16 # 30
10,0 B # 16 # 30
11,0 B # 16 # 3
12,0 B # 16 # 2
13,0 B # 16 # 73
14,0 B # 16 # 52
15,0 B # 16 # 20

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ist schon eine ganze Weile her, ich glaube mich zu erinnern, daß es mit der am Receive-FC angegebenen Länge zusammenhängt. Es wird immer dort weitergeschrieben, wo das letzte Telegramm aufhörte, wenn die Länge noch nicht erreicht war. Ist die Länge erreicht, dann wird wieder am Anfang des Receive-Datenbereiches weitergemacht. Weißt du die ankommende Telegrammlänge im voraus?

 

[Zefix]

Ist in der CP der Haken für mehr als 240Byte Telegrammlänge gesetzt?

Es gibt auch noch die Long Recv und Long Send Bausteine in der Bibliothek (FC50/60 Lrecv Lsend).

Gruss Andi

 

[JesperMP]

It hatte eine ähnliches Problem, aber zwar mit TCON, TSEND usw. über den integrierte PN Schnittstelle.

Es wurde erst behoben indem das den Telegram-Länge genau angepasst wurde mit die Nutzdaten, UND nach eine Firmware Update auf den CPU.

 

[IBFS]

Zuviel Werbung?
-> Hier kostenlos registrieren

Bei fester RECEIVE-Länge OHNE zusätzliche Massnahmen kann eine
Verlust von Zeichen nur über eine Checksumme erkannt werden.
Weiterhin entsteht dabei aber eine dauerhafter Telegrammversatz.
Dieser kann nur mit den RESET, also dem Ablöschen des Buffers
mittels Reset-Eingang bekoben werden.


Da gibt es aber zwei Möglichkeiten:

1. zu Empfangene Länge auf 1 setzen

Nachteil 12 Zeichen brauchen leider 12 SPS-Zyklen bis sie im Empfangs-DB sind.


2. UDP mit Zeichenverzugszeit verwenden, Dann erhält man immer die Info wie lang der empfange Datenstrom war.
Daher ist auch kein Aufsynchronisieren nötig.

Nachteil: UPD-Pakete sind in Switchen in der Prio leider ganz unten und können verlohren gehen.

Gruß

 

[IBFS]

It hatte eine ähnliches Problem, aber zwar mit TCON, TSEND usw. über den integrierte PN Schnittstelle.

Bei PN kann man bei TCP die erwartete Länge auf NULL setzen.
Dann gibt es keinen Versatz mehr in den Daten, sondern bei
Telegrammverlust ist dann die empfangene Länge entsprechend
kürzer, was man dann maskieren kann.

 

[Björn]

Danke für die Schnellen Antworten.
Das Problem ist das ich nicht immer weiss wie Lang die Datenblöcke sind.
Bei den Kurzen Telegrammen zur Konfiguration weiss ich die Länge.
Aber wenn ich die bei RECV einstelle habe ich immer einen Fehler.
Kann es sein das immer noch der IP Header dazu kommt.Sind zum teile 3000 Byte aber auch schon mal 2899 Byte je nach dem was der LMS an Entferungen misst gibt er für die Entferung mal 3 Hexwerte und mal 4 Hexwerte raus.

 

[Björn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich wollte auch UDP nutzen aber der Sickscanner unterstützt das leider noch nicht. Kommt wohl erst noch mit dem nächsten Firmwareupdate.

 

[JesperMP]

Bei PN kann man bei TCP die erwartete Länge auf NULL setzen.
Dann gibt es keinen Versatz mehr in den Daten, sondern bei
Telegrammverlust ist dann die empfangene Länge entsprechend
kürzer, was man dann manskieren kann.

Also, mit RCV_LEN erkennt man wie vile Bytes empfangen sind, und das muss man vergleichen mit was man erwarten ?

Aus der online Hilfe:

TCP / Ad-hoc mode
The ad-hoc mode exists only with the TCP protocol variant. You set the ad-hoc mode by assigning 0 to the LEN parameter.
The receive area is identical to the area formed by DATA. A maximum of 1472 bytes are received.
Immediately after receiving a block of data, FB64 enters the data in the receive area and sets NDR to 1.

 

[IBFS]

Das Problem ist das ich nicht immer weiss wie Lang die Datenblöcke sind.
Bei den Kurzen Telegrammen zur Konfiguration weiss ich die Länge.

Also dann geht TCP in Reinform MIT CP343 NICHT.

Bei PN gäbe es die o.g. Möglichkeiten.

Beim CP343 mußte ich leider auch die Variante 1

d.h "Länge auf 1" verwenden.

Aber bei einer SPS-Zykluszeit von 10 msec dauert das bei 16 Zeichen
auch nur 160ms bis alles eingelesen ist.
Einfach alle Daten wegschmeissen die ungleich "2" sind.
Ab da dann die Daten aufsteigend in einen DB schreiben.

So ging es bei mir!

Gruß

 

[Zefix]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wir haben bei uns nen Baustein von einer Fremdfirma, der zuerst den Header liest in der die Länge steht.
Und dann noch mal einen Recv aufruft mit der angegeben Länge des Headers.
Klappt einwandfrei wenn die Länge richtig drin steht.
Mit cp343-1 nix Lean

 

[Björn]

Jo mit den 16 Werten denke ich ist das kein Thema aber ich bekomme auch Längen von 1500 bis 3000 Bytes als Datenblöcke rein.

 

[IBFS]

ein paar Ideen dazu ohne die SW kaufen zu müssen könnte man hier lesen:

http://support.automation.siemens.com/WW/view/de/8707570

http://support.automation.siemens.com/WW/view/de/19033929


P.S.

Der LEAN-CP ist mit dem normalen CP kompatibel.
Einziger Unterschied ist die geringere Anzahl von
logischen Verbindungen.

 

[Björn]

Zuviel Werbung?
-> Hier kostenlos registrieren

danke für den tip werde ich mal versuchen.
Ich hoffe ich habe das soweit richtig verstanden.
Ich habe an einer stelle im dem Telegramm wo die Der Datenblock mit beliebiger länge ankommt eine Angabe über die Länge der Daten.
Könnte ich jetzt auf eine Bestimmte abfolge von Werten warten bis dort zb
Dist1 Scalefactor Laenge steht.Dann nehme ich Dist1 und Scalefaktor als Beginn und übergebe dann Laenge?

 

[Björn]

Ich habe mal ne Frage kann ich eigentlich auch ein UDP und TCP gleichzeitig nutzen.
Also per TCP den Befehl zum Sensor das er die Daten schicken soll und dann per UDP die Daten Empfangen ?
Also dem Sendbaustein FC5 als ID 1 geben für die TCP verbindung und dem FC6 ID 2 für UDP?
Habe grade versucht das zum laufen zu bekommen. Zeigt mir in Netpro an das TCP und UDP Verbindung aufgebaut haben.
Sobald ich aber ID 2 an den FC6 übergebe werden keine Daten empfangen.Bei ID1 mit TCP klappt es.

 

[MajorityOfOne]

ein paar Ideen dazu ohne die SW kaufen zu müssen könnte man hier lesen:

http://support.automation.siemens.com/WW/view/de/8707570

http://support.automation.siemens.com/WW/view/de/19033929


P.S.

Der LEAN-CP ist mit dem normalen CP kompatibel.
Einziger Unterschied ist die geringere Anzahl von
logischen Verbindungen.

Wie jetzt ?? Kann der Lean mittlerweise auch Profinet ?

 

[HaDi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Kann er, aber nur Profinet-Device.

Grüße von HaDi

 

[Björn]

Ich habe jetzt mal mit den großen Datenpaketen (gesendete Länge ca. 1500 Byte vom Sensor) nen Test gemacht.
Seltsamerweise ist dem jetzt die Grösse des Puffers vollkommen egal.
Wenn bei den kurzen Telegrammen (20 bis 30 Byte) der RECV im FC6 zu klein war habe ich gleich den Fehler 80B1H Zielbereich ungültig bekommen. Ich weiss sicher das die gesendeten Pakete ca 1500 Byte gross sind warum bekomme ich jetzt keinen fehler mehr ?
Daten werden auf jeden Fall in den DB geschrieben.

 

[Björn]

Also das übertragen der grossen Datenpakete ab 1500 byte geht gar nicht.Da kommt nur Datensalat bei raus.Kann es sein das die CP343 Lean mit Firmware 1.0 Probleme mit den grossen Paketen hat?
Ich habe gesehn das es Firmware Version 2.2 gibt wo etwas mit 8192 Byte für AG_RECV drin steht.Dafür müsste ich aber ein Update von Step7 auf 5.4 SP5 machen.
Macht das Sinn oder müsste die Firmware 1.0 auch mit den 1500 Byte klar kommen?