Worms get deeper!

[john paley]

Maybe you guys remember a thread I started a few weeks ago about some worms---integer bytes being transposed when sent over a Porfibus network from a Siemens S7-400 to a n AB controllogix processor.

Well, I have since found out that the profibus didn't do it--the siemens PLC does it. They're just opposite from the rest of the world with integers. Siemens uses byte sized (8 bits) addresses in their PLC's and have to use two consecutive memory addresses to store an integer--and they just do it reverse of the rest of the world--when loaded, the MSB goes in the first byte and the LSB goes in the second--how silly.

The thing that tipped me off is this--the PLC reads two status words (16 bit words) each from drives in the system over the profibus and transfers them to four consecutive memory addresses (8 bits each). Status bits 8 thru 15 go in address 0, 0-7 go in 1, 24 thru 31 go in 4, and 16 thru 23 go in 3. The bytes of the two words from a SIEMENS drive, are transposed in a SIEMENS PLC--they don't even handle their own data in the same way.

I was confused for a little while over this, as I was trying to ascertain the spicific nature of a poorly translated drive fault message to my Controller from the Siemens system. Bits 0-7 in the drive are in the second address of the PLC and 8 -15 are in the first. It was easy once I realized the bytes were backwards, but it was a pain in the a__ getting to that point--do all europeans do things bass ackwards??

While I'm bangin Siemens, listen to what else they did. They have an output module on this profibus--16 outputs. The outputs share common power for the output bits in groups of four. So one group of these four outputs energizes solenoids on one winding spindle, and another group of four does the same for the opposite spindle. The designer decided to interrupt the common power per spindle (4 outputs) via a limit switch so the solenoids only operate when the turret is in a specific position. That's OK for reasons of safety BUT----There's always a but----the removal of the common power causes an output module alarm (called "no load voltage" of all things), which in turn causes a red flashing Profibus light on the PLC front. This is not good--we have a perpetual red flahing profibus light--and it is a "normal" machine condition, as only one group of solenoids may be in position to operate at once. Very bad practice, in my opinion, but I guess I could be wrong. So if there's a machine problem, the floor electrician sees the red light and the first thing he does is start screwing around with the controller--trying to put out the light--when there's really nothing wrong with it. (I guess I could hang signs all over the damn thing that say "IGNORE ALL WARNINGS") By the way, this control system was done by siemens for the OEM of the machine. If the factory guys do **** like that, it worries me what else they did, or didn't do, that I don't know about yet--I wish Siemens would've have just stayed in Europe

To all you siemens Guru's out there--you can keep it.

 

[Peter Nachtwey]

ARE YOU SURE?

I know the Siemens S7 sends the high byte first over the Profibus DP according to specifications.

Yes, the S7 is a big endian PLC. This means that the high byte of the integer goes in the low byte of the two bytes holding the integer.

Is there some reason your didn't know that S7 are a big endian processor? It should have been obvious that the bytes were swapped.

It is not just a Siemens thing. Any processor that uses big endian format, like motorola, for storing multi byte objects will have this problem when accessing it as bytes . This is the price one pays for the priviledge of view the byte in the CORRECT order when doing a memory dump. It isn't a big deal if it is documented. To fix this problem Siemens would have to allow one to pick bits out of an integer or word instead of a byte.

I prefer little endian format. You have just point out one of a couple reasons.

About the 16 bit output card. What does the specification say it should do? The specification is a OEM problem. The Siemens guys probably just did what they were told in order to pass the acceptance test. It sounds to me like someone took or allowed a short cut.

 

[EltonJohn]

.. backwards, but it was a pain in the a__ getting to that point--do all europeans do things bass ackwards??

Yes, but don't forget San Francisco...

 

[Mike Williams]

It is awsome to see one of us figure siemens out. There systems really make you dig and a 5 minute problem takes days.

Some times you think some ******* sat down and said "lets do it backwards for the hell of it".

