S7 300 Backplane

[JesperMP]

I have seen before that the MPI port on a S7-300 CPU is connected to the backplane. Does that mean that it is the same bus or not ?

As S7-300 CPUs support 1.5M and 12M on the MPI port, does that mean that it would turn down the backplane response time if you choose 1.5M or 12M in stead of 187.5K ?

edit: Just found out that it is only 317-2 and 318-2 that support the higher MPI baudrates.

Maybe someone could test it.
Maybe RMA with his project with FM modules - eh ?

 

[nif]

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 must dissagree with you, the MPI address is there because you can program the module direct with the MPI-adress.

What kind of card is 352-5 ? I don´t have it my hardware manager..
If you want to syncronize outputs just put the cards in a new process image with the update time you want.

Are you sure that the CPU transfers the data directly to the card in the middle of the cycle when you call the standardblock?
I would imagine that the transfer is initiated at the end of the cycle when all outputs are written.

 

[nif]

The card is connected to the P-bus

 

[RMA]

Maybe someone could test it.
Maybe RMA with his project with FM modules - eh ?

Will try and have a look at it later on today, or tomorrow.

What kind of card is 352-5 ? I don´t have it my hardware manager..

It's a so-called "High Speed Boolean Processor". It has up to 15 DINs and 8 DOTs, as well as some Encoder Inputs (which double up as Inputs if you don't need the encoder. It's an FPGA (Field Programmable Gate Array) parallel processor with a 12 phase clock and 1µs cycle time. It's presumably intended for high speed machine control, I'm misusing it to synchronise output signals to better than 100µs (the customer wants 10µs, but I don't know if I'll manage that!).

As far as I'm aware it was only introduced last summer. If you're interested, you can find the manual here

Are you sure that the CPU transfers the data directly to the card in the middle of the cycle when you call the standardblock?

I'm not certain, but I have the impression FM constantly polls the CPU for fresh data - there certainly aren't any communication instructions in its instruction set. Communication is via a DB (per FM) exactly 14 Bytes long which is accessed in the FM as #CPU_IN.Bits[..] or #CPU_Out.Data. The 14 Bytes can be assigned any way you require as BOOL, INT, DINT, but the DB must always be exactly 14 Bytes long.

 

[nif]

The card is connected to the P-bus

why did this come two times ?

 

[RMA]

Just had a quick look at my 317 project and the only thing with an MPI address is the CPU itself. Neither the FM352-5s nor the CP343-1 IT are assigned an MPI address. Since there's nothing else on the backplane I'm not too sure how I could test the effect of changing the speed of the MPI link.

One thing I did note, in HW-Config I can set the MPI up to a max of 12 Mbps. In PG/PC communication in Simatic Manager I can select a maximun of only 1.5 Mbps.

I suspect as S7Guy says, the MPI limit is historical, not physical.

Also, I can't imagine that the backplane speed is affected by the MPI speed, otherwise Siemens would have mentioned this in the bit of the 352-5 FAQ which rsdoran quoted earlier on.

Cheers

Roy

PS, If somebody has some concrete ideas how we can test this, I'm willing to give it a go.

 

[nif]

SIMATIC backplane bus
187.5 kBit/s or 10.5 MBit/sec

 

[JesperMP]

Roy,
you could program an output and an input in that FM so that the output followed the input. If you then programmed the input (in the 317 CPU program) so that it switched depending on the FM output, you would then have created a bit flicker depending on the update of the FM over the backplane.

By the way, as the MPI port on the 317-2 is actually an MPI/DP port, I suspect that it has its own processor and is thus separated from the backplane. So maybe testing is to no avail.

nif,
where do you get those values from ?

edit: Roy, you probably have a serial MPI adapter or a USB MPI adapter. These have a max baudrate on the MPI side of 1.5M. You need a CP5511 or a CP5611 to go to 12M.

 

[RMA]

