Opening a big can of worms

[john paley]

Programmers of all type PLC's:

We are presently wrapping up a project to replace DC drives on a paper/plastic web handling machine.This project also included wholesale replacement of an old surface winder with a brand new dual turret center winder--manufactured in Europe.

The machine drives are rockwell--reliance webpack 3000's, controlled via controlnet by an AB controllogix processsor.

The winder drives are siemens--controlled via profibus by an s7 PLC.

We use a third party (SST) card in the controllogix rack to talk to the siemens S7 over the profibus. The data is exchanged via tarnsfer of a gazillion integers.

When we started up the SST card, we found the bytes of the siemens integers to be transposed--that is the lsb was bits 8-15 and the msb was bits 0-7---just the opposite of what controllogix was accustomed to. The siemens guy was able to reverse the bytes and everythin is OK but now for the million dollar question and that can of worms. Who the heck is backwards, AB or Siemens??

My two cents--I think it's siemens who's backwards, not just because I'm an AB fan, but because siemens had hooks available in their system to easily reverse the bytes--like they knew it would need to be done, at some time--the programmer did it in about a half an hour.

 

[Steve Bailey]

I think the "who is backwards' question applies to the manufacturer of the microprocessor chip rather than the PLC. I'm pretty sure Intel and Motorola chips disagree over which of two consecutive bytes is the low byte and which is the high byte when they're combined into a 16-bit word.

 

[john paley]

The rockwell guy answered the question. Siemens deals with bytes, AB deals with words. How siemens arranges the bytes for someone elses use as a word is of no consequence to them or thier processor. The programmer simply had a 50/50 chance and blew it. Kinda like connecting a 3 phase motor--which way will it go--50/50 chance--I blow that one about half the time.

 

[Jiri Toman]

byte order

The problem you have encountered has to do with the way PLC's
send out the serial data streams. The accepted industry practice is to
send out the data in a BIG ENDIEN configuration. In your case
an integer consists of two bytes and the high byte is sent out first
and then the low byte. Obviously you have a mismatch in the way the
PLC's interpret serial data. I would like to bring to your attention a possible problem with reversing the byte order.
If you have an even number of bytes in the data stream you have
no problem, however if you have an ODD number of bytes, after reversing the order of low and high bytes, the last
integer will contain one dummy byte of data! Make sure that
your programmer understands that!

 

[john paley]

Jimi,

Actually, he reversed the bytes before the transmission, so I don't think it's a problem.

 

[Gerry]

Just to add to the confusion...
The ControlLogix has a 'swap bytes' instruction to deal with this sort of problem.

 

[Terry Woods]

There is no "Who is Right?" in this case.

Big-Endian vs. Little-Endian is nothing more than 6 of 1 or a half-dozen of the other.

Steve's answer is correct. Except that it extends to 4-bytes for the Long-Word, as well.

Jiri Toman said...
The problem you have encountered has to do with the way PLC's
send out the serial data streams.

This is TRUE.

He then said...
The accepted industry practice is to send out the data in a BIG ENDIEN configuration.

This is FALSE.

There is no "Industry Standard". And there won't be as long as Intel and Motorola continue doing the way they do.

John Paley said...
My two cents--I think it's siemens who's backwards, not just because I'm an AB fan, but because siemens had hooks available in their system to easily reverse the bytes--like they knew it would need to be done,...

Then, Gerry said...
Just to add to the confusion...
The ControlLogix has a 'swap bytes' instruction to deal with this sort of problem.

Siemens and AB, both, have that capability because they recognize that the Big-Endian vs. Little-Endian thing simply "is" and needs to be handled.

John Paley also said...
The rockwell guy answered the question.

I didn't see that Rockwell answered anything.

John Paley also said...
Siemens deals with bytes, AB deals with words.

Both "deal with bytes". When AB calls for a Word, it calls for 2-bytes. Are you saying that AB can not call for a byte?

How siemens arranges the bytes for someone elses use as a word is of no consequence to them or thier processor.

Siemens follows the INTEL Standard.

The programmer simply had a 50/50 chance and blew it.

ALL programmers need to know that there is this "Big-Endian vs. Little-Endian" issue and then plan accordingly.


Jiri Toman also said...
I would like to bring to your attention a possible problem with reversing the byte order. If you have an even number of bytes in the data stream you have no problem, however if you have an ODD number of bytes, after reversing the order of low and high bytes, the last
integer will contain one dummy byte of data! Make sure that
your programmer understands that!

I don't know of any standard microprocessor instruction that calls for 3-bytes. Numbers, in any format do not exist in an Odd number of bytes.

Call for a Byte and use as is.
Call for a Word (2-bytes) and reverse if necessary.
Call for a Long-Word (4-bytes) and reverse if necessary.

It might very well be the case that someone calls explicitly for X-Bytes of data from some base address. "X" could be an Even or an Odd number of bytes. But to make a call on data in this manner is not calling for numbers. It is calling for a data-block-transfer.

If doing a "number" transfer from one system to another, call for the number type, i.e., a word (2-bytes) or a long-word (4-bytes), and then transpose as necessary.

