Hello PN/DP und Heinileini,
Es tut mir leid, hier erkläre ich noch ein bisschen:
Telegram Listing:
https://www.sick.com/media/docs/7/2...NAV310_LD_OEM15xx_LD_LRS36xx_en_IM0045927.PDF
Ich kommunikate durch TCP/IP mir FBs:
FB_ClientServerConnection;
FB_SocketSend;
SocketReceive;
Code:
CASE nStep OF
0:
bEnable := TRUE;
nStep := nStep +5;
5: fbConnect(
sSrvNetID := sSrvNetId,
nMode := CONNECT_MODE_ENABLEDBG,
sRemoteHost := sRemoteHost,
nRemotePort := nRemotePort,
bEnable := bEnable,
tReconnect := T#5S,
bBusy => ,
bError => ,
nErrId => ,
hSocket => hSocket,
eState => eState);
IF fbConnect.estate = eSOCKET_SUSPENDED THEN
bEnable := FALSE;
nStep := 0;
ELSE
nStep := nStep + 5;
END_IF
10: //Send sRN LMDscandata
sCommand := 'sRN LMDscandata';
// Add [STX] / [ETX] framing to the command
IF fbConnect.eState = eSocket_CONNECTED THEN
sCommandWithFraming:= Tc2_Standard.INSERT(STR1:= sCommand, STR2:= '$02', POS:= 0);
sCommandWithFraming:= Tc2_Standard.INSERT(STR1:= sCommandWithFraming, STR2:= '$03', POS:= LEN(sCommandWithFraming));
END_IF
nStep := nStep + 5;
15:
bExecuteSend := TRUE;
fbSend(
sSrvNetId := sSrvNetId,
hSocket := hSocket,
cbLen := SIZEOF(sCommandWithFraming),
pSrc := ADR(sCommandWithFraming),
bExecute := bExecuteSend,
tTimeout := ,
bBusy => ,
bError => ,
nErrId => );
IF NOT fbSend.bBusy AND NOT fbSend.bError THEN
nStep := nStep + 5;
bExecuteSend := FALSE;
END_IF
20:
bExecuteReceive := TRUE;
fbReceive(
sSrvNetId := sSrvNetId,
hSocket := hSocket,
cbLen := SIZEOF(arrReceive),
pDest := ADR(arrReceive),
bExecute := bExecuteReceive,
tTimeout := ,
bBusy => ,
bError => ,
nErrId => ,
nRecBytes => nRecBytes);
IF NOT fbReceive.bBusy AND NOT fbReceive.bError THEN
nStep := nStep + 5;
bExecuteReceive := FALSE;
END_IF
END_CASE
"sRN LMDscandata" ist Command für empfangenes Telegramm: Telegram Listing PDF Seite 65-74.
Telegram ist zusammengesetzt von:
Command type (string),
Command (string),
Version Numer (uint_16),
Device Numme(uint_16)r,
Serial Nummer(uint_32),
Device Status(uint_x),
telegram Counter(uint_16),
Scan Couter(uint_16),
Time since startup(uint_32),
time of transmission(uint_32),
Input status(Uint_x),
Output status(uint_x),
Reserved Byte A(uint_16),
Scanning frequency(uint_32), (= 15Hz)
measurement frequency(uint_32), (=16,2kHz)
number of encoders(uint_16), (= 0)
Number of 16 bit channels(uint_16), (= 1)
measured data contents((string), (=DIST1)
Scalling factor(real),
Scalling offset(real),
Starting angle(int_32), (= 62)
Angular step width((uint_16), (3.33)
number of data(uint_16), (= 157)
Data_1..Data_n (uint_16),
Teil das brauche ich
Number of 8 bit channels (uint_16), (= 0)
Position(uint_16), (= 0)
name (uint_16), (= 1)
Devicename (string),
comment(uint_16) ,(=0)
time information(uint_16),(=0)
Event information(uint_16), (=0)
= 31 Telegram parts (für mein Sensor, in PDF ist mehr Möglichkeiten). Telegram parts sind entwider Zahlen entwider Buchstaben. 157 UINT Werte die ich brauche können sie sehen auf Seite 70: Data_1--Data_n (Wie weiß ist das da ist 157 Werte? Sensor ist so Parametrisiert und ein Telegram part vor ist Amout of data.
Was mein Problem ist das leider ich erhalte ARRAY of BYTEs so, das jede Buchstabe und jede Zahle ist in einiges BYTE und in zwischen telegram part in ein {SPC}. Und Dan ich cca 780 BYTEs.. Warum cca: weil "Time since start up in µs", "Scan counter", uzw sind nicht immer gleiche nummers.
Teil das ich brauche ist nicht in Anfang. Das ich warum habe ich gesagt ok viellicht kann ich finde drei BYTEs: 16#39 AND 16#44 AND 16#20 - > das ist Amout of Data und ist vor die Werter das ich brauche.
Ich meinte, wie nennt sich das Telegramm offiziell nach der Kommunikationsbeschreibung von Sick? Das Telegramm ist die Antwort auf welche Anfrage/Command?
(Damit man unabhängig von Deinen schwammigen Aussagen belastbare Angaben bekommt.)
Command: sRN LMDscandata
Antwort: SRA LMDscandata
Du bekommst Deine 157 Ganzzahlwerte als hexadezimal-Zeichen, jeweils mit Leerzeichen getrennt. Genau das wandelt mein Programmcode aus Beitrag #9, egal mit wievielen Hexadezimal-Ziffern die Werte codiert sind, und egal ob mit oder ohne führende Nullen. Du müsstest jetzt nur noch das <STX> am Anfang auswerten/entfernen (den Empfangspuffer um 1 Zeichen versetzt weiterreichen, oder durch '0' ersetzen, oder im Konvertier-Code abprüfen), und beim <ETX> die Konvertierung beenden.
Ich muss erte mall suche für Teil mit 157 Werte.
Jeder Wert, den ich brauche, wird mit drei Bytes geschrieben:
Wie kommst Du da drauf? Und ist das garantiert immer so?
Ab arrReceive[63] sind mehrere Werte nur 1 Zeichen lang, Dein Beispiel arrReceive[116]+arrReceive[117] = 16#9D = 157 ist nur 2 Zeichen lang, ...
ich meinte für diese 157 werte
Heißt das, in dem Empfangs-Telegramm sind noch mehr Werte, und die 157 Werte die Dich interessieren liegen gar nicht am Anfang? Muß man den Anfang der Werte womöglich erst suchen oder abzählen?
Ja
Wieso brauchst Du jetzt auf einmal UDINT?
typo
Warum schreibst Du immer nur ca. ... ?
Wie gesagt ich habe mehr Telegramm parts und die sind nicht immer gleich lang.
Wo wären denn da noch die Inhalte (Werte) versteckt, auf die es eigentlich ankommt?
normalerweise 24. Telegrammteil, aber hier dachtet ich dac kann ich suche für 23. telegrammteil die in diese Beispiel ist immer 157 (Wenn in einer anderen Umgebung, an einer anderen Maschine, nicht notwendig).
Die zuletzt gelieferten ScreenShots zeigen Daten, die ausnahmslos als ASCII-Zeichen interpretiert werden können (nicht müssen), aber es sind nicht nur Leerzeichen (=Space) und Ziffern, sondern auch Buchstaben. Was haben die zu bedeuten? Die bieten sich ja nicht gerade an, in INT, UINT oder sonstige Zahlen gewandelt zu werden.
Wie Harald schon schrieb, müssten wir erfahren, welche Bytes welche Bedeutung haben bzw. wie gruppiert sind.
Wenn Du uns wenigstens verrätst, welches der im pdf beschriebenen Telegramme wir uns ansehen sollen . . .
genau. Da sind auch Parameterwerte von Sensor, Nameusw. ..Seite 65-74.:
https://www.sick.com/media/docs/7/2...NAV310_LD_OEM15xx_LD_LRS36xx_en_IM0045927.PDF
Ich hoffe, ich habe etwas besser erklärt.