I will have to say siemens has made me better in writing code with ab.
We have not had siemens (tech support) in our plant (with alot of siemens on a flexo web press) for any help but our other plants pay them like a light bill. I do not think europeans do things like this on purpose, they use the system they have.

I wish every damn plc in America was AB OR PLC DIRECT OR GE, but it will never be so we just keep on keeping on.

I do not have anything against siemens but It would be better with a common system.

 

[kamenges]

As Peter said, once you get your hands around the fact that Siemens uses big endian format, it isn't all that tough to keep straight. You might want to look at the .GSD file for the ControlLogix adapter you are communicating with. I haven't used a whole lot of different Profibus devices but the non-Siemens devices I have used so far have all had a boolean switch to select between big and little endian data transmission format. This has made the big/little question a moot point for me so far.
The funny thing about the whole big/little endian thing is that I think the AB PLC5 series was based on a Motorola processor, which would have used big endian format. And I never remember running into a big/little endian issue with the PLC5. So the PLC5 firmware must have handled the conversion transparently when talking tothe outside world. No wonder its hard to get information out of a PLC5 with any kind of speed.

Keith

 

[JRW]

John,

I think your making a mountain out of a molehill-but anyway the S7 has an instruction called SFC 12 "D_ACT_DP". What you could do is
deactivate then reactivate the node with your logic. This would
get rid of your DP/EXT fault lights on your CPU. This S7 can do
alot especially the S7400. Sounds like you were throw into it- now
you hate it- what a shame.

JRW

 

[Ken Roach]

I've seen this byte-swapping effect recently, using Profibus products from SST. I had a customer scanning A-B PowerFlex 70 drives with the 20COMM-P interface with an SST Profibus scanner for the PLC-5 (there were other Profibus nodes, too, otherwise he would have used DeviceNet or something else more A-B centric).

Sure enough, the data came through byte-swapped. The A-B drive interface was made to work with Siemens scanners, not with scanners whose destination was an A-B data table.

I was surprised that I did not find a way to swap the bytes in a data table entry using the SST module configuration, nor did I find a way to fool the scanner into interpreting the drive data differently using the GSD file.

It was easy enough to work around in a ladder subroutine; a burst of Bit Field Distribute (BTD) instructions were executed upon data arrival in the PLC-5.

 

[rsdoran]

ifn i aint mistaken john we are in the same kinda business.

Looks like we have the same kinda problems but kinda in reverse.

So far I like Siemens S7 300/400 and its programming features, of course you are more involved with the programming then I am.

As someone stated I think you may be making a mountain out of a molehill, what is happening is a difference in what you know against what can be. What Siemens or AB does is not governed by any LAW or standard for that matter, at this time.

Think about it, what if you had learned long ago that data was transmitted MSB first then AB came along and did LSB first? All this **** depends on the firmware/hardwares interpretation.

Someone once mentioned intuitive on here pertaining to plc's. I am not sure I totally understood the meaning BUT so far when it comes to Siemens S7 300/400 it hasnt been hard to understand (there are some minor issues to get around because of the AB training though).

Anyway for this ol maintenace guy I like AB (because of familiarity) and like Siemens ( because it has some awesome features that are easy to understand).

To each their own but give the other a chance.

 

[Peter Nachtwey]

Two different problems.

John's problem is caused because his GSD file says he is transfering word data, but he is accessing as bytes to get to the individual bits. Siemens does not let one access bits by using MX0.15 to access the most significant bit of the word at MW0. PLC5s with the SST card does not have this problem because the PLC5 does not do byte addressing. PLC5 allow one to specify bits in a word such as N7:0/15.

I do beta testing for SST and I beta tested the PLC5 and the SST-PFB-PLC5. In my NOT SO HUMBLE OPINION the PLC5 and the SST-PFB-PLC5 is one of the best PLC Profibus masters available. Neither Siemens or Rockwell want to hear that because they don't want to admit Rockwell has a better Profibus DP master than their S7s and Rockwell just wants the Profibus to go away.