If calling for a word, then, transpose...
X0 to Y1, and
X1 to Y0.

If calling for a long-word, then, transpose...
X0 to Y3, and
X1 to Y2, and
X2 to Y1, and
X3 to Y0.

I can't see any case where you would end up with a "dummy byte" of data if you transpose according to the data you are moving.

For those systems that don't provide a "nice 'n easy" way to do it...

After transferring a Word into a scratch area...

S = Base address of Scratch Long-Word
S0 = Source Byte-0
S1 = Source Byte-1

D = Base Address of Destination
D0 = Destination Byte-0
D1 = Destination Byte-1

Move S0 to D1
Move S1 to D0


After transferring a Long-Word into a scratch area...

S = Base address of Scratch Long-Word
S0 = Source Byte-0
S1 = Source Byte-1
S2 = Source Byte-2
S3 = Source Byte-3

D = Base Address of Destination
D0 = Destination Byte-0
D1 = Destination Byte-1
D2 = Destination Byte-2
D3 = Destination Byte-3

Move S0 to D3
Move S1 to D2
Move S2 to D1
Move S3 to D0

 

[Jiri Toman]

hmmm...

Terry,
Looks like you got all fired up?
Well since you feel so passionately about this subject let me just
answer some of your concerns (critique?).
First of all we are talking here about an ORDER OF NETWORK BYTES
not an ORDER OF BYTES WITHIN THE MICROPROCESSOR.
TCP/IP protocol suite is the most dominant protocol there is.
If you look at the ORDER OF NETWORK BYTES in the headers
you will find out that they pretty much follow the
big endian order. Not all of it but most of it.
If you look at the AB's EtherNet/IP specs you will see the same thing.
THAT CONSTITUTES A DEFACTO STANDARD!
Yes, the Motorola and Intel Micros manipulate data in a little endian order, but who cares? The network and the protocol suite do not care about the type of microprocessor used and how microprocessor manipulates data in its memory.

About the dummy byte.
Earlier versions of Logix5000 did not have capability to handle
strings. So in order to use ASCII data you had to pack it into
other data types. Should you decide to pack ASCII data into an integer you will end up with a dummy character (byte) if you have
odd number of characters in the string!
The way Logix5000 communicates with other legacy systems is to
Map the data in as either the PLC2, SLC500 or PLC5. The data
is transferred as Integers but Integers could contain ASCII
characters!
Hmmmmmmmmm.....

 

[Peter Nachtwey]

There is soooo much bogus misinformation in the above posts.

The Profibus DP standard says that a 16 bit value is sent big endian.

My company makes a product that is Profibus DP ceritified and we have a Contrologix and a SST-PFB-CLX that we use for testing.

The problem is not with the Contrologix or the SST-PFB-CLX. Our products works with both just fine. The SST-PFB-CLX puts makes sure the data get received and tranmitter from the Contrologix properly. The Control Logix know nothing of Profibus. To the Contrologix the SST-PFB-CLX is just a generic I/O card. It just sees a lot of data in its I/O image. Neither our product or the SST product have a means to swap the byte order. WE DO NOT NEED IT BECAUSE WE CONFORM TO THE PROFIBUS DP CERTIFICATION. WE DO NOT GIVE THE CUSTOMER A 50-50 CHANCE TO SCREW UP.

I would blame any device that give ones the opportunity to send data over the Profibus incorrectly. That would be....

Steve, it makes no difference whether the CPU is Motorola or Intel. Their opinion on who is right about byte ordering is irrelevant, only the Profibus DP specification determines how 16 bit data gets sent over the Profibus.

John, the Rockwell guy's answer is bogus except for that part about the 50-50 chance of getting the byte ordering wrong. I hope you didn't waste too much the Rockwell guy's time for something that couldn't be his problem.

Jiri, how many AB plc's are running using DF1? Did you know that DF1 sends the low byte first? Would you consider DF1 to be a standard protocol?

Gerry, what does a Control Logix swap bytes instruction have to with the problem?

Terry, the S7-300 and TI-505 are both BIG ENDIAN. Look at the CPU on your favorite TI505 and tell me it isn't a Motorola CPU. You should know better.

Stop guessing guys.

 

[john paley]

I tried to told joo. It's a BIG can of worms.

Terry--AB deals with words--even in the math register--siemens deals with bytes--even in the math register. If you want to look at a byte of an AB word, you have to move with mask and/or do a bit distribute to get the byte to the lower (upper??--who knows??) byte and read it as a word.

 

[Jiri Toman]

last post on this subject

Peter,
DF1 is a minor protocol in terms of the overall communication
and networking field. The data link layer of this protocol is
based on other protocols invented by IBM, Xerox and others.
The PCCC layer is specific to AB PLC's.
CMD/FNC combo, type of addressing and data type will determine how the data is presented in the PCCC layer.
If you use logical binary addressing and try to read or write from/to
integers you will see that the data is transmitted in a big endien
order.
DF1 reference manual page 7-37 gives you an example.
Otherwise feel free to use a protocol analyzer and look at the
actual data for yourself.

Have a nice day

 

[rsdoran]

