How Ignition handles big endien/little endien?

Ignition
1

How Ignition derives the following in bigendien (Hex Value)

  • Bit in bytes
  • Signed/Unsigned int
  • Signed/Unsigned double int
  • ASCII

above query is from one of our customers. Honestly, I have no clue about what big endien/little endien is. Upon quick Google search, I learnt that it has something to do with storing multibyte data-types ( int, float, etc).
We are going to receive some data in json format and there is one Siemens PLC for which we will use Siemens driver available in Ignition. So I have no idea how to apply big endien/little endien concept with Ignition and answer above query. Please guide. Any link to related document within or outside Ignition would also be appreciated. Thank you.

2

Internally, Ignition is written in Java, so uses the Java standards to handle integers. That is Big Endian, but that doesn’t matter for any end user.

What does matter is what the individual drivers support to communicate with other devices. If you use the Siemens driver, it’s made for Siemens, so as long as all data types are available, they will be translated correctly (we have used the Siemens driver before, and it doesn’t give issues with data types).

It’s all defined in the addressing: https://docs.inductiveautomation.com/display/DOC79/Siemens#Siemens-ConfiguringSiemensAddressing

I don’t get why someone is interested in endianness unless you have to work on the actual driver code.

UPDATE:
Apparently, Siemens also used Big Endianness for most data (https://support.industry.siemens.com/tf/WW/en/posts/s7-1200-big-or-little-endian/143030?page=0&pageSize=10), with the one exception of optimized block data.
The Ignition documentation says you must turn off the optimized block data. So that probably means the driver only uses Big Endian encoding, and your client probably wants to know if they can enable the optimized block data or not.

3

One nit to pick:

Java uses its platform's endianness. In the few places where Ignition's functions numerically access bits of integers, it is little-endian. Beyond that, as you've noted, it is entirely up to the individual drivers.

4

You meant big endian, right?

5

Nope, counting bits from zero at the least-significant bit, and bytes at the least significant byte, is the definition of little-endian.

6

Network protocols are all big-endian at the byte level, as the bits are placed on the wire from high bit to low bit. Most network protocols carried forward this convention by transmitting higher-order bytes before lower-order bytes. (Java serialization…) That is also helpful when designing low-latency network routing ASICs, as the routing decision can often be made before all the bits arrive.

Intel flipped the convention when ordering memory accesses with its earliest microprocessors as incrementing from low-order to high-order byte permits the most efficient handling of arithmetic carries in multi-byte math operations. This was particularly important in the first microprocessor, the Intel 4004, as its registers were four bits, not eight. Any useful math was multiple nybbles.

Thus begun, the endian wars were. (:

7

Maybe I'm a little confused about endian-ness as it applies to bits.

Bits in a byte being numbered 7 through 0, from high to low, left to right, seems like the same as bytes in a word being ordered high to low (or MSB to LSB).

0b10101010
  ^^^^^^^^  
# 76543210
8

Yup. A side-effect of using arabic numerals (arabic is written right-to-left). This Wikipedia Section shows what I think is the most durable definition:

In such a number system the "value" of a digit is determined not only by its value as a single digit, but also by the position it holds in the complete number, its "significance". These positions can be mapped to memory mainly in two ways:

  1. increasing numeric significance with increasing memory addresses (or increasing time), known as little-endian, and
  2. decreasing numeric significance with increasing memory addresses (or increasing time), known as big-endian

The distinction is most clear when thinking about register sizes other than bytes. In a little-endian system, the power of two for a particular bit can be obtained by concatenating the word offset with the zero-padded bit number (padded to three bits for byte registers, four bits for 16-bit registers, etc). Big endian representations obtain the power of two by subtracting that from the highest power of two in the multi-word value.

9

Now I'm getting more confused than I ever was...

I thought bits in a byte were standard little endian (due to intel apparently), so I only talked about bytes in a multi-byte datatype. For which Java follows the network protocols, so that's big endian.

Though indeed that doesn't match the getBit function. And actually, endianness has little importance. As long as it matches, you can communicate :slight_smile:

10

Heh. It's a hardware thing. Like most things in life, there's no single "best" way to do something, only trade-offs. I learned machine language on the old Intel 8080 (no, not the 8088) before I learned anything else about computers, so I have an ingrained little-endian bias. That bias got beat up pretty good in my college "Signals and Systems" class. /:

1 Like
11

Thank you all for your inputs.