Skip to Content

SiePortal

The integrated platform for your product selection, buying and support workflow - bringing together Industry Mall and Online Support.

SiePortalDeutsch

Search

Home
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menu temporary not available
- Menue temporary not available
- {{item.title}}

Products & Services
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Support Support
{{(apiData.Support | filter:{'rank':1}:true)[0].title}} Support
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
MySiePortal MySiePortal
{{(apiData.MySiePortal | filter:{'rank':1}:true)[0].title}} MySiePortal
- Menu temporary not available
- Menue temporary not available
- {{item.title}}
Cart ({{apiData.CartCount}})

Navigation

S7 Multi CPU Input sharing

Created by: safety4ever at: 11/30/2010 3:57 PM (10 Replies)

Rating (0)

Thanks 0

Result pages:: |; 1 | 2; |

11 Entries

Entries per page: 10 | all

11/30/2010 3:57 PM	Rate (0)
safety4ever Experienced Member Joined: 12/5/2006 Last visit: 3/4/2025 Posts: 73 Rating: (4)	We are in the process of migrating an old multi processor 155U to and S7 400. The old system did consist of 3 CPU's sharing inputs through DB1 definitions. Coming to the structure of the new system we would repeat the same HW configuration using 3 416-3 processors on a single rack. The issue that we experience that the I/O's are all ET200U that will not be replaced at this stage but will have to be accessible between at least 2 CPU's (Only inputs) i.e CPU 416 #1 would have to read input byte 1 as well as CPU 416 # 2. I was going through the forum and found some topics on the slave sharing with multi masters but it did not quite respond to my situation. Are there any work around thansending those inputs between CPU's using BSEND and BRECV for examplethrough backplane bus? I was also trying to configure 2 identical Profibus network on the2 different CPUs although the bus is different they did not accept the same addresses for I/O's. Any hints would be appreciated.

Suggestion To thank Quote Answer

11/30/2010 10:55 PM	Rate (0)
sfa Posts: 70 Rating: (3)	Hi Safety4ever First of all. why not go for a single 417-4 ? - you'll get three full size profibus masters and lots og process power and plenty memory. (not knowing your actual requirements though) Anyway... Multicomputing shares the entire I/O area between all the cpu's in the setup. I.e. if the range I1000.0 to I1001.7 is defined for CPU1 profibus, then the others cannot use this range for hardware (profibus nodes) They can however access (R/W) the memory, but IO has no data unless you make some kind of transfer from the CPU "owning" the IO. The transfer can be realised on the profibus network with DP/DP couplers or as communication with S7 connections (BSEND or PUT). The S7 communication can be done on the backplane bus (relativly slow) or on a small profibus network between the MPI ports on the CPU's (Fastest way possible). /søren
sfa Posts: 70 Rating: (3)
Suggestion To thank Quote Answer

12/1/2010 1:36 PM	Rate (0)
safety4ever Experienced Member Joined: 12/5/2006 Last visit: 3/4/2025 Posts: 73 Rating: (4)	Hi Thanks for your answer I thought about the 417 however the three s5 CPU are used to their Maximum i.e S Flags, 593 block per processor so I am not sure how many flags the 417 does permit but I converted one cPU already and my flags are everywhere lot of Graph7, so there would be lots of rewiring for addresses and may be some more errors for the conversion (specially with many indirect addressing instructions) Do you mean the external MPIconnection(Global Data) is faster than the backplane bus,I would imagine once the data is movedit could be remaped to the inputs at the start of OB1 cycle, as the old processors S5 haveshared the inputs and using the inputs all over the program in this case there would be norewiring of signals needed. This wouldmainly be similar to mapping the data over DX(Data Exchange) on profibus unfortunately the ET200 U are too old to allow this. Thanks

Suggestion To thank Quote Answer

12/1/2010 2:59 PM	Rate (0)
sfa Posts: 70 Rating: (3)	Hi I avoid Global Data for time critical functions. Use the internal ports e.g. the MPI in a small local network and configure them as profibus with three partisipants. Make S7 connection in netpro and use e.g. Put functions from the owner of the IO. (or BSEND) Please see this thread where I have shared some gained expirienceregarding multicomputing configurations and internal communication. Søren
sfa Posts: 70 Rating: (3)
Suggestion To thank Quote Answer