edit: RMA, you probably have a serial MPI adapter or a USB MPI adapter. These have a max baudrate on the MPI side of 1.5M. You need a CP5511 or a CP5611 to go to 12M.

Oops! Forgot about that, I had just hung the laptop on via the serial MPI adapter. On the HMI PC, which has a CP5611 in it, I can go to 12 M.

Will try your Bit flicker test out - may take a litle while though, I'm still struggling a bit with the FM352-5!

 

[JesperMP]

Roy,
upon further pondering on the matter - dont waste your time with testing that.

The MPI/DP port MUST be separated from the backplane bus. If you switched it to DP mode then what about the modules on the backplane - would they suddenly switch to DP too ? I think not.

The only way to test would be to use a 'regular' S7-300 like a 314 and change MPI down to 19.2K and see if the update times then becomes so much longer.
(Note: MPI on the smaller S7-300's can work in 19.2K or 187.5K only).

 

[rsdoran]

I am curious, y'all know I am not a programmer let alone an S7 expert. From reading the manual etc it seems there are 2 other options available:
1: The 352-5's could be programmed to work standalone, maybe just exchange data.
2. Profibus can also be used which definitely should be faster.

Personally I think the backplane is bus ASIC and offers its own form of communication between the CPU and devices. I know the 352-5 doesnt use an MPI address and uses addresses associated directly with the CPU.

I know I found that link that states the update times are around 1.5ms unless its the CPU that controls that aspect...that I can see now.

You may want to call Siemens support on this one.

 

[JesperMP]

Profibus can also be used which definitely should be faster.

Probably not I am afraid. If you put the FM352-5 on an ET200M Profibus adapter (for S7-300 modules), then I believe the ET200M will talk with same speed on the backplane as a CPU would do.

 

[RMA]

dont waste your time with testing that

Too late, I already started and ran straight into some problems, which I would have hit as soon as I came to try to get the real program running.

I wrote a nice simple two liner:

in OB1 - read Bit 0.0 in the input DB for the FM communication, if it's not set SET Bit 0.0 in the Output DB for the FM. If it is set, then RESET Bit 0.0 in the Output DB - simple, huh!

In the FB for the FM, Copy the state of the CPU_Out Bit 0.0 to DOT 0 and via a connector copy the state back to CPU_In Bit 0.0.

Couldn't get much easier, could it?

So, compile it - no problems.

Download it to the FM - no problems.

Try to run it - nix. FM in STOP, SF fault LED on.

Look in Module condition(? - Baugruppenzustand) and see that there's an internal error. The help file usefully informs me that I should use the diagnostic resources of STEP7 and the FM to identify the fault.

This is where things get tricky, in my relatively short S7 life I haven't had much call to do this so I don't know my way around very well - but what I found has just left me even more confused.

The first screen dump is the module state taken from the FM programming resource in HW-Config. Oh, by the way, the SF LED on the module is on.

As I don't know how to (or if it's possible to) load two pics, I'll put the second one in a new post.

Edit: Forgot to mention, all three FMs react the same way. And yes, I did have some Parameter faults initially, but I got them cleared OK.

 

[RMA]

And now the second ic from the HW-Config online view.

According to this there is no fault (and there's nothing in the diagnosis buffer either).

Where do we go from here?

 

[S7Guy]

Roy, are you saying that you didn't have a fault until you downloaded your test program? If so, I would look at bit 0.0 first. I don't have my old 352 project in front of me, but I seem to recall that the instance DB that is generated by that card has a bunch of paramterization values at the beginning of the block, followed by the actual control bits. If you are writing to 0.0, is it possible that you are stomping on something that the card needs to function? Also, I remember that I had to manually write to some of the DB variables for the card to work (module address comes to mind). Maybe they have improved this in your version. Look at the IDB online and see if everything looks normal.


Jesper, I agree that the backplane is a seperate bus. I mean, I use S7-300 cards with the U-connector on my remote stations with my 12mbps Profibus network, and it seems that a 187.5 baud on the backplane would be a hell of a bottleneck.