S7 300 Backplane

RMA

Member
Join Date
Sep 2004
Location
North of Hamburg, Germany
Posts
2,052
Does anybody know where I can find a description of the S7 range's Backplane - transmission speeds and protocol. I'm interested in finding out how fast I can transfer data between a 317-2 DP CPU and three FM352-5s on the same bus.
 
I've spent the best part of half-an-hour digging round the Siemens site - to no avail. I'm not sure if Siemens consider that to be proprietary info, that they don't want you to know, or whether they just consider it irrelevant.

Could always be that I didn't come up with the right combination of keywords, of course! :rolleyes:
 
Is this what you need? http://www4.ad.siemens.de/-snm-0135...se&objid=10805159&siteid=cseus&subtype=133000

QUESTION:
How long is the SPS-updating-cycle-time for the FM 352-5?

ANSWER:
The SPS-updating-cycle-time is the time typically required for the transfer of data via the backplane bus, or respectively the updating time for the data transfer on the backplane bus (Bus-ASIC).

The time is different from the actual FM-cycle, which runs according to µs-time.

During the last update (firmware version 3) the SPS-updating-cycle-time was further reduced to (now typically) 1.4 to 1.5 ms (max. 1,7 ms).

The Entry-ID: 9240171 (chapter A.5 in the manual) still lists the old value.
 
Last edited:
RMA said:
I'm not sure if Siemens consider that to be proprietary info, that they don't want you to know, or whether they just consider it irrelevant.

It is proprietory. This means one of three things:

1 The bus is very good and use some very neat technology they don't want to share with their competition so Siemens can keep a competitive advantage.
2. The bus isn't that good and they don't to want their competitors know they already have a competitive advantage.
3. They don't want third parties making boards for the back plane. This causes support issues.

Case 3 almost always applies. You can choose between case 1 and 2.
 
Hello guys;
The protocol used by Siemens on the S7 backplane is simply MPI, at 187,5 kB. Which is why FM and CP modules are attributed an MPi address in HWConfig: they use MPI token-passing to exchange data with the CPU.
I don't remember where that info is available on Siemens' website. I do know that it ia part of their training manuals for the advanced classes on the S7-300.
Hope this helps,
Daniel Chartier
 
rsdoran, thanks, that was what I was after - my brain seems to run on a different wavelength to the guys who write the help files, be it Siemens or Microsoft. I never come up with the right keywords!

It also confirms what I suspected, the backplane is too slow and too variable for what I wanted to do.

Thanks again

Roy
 
The protocol used by Siemens on the S7 backplane is simply MPI, at 187,5 kB.

Daniel, I knew the backplane used MPI, but are you sure that it is at 187.5? I thought the backplane ran at 12 Mbps, but for the life of me I can't remember where I got that info. I can even go into the hardware config and set the MPI baud rate to 12 Mbps if I wanted to. I always thought the typical baud rate of 187.5 was a limitation set by the connected devices on an MPI network (probably from earlier days), and that MPI was in reality very similar to Profibus. Or maybe I'm wrong about that.

Also, I have some white papers from Siemens that offers a very thorough study of bus cycle times, and the backplane bus transmission time was negligible, for what it's worth. I will post it if I can get permission.
 
I hadn't thought about it before, but the backplane must run faster than 187,5 kbps otherwise there is no way they could achieve the 1.4 - 1.7 ms CPU - FM update times quoted in the FAQs that rsdoran dug up for me.
 
I think my link above is incorrect....I do not know what SPS is either. This manual states:
Response Time during Program Execution
As noted before, the response time of the FM 352-5 is extremely fast. In normal
mode operation, the response time is measured as the elapsed time from the
change of an input until the setting of an output.
The calculated response time consists of the following components:
• Input delay (circuit delay + filter delay)
• Program execution time (1 µs)
• Output circuit delay
http://www4.ad.siemens.de/dnl/jkzMTgzNQAA_9240171_HB/fm352-5_e.pdf

I can not find any reference to MPI being used in HWconfig. Since it can use Profibus doesnt that offer "real time" capabilities?
 
Last edited:
I will add my two pennys worth to this thread.

The backplane has two bus's, P and K. The P bus is for the I/O update and the K bus deals with the communications updates.

I don't know what the speeds are, but I just remember the above from the siemens networking course I attended just over a year ago.

I also had a good look through the siemens support site for more information on these bus, but I only came up with the document that Ron has already linked to.

Not much help for you here, Roy.

Paul
 
No, that's an extract from the FM352-5 manual and refers to the latency of the FM352-5 program itself.

My problem is that I'm having to synchronise 21 outputs and this means I'm using 3 FMs. I assumed the easiest way was to use one of the spare outputs to drive one input on each FM, so that they all get the Trigger signal at the same time (accurate to ~1 micro-second - how come ALT GR + M doesn't work on my laptop?) but it irritates a little as it seems a bit primitive. If I only had 1 FM there would be no problem since although I require a relative accuracy < 100 micro-secs, absolute time is totally irrelevant. But with 3 FMs that means loading 3 DBs with the trigger signal and transferring the contents of each DB (14 Bytes) over the backplane to each FM one after the other - bye bye synchronisation!

Paul, you came in while I was posting, and all information is still welcome, however rsdorans original link did deliver the information I needed - or better it confirmed my suspicion that I'm going to have to use a DIN on each FM to satisfy my synchronisation requirements. Even better, one of the other FAQs told me how I need to wire it from the DOT in the third FM, which saved me having to go looking for that info later on!

Many thanks to one and all,

Cheers

Roy

PS My Tips and Tricks to the FM352-5 is still very much open for further offerings!!!
 
Last edited:
Paul

The P-bus and the K-bus apply to the S7-400 only. Damned if I can remember right now which is which, but one runs very much faster than the other - I think it's the K-bus. The 400 obviously has the fixed hard-wired backplane which permits the 12MB K-bus (and allows hot-swapping of cards etc).

The poor old S7-300 just has these little U-connectors which only carry a P-bus at a much slower rate, very possibly the 187.5KB mentioned earlier. Pull out a module inthis family and the whole backplane bus stops right there. (There is a hardwired backplane for S7-300 and ET200M as well, but very few people seem to use it apart from H or F systems.) I guess the 300 was built to a price and the 400 was built to a spec.

Regards

Ken.
 
Ken M said:
Paul

The P-bus and the K-bus apply to the S7-400 only. Damned if I can remember right now which is which, but one runs very much faster than the other - I think it's the K-bus.

Damn!!! I remember one snippet of information from over a year ago and I get it wrong!! :rolleyes:

Thanks for putting me right Ken (y)

I would imagine that the K bus runs faster, as I am pretty sure I got their uses right, even if I got the incorrect backplane!

Paul
 

Similar Topics

Hi Guys. I hav an general question about data traffic between CPU and CP on K-Bus backplane. We got an issue where a vendor has an S7-300 cpu...
Replies
4
Views
2,299
Hi all I'm a french student and I have a research project which consists in detecting the late of the I/O cards and the internal bus of a S7-300...
Replies
4
Views
2,455
Have a system that has been running for over a year and all of a sudden getting a ExcessiveVelocityFault on one of the drives when the MSO command...
Replies
2
Views
136
Hello PLCS.Net Forum, First time posting. Let's assume I am a novice. BASIC PROBLEM: My servo/linear piston is no longer zeroed to the...
Replies
9
Views
201
hi... i have an issue in s7 300 plc, while we run the machine(in idle there is no fault) , plc cpu goes in SF mode, after restart the power cycle...
Replies
2
Views
107
Back
Top Bottom