Verbindung zwischen ifm sensor und cp

[Ötzwurst]

Zuviel Werbung?
-> Hier kostenlos registrieren

hi,

ich hänge grad an einer inbetriebname eines ifm-sensors. diesen habe ich bereits eingerichtet, kommunikation mit hyperterminal funktioniert auch wunderbar. einzig die kommunikation mit der cp macht probleme.
ich benutze die bausteine ag-send und recv. das senden ging bisher auch immer ohne fehler, beim empfangen ist der wurm drin. der ifm schickt mir 30 zeichen. deshalb hab ich folgenden pointer als ziel eingerichtet: p#db23.dbx123.0 byte 30
soweit so gut, ich empfange daten, allerdings sind diese versetzt. sendet der ifm nochmal, verrutschen die daten weiter.
habe folgendes mehrfach kontrolliert:
- verbindubgsparameter in netpro
- antwortlänge des ifms
- verschiedene pointer varianten
- verschiedene db-strukturen (string, array, byte, etc)


leider fällt mir nun nichts mehr ein. Hoffe von euch hat jemand eine idee.

vielen Dank schonmal.
Gruss
Stefan

 

[SoftMachine]

Um wieviel versetzt ?
Immer konstanter Versatz ?

Ist das mit ...DBX 123.0 ... gewollt ?

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die Empfangsfachlänge muß genau der Länge der gesendeten Daten entsprechen (leider). Das trifft auf ältere Siemens-SPS und auf die VIPA Speed7 zu. Bei neueren Siemens-SPS (auch CP???, Ab wann kann ich nicht genau sagen) einen größeres Empfangsfach vorgeben.

Stimmt bei den erstgenannten SPS die angelegte Empfangslänge nicht mit der tatsächlichen Länge überein, dann kommt es zu dem von dir beschriebenen Effekt.

1. Das Empfangsfach ist zu klein: die Daten, die zu viel sind überschreiben den Anfangsbereich des Empfagsfaches, beim nächsten Empfang geht es nach dem letzten Byte vom vorigen Empfang weiter.

2. Das Empfangsfach ist zu groß: Die Daten passen beim Ersten Mal hinein, beim Zweiten Empfang, wird hinten angefügt und dann tritt der Effekt wie bei 1. auf.

Es gab nur 2 Möglichkeiten, entweder man wußte genau, wie viele Byte kommen und stelle das Fach genau so ein oder man hatte eine Endekennung, gab das Fach größer an, als nötig und suchte sich dann aus diesem Fach die Daten heraus.
Bei den neueren PN-CPU von Siemens trat dieser Effekt (glaube ich zu erinnern) nicht auf, bei jedem Empfang wurden die Daten wieder am den Anfang des Buffers beginnend eingetragen.

PS: DBX123 sollte besser auf eine Wortgrenze fallen (Gerades Byte)
Ausgehend von Versatz kannst du mal mit "Byte 30" experimentieren und die Länge variieren.

 

[SoftMachine]

Stimmt bei den erstgenannten SPS die angelegte Empfangslänge nicht mit der tatsächlichen Länge überein, dann kommt es zu dem von dir beschriebenen Effekt.

Hi Ralle,
kenne ich nicht ganz so, weil:
1. bei zu klein wird nur eine Fehlermeldung ausgegeben
2. bei zu gross wird in den Empfangspuffer geschrieben, der nachfolgende Empfang schreibt aber wieder ab der Anfangsadresse in den Empfangspuffer. Der obere Rest bleibt ungenutzt.

Ich denke mal, eine nähere AUskunft vom TE über HW und auch über NDR/ERROR und Status könnten hier weiterhelfen.

3. ...DB123.0... volle Zustimmung !

Gruss

 

[Ötzwurst]

hi,
schonmal vielen dank für die antworten.
ich habe bereits mit "byte 30" herum experimentiert, leider ohne erfolg. der versatz ist immer unterschiedlich, zumindest erkenne ich kein system. was mich auch verwundert, dass das erste byte während dem empfangen "flackert", sprich der wert ändert sich...
leider gibt error und status nichts her, alles normal... status sagt warte auf neue daten, neue daten empfangen...
was ist an dbx123 auszusetzen? war aber nur ein beispiel, hab den pointer und den db auch varriert....
was für infos braucht ihr über die hw? die verbindung ist eine tcp/ip verbindung

danke für eure hilfe!

gruss
Stefan

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Ralle,
kenne ich nicht ganz so, weil:
1. bei zu klein wird nur eine Fehlermeldung ausgegeben
2. bei zu gross wird in den Empfangspuffer geschrieben, der nachfolgende Empfang schreibt aber wieder ab der Anfangsadresse in den Empfangspuffer. Der obere Rest bleibt ungenutzt.

Ich denke mal, eine nähere AUskunft vom TE über HW und auch über NDR/ERROR und Status könnten hier weiterhelfen.

3. ...DB123.0... volle Zustimmung !

