Hi,

I am doing a TCP/IP communication to 3rd party and something isn't clear to me. There are mainly two cpu archicetures that have little or big endianes. Now simotion it has to have something else, because of the implemented functions:

AnyType_to_BigByteArray

AnyType_to_LittleByteArray

BigByteArray_to_AnyType

LittleByteArray_to_AnyType

For example if the simotion would use big endianes, then AnyType_to_BigByteArray /BigByteArray_to_AnyType would be void functions, because they are not, the logic explanation is that simotion is neither big or little endian, it's simotion endian?! 

Now the question is: Do I have to convert the received data from PC with BigByteArray_to_AnyType / LittleByteArray_to_AnyType in all circumstances?

Hi!

Have you seen chapter 5.1.1.2 from the Simotion documentation?

https://support.industry.siemens.com/cs/document/48955385?lc=en-WW

Perhaps I have solved the mistery. The answer is very simple, SCOUT is used to program different platforms of CPUs. With converting functions, you can port your application from SIMOTION D to C, or if next year Siemens changes cpu to different brand.

By the way, I did test endianes of D425. Its big endian, also I have read that default endianes on ethernet network is big endian, perhaps I shall still use BigByteArray_to_AnyType for latter porting the app to another simotion platform.

I do use STRUCT OVERLAP:

        sRecvBuffer                  : STRUCT OVERLAP // Union 
            Bytes           AT %B0      : ARRAY [0..4095] OF BYTE; //bytes 0-4095
            PacketType_1    AT %B26     : sPacketType_1; //bytes 26->
            AlarmType       AT %B26     : sAlarmType; //bytes 26->
            HeadStat        AT %B0      : sHeadStat; //bytes 0-25           
            PacketType_2    AT %B26     : sPacketType_2; //bytes 26->  
           
        END_STRUCT

If the received bytes are oredered in the same order as the host (SIMOTION) archicecture, then I guess the structure will match and there is no need to do marshalling.

        sHeader                         : STRUCT OVERLAP 
            DatLen          AT %B0      : ARRAY [0..3] OF BYTE;
            DatagramLen     AT %B0      : UDINT := 0;
            Checksum        AT %B4      : BYTE;
            Dummy           AT %B5      : BYTE;
        END_STRUCT

As for endianes, I have insterted DatagramLen := 12345678, the DatLen bytes are:

[0] = 4E

[1] = 61

[2] = BC

[3] = 00

12345678 (dec) = BC614E (hex) from windows calculator.

Wiki:

Each byte of data in memory has its own address. Big-endian systems store the most significant byte of a word in the smallest address and the least significant byte is stored in the largest address (also see Most significant bit). Little-endian systems, in contrast, store the least significant byte in the smallest address

So the D425 is Little-endian

Reality is not so simple. Besides the endianity, marshaling functions solve another issue - different memory architecture on different systems. Of coures you can handle that with STRUCT OVERLAP and proper alignment of your data (possibly on both endpoints), but:

- first of all, you must be aware of that,

- it's additional documentation digging and then coding,

- solution is not robust - changing the data structure may cost you a lot of additional work with aligning data again,

- you can create additional data overhead.

jacek d

Reality is not so simple. Besides the endianity, marshaling functions solve another issue - different memory architecture on different systems. Of coures you can handle that with STRUCT OVERLAP and proper alignment of your data (possibly on both endpoints), but:

- first of all, you must be aware of that,

- it's additional documentation digging and then coding,

- solution is not robust - changing the data structure may cost you a lot of additional work with aligning data again,

- you can create additional data overhead.

With STRUCT_OVERLAP changing the structure is simple, everything is readjusted with a compile, no aligning, no offset calculation, no copying from one memory to another.

With marshalling isn't, you have to re-calculate offsets, no overlap struct is allowed as target struct when marshalling, therefore I  have to copy in additional sturcure (because I need overlap struct) . From receive buffer to a structure and then copy again overlapped structure: 3x memory areas , 3x structures, 3x copying, 3x calculate offsets for all these.

Where do all yours "AT %Bxx" come from ? Aren't those offsets ?

Nothing like that while using marshaling.

OK, I did it. The communication TCP/IP to 3rd party (PC). The receiving buffer is organized with STRUCT_OVERLAP. Many different types of telegram responses are configured as structures that overlap each other, the header of the telegram indicates which type of structure should be used.

The PC send in little-endian byte order, therefore no marshalling is used. I have tried also where PC sends in big-endian, and I have used BIGBYTEARRAY_TO_ANY() . With marshalling you can't use overaping structures, if  you need them you have to copy the memory area to another memory area - in my case:

1. receive buffer is translated and copied into temporary memory with marhalling

2. temporary mem. area is copied into another mem. area that has struct_overlap

3. data is processed

Without use of marshalling, steps 1 and 2 are not needed. Simotion D is little-endian, while Windows OS, running on PC is also little-endian, therefore no marshalling is needed on any side.

Good to hear that.

However we failed to explain to you what marshaling functions are for... Sorry for being mentally imperfect.