Ken, the problem you found is most likely in the slave device. It is probably sending the bytes over the bus in little endian instead of the big endian mode. You didn't say if the slave device is certified. If the slave isn't certified then don't blame the SST card or your PLC5.

FYI, the other Profibus master I like is the TI505. Some of my customers have also had success with the GE 93-30 and the second version Horner Profibus DP module. Siemens has only recently got their S7-318 upto the same level, but I haven't had a chance to test that yet. I will in the next 6 months. The ControLogix and the SST-PFB-CLX are pretty good but it only allows half of the data transfer capability of a PLC5.

SST does not give one an option to swap bytes and I agree with their philosophy. They support the standard and only the standard, as do we. I recommend only SST cards for the PC because they support the standard and only the standard. WHY GIVE THE USER AN OPTION HE DOESN'T NEED AND IS NON STANDARD?

Ron, there is a Profibus standard and a place to get the modules certified at Johnson City, TN. It is actually at the Siemens facility.

 

[rsdoran]

Let me see if I understand this correctly

Ron, there is a Profibus standard and a place to get the modules certified at Johnson City, TN. It is actually at the Siemens facility.

I understand there is a Profibus standard but does that state HOW the data is sent as in this case? I read alot on different standards, sometimes it doesnt always make sense to me.

I am going to re-read the info I have on Profibus.

 

[Peter Nachtwey]

Profibus should not be the 'Wire of Babel'

Yes, Ron, the specification says the data is sent over the wire high byte first or big endian. Those products that don't meet this specification should not be allowed to advertise their products as Profibus products.

The specification costs money or membership in the PTO, Profibus Trade Organization. Most of the info on http://www.profibus.com is just marketing propaganda. The specifications and how Profibus DP works are avaiable with a password at Profibus Trade Organization

We are currently making another Profibus DP product. If you have questions about Profibus DP, I will be able to answer as I am re-reading the specifications myself. BTW, our first product was the first Profibus DP slave to pass certification the first time, in the western hemisphere, and it took only two of the three days because the tests went so smoothly.

 

[john paley]

I think your making a mountain out of a molehill-but anyway the S7 has an instruction called SFC 12 "D_ACT_DP". What you could do is deactivate then reactivate the node with your logic. This would get rid of your DP/EXT fault lights on your CPU.

I don't understand all I know about this SFC 12 "D_ACT_DP", but it's worth investigation (I know how to use the help screens). It seems that when I re-activate, the fault will still be present at the output module. Or if you mean I should de-activate the node in place breaking power with the hard limits, I don't think, for safety reasons, I can do that. And if I could, I'd just hook the limits to input points and interrupt the output in the ladder, or STL, or whatever. Thanks for the lead. Hmmm, wonder why the Siemens programmer didn't think of that one???

This S7 can do alot especially the S7400. Sounds like you were throw into it- now you hate it- what a shame

Yes, it was thrown upon me, and, although I don't hate it, I don't prefer it either. And until I find out that it does something I need, that what I'm used to can't/won't do, I prefer what I'm used to (AB).

On the other hand, the more experience a body gets with various equipment, the more prepared the body is for anything else that comes along. I've spent years finding out what AB stuff can and can't do, simply by having a problem to solve and digging and trying different and new things until I reached a workable solution. (I still look at things I did 5 or 6 years ago and say to myself "Why'd you do it that way?? What were you thinking, you idiot?) Now I look at a Siemens system and think, oh boy, here we go again. Maybe I can get the guys I work for to send me to Siemens school to shorten the learning curve. That's Atlanta, right? They got beer in Atlanta, don't they???

As someone stated I think you may be making a mountain out of a molehill, what is happening is a difference in what you know against what can be. What Siemens or AB does is not governed by any LAW or standard for that matter, at this time.

True, in the case of the bytes--I agree, and it was easy once I realized the hi/lo byte thing--but not in the case of the "normal" fault indication. "I know" that "what can not be" is a flashing fault lite on a piece of my equipment where ther is no problem!!! Anybody who does this kind of work knows that it is up to the programmer to pay attention to the very last detail, or molehill. Somebody at Siemens dropped the ball with the profibus fault thing--no fault of the equipment's (cause I don't thing the designers meant the light to flash during a "norml" condition), but the guy who came up with the idea to do the solenoid interlock that way. I have thought of a solution that will fix the problem in the hardware (or I'll try the suggestion, above--if it don't take 2 weeks to figure out, what the with Siemens unfamiliarity, and all), and it is a little time and a little money--but guess what--it's gonna happen, cause prefer it or not, they're my molehills now.