Gruss

Ich meine die Länge des Emfangsbuffers, der von dem Any repräsentiert wird und die Länge der tatsächlich eingehenden Daten.

Ich hatte gleiches Problem bei einer VIPA Speed7 erst vor einem halben Jahr, das war dort absolut reproduzierbar, glücklicherweise gab es eine Ende-Kennung, so daß man mit ein wenig Code damit fertig werden konnte.

 

[Ralle]

hi,
schonmal vielen dank für die antworten.
ich habe bereits mit "byte 30" herum experimentiert, leider ohne erfolg. der versatz ist immer unterschiedlich, zumindest erkenne ich kein system. was mich auch verwundert, dass das erste byte während dem empfangen "flackert", sprich der wert ändert sich...
leider gibt error und status nichts her, alles normal... status sagt warte auf neue daten, neue daten empfangen...
was ist an dbx123 auszusetzen? war aber nur ein beispiel, hab den pointer und den db auch varriert....
was für infos braucht ihr über die hw? die verbindung ist eine tcp/ip verbindung

danke für eure hilfe!

gruss
Stefan

Versuche zuerst einmal den Emfangsbuffer z.Bsp.200 Byte lang zu machen (p#db23.dbx200.0 byte 200), sende 5 mal Daten vom IFM-Sensor und schau dir dann das Ergebnis im Buffer an. Wenn alle 5 Datenpakete fein säuberlich hintereinander stehen, dann kannst du genau sehen, was gesendet wird (u.U. sind es mehr als 30 Byte, vielleicht gibt es noch Anfangs-/Endekennungen etc.) Dann löscht du den Buffer und sendest du 7 Pakete. Anschließend schaust du nach, ob die Daten des ersten Paketes mit dem Rest des letzten Paketes überschrieben wurden.

 

[Ötzwurst]

ich hab mir das grad nochmal angeschaut, wenn ich den pointer auf byte 200 erhòhe, schreibt er due daten auch schön hintereinander, allerdings fängt er nicht am anfang des dbs an.
desweiteren habe ich nun gesehen, dass noch folgendes mit kommt * $l $r (hab ich so zwar nicht eingestellt, aber gut). wenn ich nun den pointer um diese 3 bytes anpasse, habe ich aber immernoch einen versatz drin... der letzte eintrag, wenn der pointer zu gross ist, wird nicht ganz gespeichert, wird auch nicht am anfang des dbs fortgesetzt...

 

[Ralle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist komisch, normalerweise schreibt er dann am Anfang weiter, das Daten verloren sind habe ich noch nicht erlebt. Mit der Endekennung kann man dann das Ende finden und die Daten in die richtige Reihenfolge bringen.

 

[Ötzwurst]

nach längerem suchen, habe ich nun die vermutung, dass die daten alle in das erste byte geschrieben werden und nicht pro zeichen ein byte... deswegen auch das flackern des ersten bytes vielleicht... kann es sein, dass die cp 343-1lean zu langsam ist, oder besser die cpu 319-3 pn/dp???? kann ich aber gar nicht glauben...

 

[Ralle]

nach längerem suchen, habe ich nun die vermutung, dass die daten alle in das erste byte geschrieben werden und nicht pro zeichen ein byte... deswegen auch das flackern des ersten bytes vielleicht... kann es sein, dass die cp 343-1lean zu langsam ist, oder besser die cpu 319-3 pn/dp???? kann ich aber gar nicht glauben...

Lösche doch mal deinen Empfangsbuffer komplett und dann schicke vom IFM ein Telegramm. Wird alles in das erste Zeichen geschrieben, dann sollte ja Zeichen 2, 3, usw. 0 bleiben.

 

[Ötzwurst]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist sogar korrekt, den Fall hab ich manchmal... Manchmal bekomme ich viele Zeichen, manchmal nur ein paar und manchmal eben nur im Byte 0... Es sieht wirklich so aus, alsob die CP der Kommunikation nicht hinterher kommt... aber was bedeutet das und wie kann ich das beheben??
Gibt es vll inzwischen neue Bausteine, oder sowas, die Hardware ist zumindest neu...

 

[Ralle]

Also ich nutze die Bausteine aus der Bibliothek "SIMATIC_NET_CP". "Verlorene" Zeichen hatte ich bisher noch nie, einen IFM-Sensor hatte ich auch schon, ist aber etwas länger her. Nimm doch mal Hyperterminal oder ein anderes Programm und sende damit Daten an die CP. Bei Hyperterminal mußte ich aber immer den zu sendenden Bock direkt in das Sendefenster kopieren und dann abschicken, Wenn man das einzeln über die Tastatur versucht, bekommt man auch den Effekt, den du beschreibst, da wird dann wohl jedes Zeichen als eigenes Paket verschickt.
Was sagte den LEN von AG-Receive? (Ist immer nur einen Zyklus lang mit DONE aktiv!)