S7-1200 MB_Client Little Endian Device

Hi everyone, trying to get data out of a digital encoder that is little endian into my Siemens S7-1200 controller that is big endian...it's an issue lol.

My modbus communications read successful open no issue (code 7004) but the data reads all zeroes (as expected). On other master platforms outside Siemens, all zeroes is the same result if the byte order is not correct. Someone suggested using the SWAP function to me but if I read the data into the MB_Client and it comes in zeroes, then I swap it, it reads zeroes lol.

It's almost like I need the data swapped pre-transit before going into the MB_client function to be interpreted and stored in a DWORD properly. Anyway, I'm wondering if someone has had little endian to Siemens big endian issues before and might be able to look at this code and offer advice (or just in general for the need). The encoder modbus data is on page 76 of the PDF and while I realize the input data would technically be 30002 for velocity data, Siemens starts at 30001, so I did account for the offset and am looking at 30003 in code with a length of 2 for DWORD.

It was programmed in TIA Portal V16 FYI. Could create lower if need be. Thanks in advance for any advice anyone can offer!

ZestyMozzarella said:

On other master platforms outside Siemens, all zeroes is the same result if the byte order is not correct

Click to expand...

I am guessing that what you are saying that if the CPU sends a command word with the wrong byte order to the device, the device then responds with all zeros.

To swap bytes:
In STL you can use the CAW instruction.
In SCL you can use the SWAP instruction.
In LAD and FBD you can use SHR to rotate all the bits withing a word 8 positions.

New MB_Client doesn't need edge up on REQ, just TRUE will run it cyclically..

The Endianess doesn't matter to MB_Client, you have something wrong.. You will always get the data, interpreting them is where "the problem is".. But it is actually no problem, just check the Read_little command in SCL...

Hi JesperMP,

Perhaps a command as a client yes. I'm uncertain if the exact issue is in the structure of the MB_Client itself or the actual data storage. I was under the impression from Siemens sources online that the data storage on S7-1200 is Big Endian format. Though when I try to use a SWAP, it still seems to be zeroes, so I think the nature of the MB_Client itself storing data from the communication in MB_DATA_PTR is an issue that it has to be flipped before storage? Not sure there is a way to do that and I may also be mistaken but it stores the data as zeroes, so flipping it afterward doesn't work...it's like it has to be built into the request or something.

I'm still reading and fairly confused as the SWAP function is not able to attach to MB_DATA_PTR and interact anyway prior but still trying to investigate solutions. My lack of veteran experience on the platform may be missing something about due process here.

I also experimented prior to the MB_Client request...taking a DWORD DB and sending it through a SWAP and then directing that memory area to MB_DATA_PTR...I'm not sure if that would work? Still gives me zeroes though, so if using the SWAP in that manner would work...I may have issues in the comm itself that are not clear.

I'm building more status and error memory areas to read any other codes not inherent in the MB_Client DB itself to see if I get any more intel...

Hi M_Turk, thank you. I'm doing some reading on it now and hope it's promising. Did not see this one yet, so I'm hopeful Keep you guys posted!

You cant use SWAP on an entire structure in one go. It only works on WORDs or DWORDs
You could arrange the data as an ARRAY of WORDs (since in one direction it is an uneven no of words). And then swap the bytes word for word.
The READ_LITTLE, READ_BIG, WRITE_LITTLE, WRITE_BIG instructions which m_turk refers to may be the better way.

I dont understand the other thing you write about what causes the device to only return zeroes.
The Siemens Modbus blocks merely transmits some data, no regards to the endianness of the data.
And, the bits in a word with the value of zero, is the same if you swap the bytes.

I speculated that it could be that the command word that CPUs is interpreted wrongly by the device (because of the byte order), and it therefore responds with zero. If that is not the explanation, I cannot help with that.

Hi JesperMP,

Yes, I will do some more testing around these today. I did hear from the encoder manufacturer this morning and they'e in agreement that the endianness should not matter. They said it should not be zero and the data would simply show up in reverse order, so some erraneous DWORD number. I would think if that's the case, then a simple SWAP DWORD may work or I have to break it up.

Anyway, as M_Turk referred to, there may be some inherent issue in the MB_Client request itself. It seems like the connection is successful to open but the actual request is not happening...may try a TRUE command or something non-clock based to see if it triggers any responses. Saving Status also shows me zeroes, so I think this comm is open but requests are not taking place.

I may strip one of these encoders and go to the office for standalone testing at this point because I have had issues in the past with these encoders where even if the communication structure is correct, the encoder has stayed locked at zero for me. I have had to physically cycle power on them and then they work once the right configuration is in place, some kind of freeze state from an improper config I suppose. A little annoying but between each test, I have been walking in the factory to reset them since I don't have a station right by them

IT WOOORRRRKKKKSSS!!! LOL

As M_Turk eluded too, dug deeper with AMCI on the structure and the MB_Code was all that was wrong! I was using function code 0 as I have in the past for "read" but forgot my device length is 0-65,535 device, so that's why I get zeroes. Upon switching to function code 104 in Siemens which represent function code 4 as shown in the attached file for MB_Code functions, it now reads the data in and it doesn't care about the endianness!

The world is saved and now it's onward to Atmosphere! Thanks to everyone for their help, this has set me down the right path of investigation and led to a solution! I also set the request to just true but as I sequence more requests, I will probably use the done bits to sequence accordingly, that way I don't get hiccups.