S7 315-2DP & PROFIBUS^3

i have three CPU 315-2DP's, connected via Profibus, all i need to do, is move short datablock (30 bytes) from CPU A and B to CPU C... (CPU C is equipped by Ethernet... so makes a storage for parent system - but this is circumstencial - but to explain) i've been able to locate this thread... and had created configuration as described...

http://www.plctalk.net/qanda/showthread.php?t=9745
(thanks dchartier!)

previously i've worked with profibus gateways... which requires specific speed settings and sync calls... but not with CPU's yet

the question is... if i call SFC15 on CPU A and B every second... how often i should call SFC14 on CPU C ? in order to gain best performace for whole PROFIBUS subnet? is better to read every cycle, or just every second?

SFC15 :: DPWR_DAT
SFC14 :: DPRD_DAT

most probably... there will be also OP, with much higher priority then this transfer function, whole project contain more MPI, PROFIBUS and Ethernet subnets... so i need to avoid some communication problems because some devices are MPI only and etc.

thanks for any timing responses

You don't need to call SFC because data exchange is configured already if you have configured hardware as described by dchartier. If you want data to be consistent you can apply Consistency field as "All".

i guess... this should work only with real IO... to transfer datablock content... you need to specify which datablock will be transfered... this is what SFC14/SFC15 does....

if i'm wrong, please correct me

I suggest to read this link first. You can transfer your DB content either by using SFC or by the way described in this link (transferring DB data to/from DP data area).
http://www.plctalk.net/qanda/showthread.php?t=23745

quite confused ...

this thread is again about 'unit' consistency... my profibus input/output area is set to I500 and O500 for master->slave with 'all' consistency ...

if i try something like
L DB40.DBD 40
T QD500

cpu simply generate configuration error and tries to crash, so i call it like this (1f4 is 500 in decimal format) and it works well...

// SLAVE
CALL "DPWR_DAT"
LADDR :=W#16#1F4
RECORD :=P#DB6.DBX0.0 BYTE 30
RET_VAL:="profibus".retval

// MASTER
CALL "DPRD_DAT"
LADDR :=W#16#1F4
RET_VAL:="profibus".retval
RECORD :=P#DB8.DBX0.0 BYTE 30

maybe i'm blind... but what i'm doing is sending of 30 bytes from DB6 in one CPU to DB8 in second CPU, and i don't see way how to do it using only I/Q ... because assigned Q area cannot be for some reason accessed directly from code ?

... so if there is no need to use SF14/15 how i do write BYTE to Q area without CPU crash? or how exactly do i tell area to get it from datablock?

i also read this one http://www.automation.siemens.com/download/internet/cache/3/1370368/pub/de/d06_cpu315_cpu315.pdf
that's again about 'unit' consistency


back again... what i created, works well for now as deep as i tested... what i do not uderstand is how to perform action to stay most efficient... these data "really need" to be transfered every minute for parent system... so won't send them every cycle, just every few seconds or second... -> what i don't understand and couldn't find is: if i call SFC15 at slave every second... what will CPU do in bacground?... will it be sent repeatedly until SFC14 called at master, or it will be send to some masters buffer, from there next following SFC14 just pick-ups it...? or will it be sent and if SFC14 not called immediately, data are lost?

so... my current schema is that SFC15 is called every second at slave, and SFC14 is called every cycle at master to succesfully get it...

1. CPU tries to crash because it's process image area is limited to 128 bytes. Try to use PQD instead QD. But you can use SFC14/15, of course.
2. Slave cann't initiate data exchange. All is done by master request. Try to remove SFC from slave program.
3. I amn't sure about details of bus activity in case of I-slave. But both CPU stop if required OBs aren't downloaded even if you don't use data defined as DP exchange area when one partner is off. IMHO, this means bus activity on hardware level. But this activity checks master and slave presence only, I think. If you call SFC in master once in minute, this really can decrease bus loading, IMHO.

oops, just one letter

PI/PQ... well... ok, that was easy, i guess i should really get some sleep today

... 'the crash' i meant is not the one with missing OB, i'm not so that dumb yet ... thats just if you compile it with STL writen to I/O instead process I/O, which difference i didn't realize before, it refuse to compile properly nad cpu will crash...

i have doubts if this will speed communication... but thanks for the hint anyway!