Question..what is an endien? Is that suppose to be Indian (or to some injun)?

 

[Greg Gauper]

Possible reference to Gulliver's Travels???
I believe somewhere in the story there was an argument/war between two kingdoms as to which end of an egg to break open. The big end or the small end.

It's been a while since I read the book.

 

[Peter Nachtwey]

Guess again or RTFM.

If you use logical binary addressing and try to read or write from/to
integers you will see that the data is transmitted in a big endien
order.
DF1 reference manual page 7-37 gives you an example.
Otherwise feel free to use a protocol analyzer and look at the
actual data for yourself.

Have a nice day

The example you give shows the low byte being transfered first. That is little endian.

See also chapter 11 Order of Transmission.

 

[Terry Woods]

Jiri Toman said...
Terry, Looks like you got all fired up?

Huh? I guess you haven't been around very long. I don't think you've seen me fired up.

Well since you feel so passionately about this subject...

Again, I guess you haven't been around very long.

First of all we are talking here about an ORDER OF NETWORK BYTES
not an ORDER OF BYTES WITHIN THE MICROPROCESSOR.


TCP/IP protocol suite is the most dominant protocol there is.

Says who?


If you look at the ORDER OF NETWORK BYTES in the headers
you will find out that they pretty much follow the
big endian order. Not all of it but most of it.

Six of one, half-dozen of the other?

If you look at the AB's EtherNet/IP specs you will see the same thing. THAT CONSTITUTES A DEFACTO STANDARD!

WE ARE AB! YOU WILL BE ASSIMILATED!


Yes, the Motorola and Intel Micros manipulate data in a little endian order, but who cares?

Intel uses Little-Endian and Motorola uses Big-Endian. And, you're right, who cares... until you need to talk between types.

The network and the protocol suite do not care about the type of microprocessor used and how microprocessor manipulates data in its memory.

A network can certainly do a block-transfer. If both the Source and destination speak the same "-Endian" language, then, no problem. However, if the source is Big-Endian and the destination is Little-Endian (or vice-versa), then where does the "communicating" responsibility lay?

Does the sender simply transpose every 2-Bytes before sending? Won't Work! It certainly won't work if you are trying to communicate a Long-Word. Nor will it work if you are trying to communicate a Byte sequence.

I've always felt that if I'm trying to tell you something then it is MY responsibility to ensure that you know what I mean. If I have to provide you with some info, but you only understand numbers in a fashion that is backwards from my normal method, then I need to prepare those numbers so you can understand - else, no effective communication.

A "Translator" Network is not effective either. That is, if a network knows it is communicating between a "Big-Endian" system and a "Little-Endian" system, it, the network, still can't determine if a particular Byte is only a Byte, or part of a Word, or part of a Long-Word.

The only way that communication can occur is if someone (one end or the other, or both?) takes responsibility for handling the data-block. This can occur before the transfer or after the transfer.

Now it becomes a question of... Is the responsibility shared? Or is it on one end only? (Kinda like the Husband-Load vs. Wife-Load issue.)

Seems to me, in keeping with my communication philosophy, that the sender is responsible for sending what can be understood.


About the dummy byte.
Earlier versions of Logix5000 did not have capability to handle
strings. So in order to use ASCII data you had to pack it into
other data types. Should you decide to pack ASCII data into an integer you will end up with a dummy character (byte) if you have
odd number of characters in the string!

Tsk-Tsk. Maybe there's something to say about being "Byte Oriented".

xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Peter said...
Terry, the S7-300 and TI-505 are both BIG ENDIAN. Look at the CPU on your favorite TI505 and tell me it isn't a Motorola CPU. You should know better.

Hmmmmmmmmmmmm, Crow! My favorite! Especially with Ketchup (or Catsup, as you prefer)!


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

John Paley said...

I tried to told joo. It's a BIG can of worms.

So it seems.

Terry--AB deals with words--even in the math register--siemens deals with bytes--even in the math register. If you want to look at a byte of an AB word, you have to move with mask and/or do a bit distribute to get the byte to the lower (upper??--who knows??) byte and read it as a word.

In an AB WORD...

If you want to see only the MSB of a Word, then use "AND" Mask = FF 00

If you want to see only the LSB of a Word, then use "AND" Mask = 00 FF

In an AB LONG-WORD...

If you want to see only the MSB of a Long-Word, then use "AND" Mask = FF 00 00 00

If you want to see only the LSB of a Long-Word, then use "AND" Mask = 00 00 00 FF

xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Ron asked...
Question..what is an endien? Is that suppose to be Indian (or to some injun)?

And Greg Gauper said...
Possible reference to Gulliver's Travels???
I believe somewhere in the story there was an argument/war between two kingdoms as to which end of an egg to break open. The big end or the small end. It's been a while since I read the book.

Greg's response is absolutely TRUE.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Jiri,

I'm passionate about PLC's and the fact that they are microprocessor-based.

I usually post loooong responses because questions make me think, and I tend to write what I'm thinking. I know it helps me and I hope that it helps others. Sometimes I get a good serving of Crow, but then, I learn... I hope others do as well, learn, that is.