Hello!
I am having an issue properly utilizing the TLS function blocks in ST. I am getting a c101 error code, which is “unexpected error”. I am not sure what the diagnosis steps are for this.
image.pngheres the code
image.pngand heres the custom struct to receive the data.
Is it possible to receive the data in a struct? it is being sent as a byte stream in this exact syntax, which i got from this.
We are sending the command sRN LMDscandata, and the response is sRA LMDscandata which has that structure to it.
Hello Dragonite06,
What version of PLCnext Engineer are you in? There have been recent changes to the functionality of that function block that may fix the issue.
Additionally what firmware is the controller on?
I believe the fix happened in the 2024.0.4 firmware and PnE 2024.0.3.
Hello Dragonite06,</p>What version of PLCnext Engineer are you in? There have been recent changes to the functionality of that function block that may fix the issue. </p>Additionally what firmware is the controller on? </p>I believe the fix happened in the 2024.0.4 firmware and PnE 2024.0.3.</p>
I am using firmware 2024 and PnE 2024.0.4.
I have also gotten that error code to go away (manually restarting the function block whenever it occurs) but the data I am receiving is all garbage and partially missing, so it appears the issue has shifted.
Hi!
According to sample snapshot, there is:
1. You activate receive fb before socket establish connection. You should use TLS_SOCKET.ACTIVE for EN_R of TLS_RECEIVE.EN_R
2. I will recommend you to drop TLS_SEND.REQ after DONE or ERROR flag rised, not BUSY.
3. Yes you can map raw tcp buffer to structure with MEMORY_COPY fc
BR
Hi!</p>According to sample snapshot, there is:</p>
1. You activate receive fb before socket establish connection. You should use TLS_SOCKET.ACTIVE for EN_R of TLS_RECEIVE.EN_R </li>
2. I will recommend you to drop TLS_SEND.REQ after DONE or ERROR flag rised, not BUSY.</li>
3. Yes you can map raw tcp buffer to structure with MEMORY_COPY fc</li></ol>[https://forum.plcnext-community.net/uploads/0T3P8RC40WHX/png.png</a></p>BR</p>
image.pngUsing the exact code written above, I am getting flooded with garbage data, rather than anything that matches the message structure provided by sick.
When i open a socket through python, here is what the data i receive looks like, nice and clean.
\x02sRA LMDscandata 1 10 10A465D 0 0 F8F8 F8FD FD96C2EE FD975BF3
0 0 F 0 0 5DC 6C 0 1 DIST1 40800000 00000000 DBBA0 1388 169 2FD 307 31B 304 2F3 2E0 2CE 2BB 2AB 2B1 2F4 2EB 2DE 2D9 2CC 2C8 2C8 2EF 2E8 2E2 2DD 2D9 2D6 2D2 2CA 2D0 2FE 3A9 3B0 3BC 3B4 3AD 399 394 390 38E 386 37C 372 258 217 242 22F 246 25E 25C 374 388 3A0 33A 3FD 3F8 3E8 3C0 3CD 381 360 3E0 37E 391 3D2 3A1 20B 252 252 20C 216 223 222 224 227 223 222 224 222 21E 1DA 1D7 1D3 1D3 1DB 1EA 211 228 247 247 244 250 249 24D 249 0 56E 569 355 349 298 270 226 22D 228 43C 5D6 5C4 56A 55C 55C 564 563 560 560 55F 564 55F 55B 55C 55E 55D 55F 560 555 3CF 3B0 3A0 37C 365 350 35C 375 343 347 349 357 35A 35B 35B 35E 35D 35B 363 366 362 363 369 36A 36C 369 36B 36F 36F 399 365 3F5 3A4 38C 464 5BF 5C4 342 5CD 5D2 389 1A9 1A7 1A5 1A3 1A9 218 31D 31B 317 30B 30F 297 282 30B 315 319 320 32B 33B 348 6A7 6B4 6BD 607 5FA 5E8 5D8 5C5 5B4 5A6 598 588 571 563 556 547 538 528 51F 2FB 2F6 356 3C4 4D3 4E0 4F1 4FA 509 519 529 3C3 3C2 3B5 3B4 3CD 3CD 30F 305 27F 2CB 26A 26B 222 21C 21F 21F 222 21F 21D 21E 215 214 20F 20A 207 20A 207 200 201 200 1FD 1FC 1F5 1F9 1F5 1F3 1F0 1F3 1ED 1EB 1E7 1E7 1E5 1E4 1E3 1DF 1DF 1DF 1F2 1D5 1D5 1D0 1DE 1F5 1E6 1DF 1E2 209 1FD 1EA 1F9 1F6 1F5 1F3 1F4 1F3 1F1 1EA 1EB 1F0 1F1 1EF 1E8 1EC 1EC 1EC 1E5 1EC 1EE 1EC 1E9 1E9 1E9 1EA 1E7 1ED 1ED 1EA 1EC 1ED 1EE 1E8 1EE 1EC 1E9 1EB 1E7 241 244 242 247 249 249 243 228 220 21F 21C 222 230 233 231 231 235 239 23B 255 258 25A 25F 23C 23D 240 264 265 268 26A 26B 272 26D 277 22C 213 216 21C 21D 221 223 224 22B 22D 22F 234 238 23C 23D 243 245 24D 0 0 0 0 0 0\x03F
I suspect it is taking my bytestream and putting almost everything into the string, rather than ending it after a specified size. Is there a way to limit the string length, or maybe a better way of breaking up this message on the PLC side?
Thanks
The common trouble is that bytes in buffer should be converted to ASCII in different manner, some as chars an some as hex representations. Also in you struct, default size of string is 80 chars, so some additional data swamp into this variable and create shifting of data. In your case tcp buffer data should be parsed comprehensively, in several steps. Single memory_copy or dumb pasting into string variable is not suitable.
You can clearly see borders of message, x02 x03 special characters, which can suggest you where to start accumulate message buffer and where message stops, and may be processed further.
Please point to the exact telegram type according to the lidar instruction (page to see) and I’ll try to assist you.
BR
The common trouble is that bytes in buffer should be converted to ASCII in different manner, some as chars an some as hex representations. Also in you struct, default size of string is 80 chars, so some additional data swamp into this variable and create shifting of data. In your case tcp buffer data should be parsed comprehensively, in several steps. Single memory_copy or dumb pasting into string variable is not suitable.</p>You can clearly see borders of message, x02 x03 special characters, which can suggest you where to start accumulate message buffer and where message stops, and may be processed further.</p>Please point to the exact telegram type according to the lidar instruction (page to see) and I’ll try to assist you.</p>BR</p>
NAV310_34-37.pdfIt is pages 34-37 to get the telegram structure. I have attached these specific pages too, incase it is easier. Thank you!
NAV310_34-37.pdf
Ok.
So I suspect we will use ASCII protocol to exchange messages.
It is not clear to me, does “Telegram stream” will be sending from lidar to the client all the time, or one request = one response?
So now the goal to get string representation of transferred data in plc, similar to sniffed via python code.
Please, find out first rough approach. It does not take to attention 0x02 /0x03 markers, and suspect that all data will be received via single transfer cycle.
There are embedded methods of fb, that will try to adapt byte stream of the rcv buffer to ascii symbols or hex codes, in case it is impossible to convert data.
LIDAR_SOCK.7zFor further discussion, please mail me oguminskiy@yahoo.com
BR
