1

i´ve been successfully using a S7 1500 PLC in combination with an SQL-Server for quiete some time now. I set everything up like mentioned here: S7SQL-Guide-Stackoverflow Today i tried to add a second parameter to my SQL-Query. So I made something like this:

select Number1,Number2 from MYTABLE WHERE Apple = red and Sky = blue

The S7 sends the telegram, and the SQL-Server replies. So far so good.

TokenColumnMetaData

I set up the size of TokenColumnMetaData accordingly to my wireshark record, compiled and send the updates to my PLC. Now the part which I don´t understand:

I am expecting to receive the value "12345" so again I used wireshark to see what I should expect: wireshark-data

So what I got is: 39 30 00 00, which is 12345 just the bytes are reversed -no problem so far, but when I check on S7-side, I see this: S7-Watchtable

My input is shifted by 1 Byte. How can I solve this? Unfortantely I don´t have deeper knowledge of the code provided by Siemens for this application.

Edit:

Screenshot of typeUseCaseSpecificTokenrow

typeUseCaseSpecificTokenrow

nico25
  • 73
  • 6
  • Did you adjust the `typeUseCaseSpecificTokenRow` struct after adding the `Number2` bigint column? Seems like it's still expecting rows of `int` (1 length byte + 4 data bytes) instead of rows with both `int` and `bigint` (2 length bytes + 12 data bytes). – AlwaysLearning Jan 14 '22 at 15:32
  • I tried, but with no positive outcome for my problem. – nico25 Jan 17 '22 at 06:46
  • Can you [Edit](https://stackoverflow.com/posts/70708709/edit) your question to include a screen shot of the `typeUseCaseSpecificTokenRow` struct inside "PLC data types"? According to your Wireshark capture there should only be one row in the results. Starting with the `d1 ROW` token at `008D` is the `int` value with a length of `04` and the data `39 30 00 00` (1234), followed by the `bigint` value with a length of `08` and the data `47 94 03 00 00 00 00 00` (60049160). The `tokenRows` array data doesn't seem to agree with this, though, because it's only showing what it thinks are `int` values. – AlwaysLearning Jan 17 '22 at 09:44

1 Answers1

1

Sometimes weird memory stuff happens when the data type comprises an odd number of bytes.

Siemens starts each element on an even memory address. So if Length is at address 0 and Data is at 2-5, then address 1 may be getting the first byte that is intended for Data

Address Data Element
00 04 Length 0
01 39
02 30 Data 0, byte 0
03 00 Data 0, byte 1
04 00 Data 0, byte 2
05 08 Data 0, byte 3
06 47 Length 1
07 94
08 03 Data 1, byte 0
09 00 Data 1, byte 1
10 00 Data 1, byte 2
11 00 Data 1, byte 3
12 00 Length 2
13 00
14 FD Data 2, byte 0
15 10 Data 2, byte 1
16 00 Data 2, byte 2
17 C1 Data 2, byte 3
lcecl
  • 326
  • 2
  • 11
  • Is there a solution for this ? Currently I adjusted everything in a way, that I can access the bytes that I really need(the other bytes are inaccessable on siemens side now) but that´s more a workaround than a solution. – nico25 Jan 17 '22 at 07:00
  • One option is to send all the data to an array of bytes, then write an FB to move that data into a tag of your user data type. It does mean you're storing the information twice though. – lcecl Jan 17 '22 at 16:58