The part about fixing it that irks me is when I have to go to the guys that did it in the first place and ask them if it's OK if I fix it this way. These guys are from Germany, and they never built anything that wasn't perfect, right out of the box. And they'll say, "why, what's wrong with the way it is? The winder is functional" And all I can say is "I don't like it that way" and tell them why. It's gonna end up bein' a big Pis_in' match.

Anyhow, thanks for lettin me vent and thanks for the suggestions.

 

[rsdoran]

OK, as y'all know I can be a little slow so I will make sure I understand correctly.

1. Siemens uses big endian processors or the process of Siemens plc's are big endian by default?

2. Profibus standard states that data is transmitted in big endian order?

3. By default AB and other brands may or do use little endian order to transmit data.

4. Any manufacturer that designs/builds under the Profibus standard should conform to big endian order for transmitting data.

We had a local distributor that changed from Siemens to Schneider Group/Square D products, I had gone to a couple of shows/seminars but not enough to fully understand its implementation/usage etc.

BTW john there training/support center is in Johnson City, TN, not too far from you if I aint mistaken. Checkout their website on training schedules/cost etc. http://www.sea.siemens.com/sitrain/coursesbyloc.html?loc=JCC&selloc=Johnson%20City%20-%20CCA

You can also goto the main page and look on bottom right corner for options
http://www.sea.siemens.com/index.html

 

[Peter Nachtwey]

The small company is always assumed to be wrong.

OK, as y'all know I can be a little slow so I will make sure I understand correctly.

1. Siemens uses big endian processors or the process of Siemens plc's are big endian by default?


Siemens S7-300s are big endian. I haven't tested s7-200s and S7-400 to be positive about them being big endian. Default? There is no choice. So are PLC5s and SLCs. That is most of the market.


2. Profibus standard states that data is transmitted in big endian order?


Yes.


3. By default AB and other brands may or do use little endian order to transmit data.


Rockwell has little to do with the Profibus DP transfers. The SST cards in the AB plcs take care of sending the data in the correct, big endian, order. The combination of SST and AB works well.

There are some PLC manufacturers that don't send the data in big endian format. I hate tech calls from customers that are using these PLCs with Profibus to communicate with our product. For some reason the end user thinks we are wrong and should swap our bytes around to be compatible with the little endian master. In many cases it has been the tech support of the PLC/HMI company that has told the end user we are wrong. I have had some heated discussions about this topic with the tech support, engineers and managers of some of these companies.


4. Any manufacturer that designs/builds under the Profibus standard should conform to big endian order for transmitting data.


Yes. Otherwise it isn't really Profibus is it? Say no.

I guess it is a bag of worms until the PTO prohibits companies from advertising that their product is Profibus compatible when they are not. My blood pressure is now 10 points higher.

 

[JRW]

John,

So whats the winder consist of? Is it a center wind application or surface winder? Is is a Siemens 6SE70?
Does it have a tech. board? T300 of T400?
I am sure- if you knew something about Step7,you would never
use AB again.
I've used SFC12 on applications where a piece of equipment had
to be detached (it had a few drives and ET200S I/O). The operator
would press a button on the screen, then detach the folder section.
The SFC would "turn off" the slaves- thus the OB's would not be called.
Presto- no red lights.

Would this work on your application?