12/1/2010 8:21 PM	Rate (0)
safety4ever Experienced Member Joined: 12/5/2006 Last visit: 3/4/2025 Posts: 73 Rating: (4)	I am a bit confused when you say internal ports are you talking about the 9 pin ports, I understand that this would still be kept in MPI not DP. I have tried the backplane bus I using FRSEND and FR RECEIVE (Special blocks done by Siemens SE&A in US I guess they are using SFB12 and SFB13, I there a way to compare this with the MPI communication speed. Now you also mentioned that using Put or BSEND could directly more the IW to IW, definitely this would be more beneficial as I did not want to use and DB in the middle. this would take an SFC 20 call on each CPU Thanks

Suggestion To thank Quote Answer

12/2/2010 7:57 AM	Rate (0)
sfa Posts: 70 Rating: (3)	Hi The first internal port is the MPI port. It can be operated as a fully functional 12mbit profibus but only supports 32 nodes (electrical limitation). So if you do not use the MPI for anything else that will be a good solution. The advantage you get by using the internal ports opposed to a communication card is taht you avoid the delay on the backplane. Just "PUT" or "GET" the I or Q area you need to move between the CPU's. If you toggle a bit in such a interface you can meassure the responstime and verify that the function is sufficient fast. /søren
sfa Posts: 70 Rating: (3)
Suggestion To thank Quote Answer

12/2/2010 12:52 PM	Rate (0)
safety4ever Experienced Member Joined: 12/5/2006 Last visit: 3/4/2025 Posts: 73 Rating: (4)	Thanks Soren I have tried this yesterday it seems to work properly and fast enough using the PUT and GET blocks, the only thing I do not like about this is that anyone thinks MPI is a programming port and could mess up with the cables removing them to put a programming cable without realizing the importance of this interface usually profibus people are more carefull. But otherwise it seems even simpler than the blocks I have used before where they need a DB buffer and use SFC 20 to move the input. This has been really helpfull. Best regards Shadi

Suggestion To thank Quote Answer

12/2/2010 5:45 PM	Rate (0)
sfa Posts: 70 Rating: (3)	Hi I'm delighted that my expirence can help others - please rate me accordingly if you think I have earned it. Anyway - you should use proper profibus cables and plugs. Make sure that the plugs are tightned properbly, chose the plugs without extra DB9 on the back. There is a rumor going around (at least in my company) that there is a minimum distance between profibus nodes. That is not correct and I have very good expirience with just less than 20cm cable - please consider bending radius of the cable. For online access, I allways use ethernet(TCP/IP). Only firstime configuration is done via MPI or even better through iso on TCP and MAC address on CP-443 cards (requires that you are on the same subnet with the PG). Søren
sfa Posts: 70 Rating: (3)	Last edited by: sfa at: 12/2/2010 5:51 PM Online access comment
Suggestion To thank Quote Answer

12/3/2010 5:15 PM	Rate (0)
J_Bell Posts: 5822 Rating: (412)	Hello, I am sorry, but I would recommend useing this way: S7 Communication via K bus with the S7-400 MPI is by far not as fast as the K-Bus. Best regards J_Bell
J_Bell Posts: 5822 Rating: (412)
Suggestion To thank Quote Answer

12/3/2010 7:08 PM	Rate (0)
safety4ever Experienced Member Joined: 12/5/2006 Last visit: 3/4/2025 Posts: 73 Rating: (4)	Isn't the K BUS using MPI also for communicating to other CP, FM cards on the rack as well , I have tried to read in the S7 400 documentation 400 Specifications manual to see anything about the internal bus speed (K bus) but I could not find accurate information aboutit with numbers for example we all know MPI can not go higherthan 12MBits/sec. There will be also lots of modules on this rack between FM cards and other CP's, 3CPU's I do not know if this would affect the performance ofcomm over the BP bus.

Suggestion To thank Quote Answer

|

Share this page:

Share this page on...

Follow us on