PDA

View Full Version : Worms get deeper!


john paley
November 22nd, 2002, 03:00 PM
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
November 22nd, 2002, 04:09 PM
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
November 22nd, 2002, 04:47 PM
Originally posted by john paley

.. 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
November 22nd, 2002, 06:41 PM
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
November 22nd, 2002, 11:28 PM
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
November 23rd, 2002, 09:14 PM
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
November 23rd, 2002, 10:23 PM
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
November 23rd, 2002, 10:28 PM
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
November 24th, 2002, 01:58 AM
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
November 24th, 2002, 10:22 AM
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
November 24th, 2002, 11:15 AM
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 (http://www.profibus.com)

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
November 24th, 2002, 05:13 PM
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
November 24th, 2002, 05:15 PM
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
November 24th, 2002, 06:21 PM
[QUOTE]Originally posted by 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?


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. :furi:


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
November 24th, 2002, 08:57 PM
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?

BobB
November 25th, 2002, 04:29 AM
I am quite surprised that this is the first time you have seen this. I use mainly Omron PLC's and have found words swapped on Modbus RTU from Nemo power monitors (Italian). I have also used Device Net extensively and found information read from an AB Powermonitor 3000 by explicit messaging was received with bytes swapped and words swapped.
With the Device Net trick, "Praise The Lord" I knew what information I was looking for and it did not take long to work out what had happened (only about an hour pulling out what little hair is left). The "Swap Byte" function worked a treat - just specify how many words and it does it seamlessly. Swapping words is a little more difficult as, despite Omron's huge function list, the latest PLC's do not appear to have a swap word function. "Move" and "Transfer" used extensively.
The Modbus RTU one took a little longer. Finished up using a serial port protocol analyser called "PAT". Very good. Then figured it out.
The following "Beerchug" indicates the next port of call.
beerchug

john paley
November 25th, 2002, 04:09 PM
JRW,

So whats the winder consist of? Is it a center wind application or surface winder? Is is a Siemens 6SE70?

It's a dual spindle turret paper re-winder with a pair of Simovert Masterdrive VC's on each winding spindle. There's a simovert VC for the turret index motor, as well as a Simovert MC drive as an outfeed nip drive.

Does it have a tech. board? T300 of T400?


The winders have, I think, T400 boards for the coiling application. The documentation I have (OEM supplied) and can find on the website is vague. Apparently, the T300's are no more--that's why I think we have T400's--that's the documentation I find on the web site.

I am sure- if you knew something about Step7,you would never use AB again.

I know this about Siemens--the simovert manual says the drive supplies 32 bits--4 bytes--of status to the profibus--The PLC reads 3 words--2 from the drive--one from the technology board--After you get past the little/big endian thing, the drive documentation is OK but the tech board documentation is very very unclear about what the 16 bits from there represent.

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.

My system uses the Et 200's also. The problem is, that they only interrupt the power to 4 of the 16 outputs at once. If I use the SFC12, I kill all 16. No can do--need the others. I could simply wire and program the Position LS's into the ladder and interrupt the output coils there, but this steps on the Hardwired interlock--which is the crux of the thing here--they wanted a hardwired interlock to the solenoids, and they got one--but their ill concieved method causes a failure indication. I thought that maybe there might be a way to mask, or ignore, the individual faults from any given node of the Profibus, but can't find anything in the books to support anything along that line.

I plan to install a pair of 4 pole relays and interrupt the power to each solenoit at the output end of the module, rather that at the power supply end. I guess I should disconnect them all before I do all the wiring, first, to see if this method causes some kind of "open output device" alarm on the module. If that's a problem, I'll do somethin else. As Senator Howard Baker said once as he sat at the Nixon Watergate hearings " As we say down there in Tennessee, there's more than one way to skin a cat.

On the detached equipment application. We've done a little of that. I have a piece of equipment, a folder/gluer, which utilizes 2 seperate pieces of support equipment, feeders, at different times. Both feeders are controlled by the main machine's PLC. Both feeders have different features with different control schemes and different types of devices that "share" I/O and wiring in/to the main controller. Both feeders connect to the main machine via the same electrical connector plug--one feeder or the other. There is logic to control each feeder in the PLC. The PLC recognizes which code to run via a jumper on each of the feeders connector--it knows which one is plugged in at any give time. If the operator wants to change feeders, he just unplugs, rolls out, rolls in, re-plugs, and the controller takes care of the rest. This system was done in house with AB--not siemens, software--not hardware, well concieved ideas--not "lets make it work and get outta here" attitudes.

Jay Anthony
November 25th, 2002, 05:44 PM
Swapping words is a little more difficult as, despite Omron's huge function list, the latest PLC's do not appear to have a swap word function. "Move" and "Transfer" used extensively
Bob:
Here's a few pages on the SWAP and XCHG functions in the current Omron instruction set.

BobB
November 27th, 2002, 03:40 AM
Thanks Jay but I have used them both extensively. Quite used to the manuals, all 3 inches oe so of them. Have been using and/or selling Omron for 15 years or so. Love the "SWAP" byte function - start word and how many words entered and it is all over. Would like to see "XCHG" set up the same way instead of having to write an "XCHG" function for every pair of words that need to be swapped.
Love the digital library that has been released in Australia. Do not know if you have it over there yet. If not, contact Omron Australia for a copy. It gets better every issue.
I hear from people in Oz that you are a bit of a guru. Quite a compliment.
Regards
Bob
beerchug

kevingillie
November 27th, 2002, 02:27 PM
Nutin' but worms!

I have worked with Profibus extensively in the past couple of years. I have seen the byte swapping quite regularly. Basically it is a difference in processor families used in the devices and masters. those processors that run on a Intel base format and those that mimic the Motorola format read in opposite directions, Intel reads from right to left and Moto. from L to R. therefore MSB and LSB get swapped. First practice I have inherited is to "ring out" the I/O on the network to make certain which slaves swap bytes and which don't back at the master.

Profibus standards have not implemented specifics as to weather the master should "clean up" the incoming data.

I hope this offers some insight. It's not really wormie just a difference between product vendor hardware. banghead

Regards.