6/9/2009 9:51 AM | |
Joined: 10/7/2005 Last visit: 9/23/2024 Posts: 3022 Rating: (1054) |
Hello gumis have a look at the attached pdf which is straight fromthe inbuilt S7help and should contain all the answers you were seeking (I hope). Cheers Fritz AttachmentConfiguring Short and Equal-Length Process Reaction Times on PROFIBUS DP.pdf (376 Downloads) |
Cheers |
|
This contribution was helpful to1 thankful Users |
6/10/2009 2:24 PM | |
Joined: 10/7/2005 Last visit: 9/23/2024 Posts: 3022 Rating: (1054) |
Hello again gumis sure can, open up the help from within Simatic Manager, go to the index tab and copy "Configuring Short and Equal-Length Process Reaction Times on PROFIBUS DP" into the keywordsearch box of it. As for what you measured, here are also some more "ideas" on things to checktoget abettter understanding on how "trustworthy" your measurement results are (assuming a setup with one PLC and one Simoreg 6RA70 DP Slave and nothing else on the bus): 1.) Find out thethe reaction time of your S7DQ card(e.g. a 322-1BL00 needs up 0.1 ms for a 0-1 transition, a 322-5GH00 can take up to 6ms for a 0-1 transition). 2.)Find out the reactiontime of your 6RA70 DQ. 3.) What type of instrument do you use to measure the times and what is its accuracy (and/or input detection reaction time)? All of the above can very well explain the difference in times for your 12Mbit/s measurement As for your9.6Kbits/s measurement, I'm not too sure how you manage to actually get it down to 40.4 ms. Ttr typical (typical/average response time as calculated by Step7(see bus paramter tab in HWconfig)) is some 87 ms for this baudrate in the assumend configuration (1 DP slave with PPO3). Anyway, I hope this helps at least somewhat and please keep us posted as it is a rather interesting piece of research you are doing (and ideally you'll connect a busanlayser tool (e.g. Profitrace) to verify that you have no repeats/illegal messagesand the likes happenning while you measure). Cheers Fritz |
Cheers |
|
This contribution was helpful to1 thankful Users |
6/15/2009 6:39 AM | |
Joined: 10/7/2005 Last visit: 9/23/2024 Posts: 3022 Rating: (1054) |
Hello again gumis since a picture tells more than a thousands words, please see attached one way on how to get to the bus parameters in Step 7. From experience (and verification of actual Ttr via Profitrace) the Step 7 calculated "Ttr typcial" valueis quite accurate (factors likes retries, acyclic data exhange, diagnostic messages etc. obviously can lead to longer Ttr's). The calculated "Ttr typical"in your case are: 12 Mbps: 0.3 ms 9.6 Kbps: 87.1 ms Ihope this helps Cheers Fritz |
Last edited by: fritz at: 6/15/2009 1:24 PMReplaced "The calculated response time in your case are:" with "The calculated "Ttr typical" in your case are:" Cheers |
|
6/15/2009 7:59 AM | |
Posts: 116 Rating: (1) |
Hi Fritz, Can you tell me which PLC cycles are included in this TTR time? Regards Paresh |
Last edited by: Paresh at: 6/15/2009 8:01 AM |
|
6/15/2009 10:57 AM | |
Joined: 10/7/2005 Last visit: 9/23/2024 Posts: 3022 Rating: (1054) |
Hello Paresh I'm not too sure if I uderstand your question correctly. The cycle time of your PLC program has nothing to do with the Profibus Ttr (unless you use"Configuring Short and Equal-Length Process Reaction Times on PROFIBUS DP", seemy earlier post for more on this). As for the calculation of the "Ttr typical" the following applies (see also the"HELP" button from the bus parameter screen"): All configured Slaves are in "pure" cyclic data exchange (i.eNone of the Slaves has diagnostic messages,noacyclic comms are taking place (e.g. no use of dataset readouts via SFC58/59 or SFB 52/53 etc.),no other active nodes like HMI system or programming device are on the busetc.) There is also a simplified generic formula available for calculating this time (in case you don't have Step7) which is (courtesy of Siemens, see also attached screendump from the Siemens Profibus brochure): DPt = NbDP · [OvPB + BitDP · (NbE + NbA)] / BdsDP NbDP: Number of DP slaves OvPB: Overhead of PROFIBUS message frame= 317 bit BitDP: Data format = 11 bit/byte NbE: Number of Input bytes:(max. 244) NbA: Number of Output bytes: (max. 244) BdsDP: Transmission speed I hope this helps Cheers Fritz |
Cheers |
|
6/15/2009 11:03 AM | |
Posts: 45 Rating: (0) |
Dear fritz: Could you define the term 'response time' in case of this topic? Regards, gumis |
6/15/2009 1:44 PM | |
Joined: 10/7/2005 Last visit: 9/23/2024 Posts: 3022 Rating: (1054) |
Hello gumis it is me being silly and writing "response time" when I should have written "Ttr typical". Hello Paresh PLC scan/cycle time is purely a function of CPU speed/power and amount of logic/code it has to "crunch" through. If you really want to calculate this yourself you'll need the "Instruction list" manual for your CPU, for S7-300 CPU's you can for example find it here. Alterantively (and much easier) you can view the actual cycle time online in the "Scan cycle time" tab of "Module information"(see PLC drop down menu -> Diagnostic/setting)or in OB 1's TEMP variables (OB1_PREV_CYCLE, OB1_MIN_CYCLE and OB1_MAX_CYCLE). Cheers Fritz |
Cheers |
|
6/15/2009 2:58 PM | |
Posts: 45 Rating: (0) |
Dear Fitz What is exactly the Ttr time? Where it is measured? |
6/15/2009 3:27 PM | |
Joined: 9/27/2006 Last visit: 9/22/2024 Posts: 12282 Rating: (2685) |
Hello gumis; Since I have a feeling you are going to come back to ask for more detailed information on the different bus cycle parameters for Profibus, look at the attached extract from a document from Acromag. Hope this helps, Daniel Chartier AttachmentProfibus_cycletime_parameters.PDF (286 Downloads) |
This contribution was helpful to3 thankful Users |
6/15/2009 3:40 PM | |
Joined: 10/7/2005 Last visit: 9/23/2024 Posts: 3022 Rating: (1054) |
Hey gumis I honestly don't know why I didn't think about this earlier, but there is actually a simple explanation for your measurements. What Ifailed to consider is that Ttr is the time for a complete Profibus scan (i.e. time for each response telegram to the Slave + time for each request telegram back from the Slave+ the minoroverheads (e.g.checking for another master on the bus,minimumSalve response time etc.)) I'll try to make it clearer by stickingwith your orignalexample as followed: One PLC and one PPO 3type 6RA70 DP Slave and nothing else on the bus. You have NOT configured Equal-Length Process Reaction Times on PROFIBUS DP (i.e. your bus scan is independent of your PLC cycle scan) Bus speed is set to 9.6 Kbps which gives a calculated "Ttr typical" of 87ms. PLC scan time is some 3 ms (which we willingnore in this case). Yourmeasurements were between40 ms and 88 ms. To simplify the example we assume that it takes exactly 40ms for the request telgram to go from the PLC to drive and 40ms for the response telegram to go from the Drive to the PLC (andthe remaining 7ms to make up a Ttr of 87ms will be considered the bus overhead which we'll gracefully ignore in this example). "Fast" 40 ms "reaction time" chain of events example: T=0ms: Response telegram from the Drive has just arrived back at the PLC and you"flick" the switch to set the(PLC Q0.0 and Profibus) output to "1". Your time measurement registers the PLC Q0.0 as being "1". T=40ms: The Profibusdata arrives at the drive (with output "1") and your time measurement records the Drive output as on which willgive you your "fastest" time of some 40 ms. "Slow" 88 ms "reaction time" chain of events example: T=0ms: The (independently running) Profibus is already busy sending the current output values to the Drive (which still has a"0" for the output in it). T=1ms: You "flick" the switch to set the(PLC Q0.0 and Profibus) output to "1". Your time measurement registers the PLC Q0.0 as being "1". T=10ms (arbitrarily picked,this could be 0 to 40ms): The Profibusdata arrives at the drive (which still has a"0" for the output in it) and the driveresponds back with its input values. T=50ms: The respond telegram from the drivearrives back at the PLC. The PLChas no other Slaves to poll (it will quickly "ping" for another Master) and then send the Outputs again to the Drive. This time the Profibus output also has a valueof "1". T=90ms: The Profibus output with avalueof "1" arrives at the drive and your time measurement of the Drive output will now give you your "long" time of nearly90 ms. Note that I picked T=10ms arbitrarily in the above example to end up with the desired result. This could however be a T=40ms value (i.e. the "0" value Profibus output telegram has just left and you "flick" the switch) in which case your worst case "reaction time" wouldbe measured as some 120 ms (40 ms request to the drive with value "0", 40 ms response back from the drive and another 40ms request to the drive)). Anyway, I really hope the above explanantion helps. Cheers Fritz |
Cheers |
|
This contribution was helpful to1 thankful Users |
6/16/2009 11:22 AM | |
Joined: 10/7/2005 Last visit: 9/23/2024 Posts: 3022 Rating: (1054) |
Hello gumis |
Cheers |
|
This contribution was helpful to1 thankful Users |
6/16/2009 1:16 PM | |
Posts: 49 Rating: (18) |
Dear all,
I have found two methods to do the same.
refer from page 36. BUS TIMING
Unlike CAN and Ethernet which are event-driven busses, ProfiBus was
TSYN = Sync-Time i.e. Bus idle time or ProfiBus Sync-Time (please refer manual for details) TMC (in TBits) = 198 + TSDR + TSYN + Tid1 now to calculate TMCsc = Time of 1 telegram cycle per slave would be
you may add the data for remaning slave to get the TMCbc (TMC for the DP bus)
All the highlighted fields in EXEL file are data entry fields,please modify only those fields.
WITH THE HELP OF General Formula (Which i found from some profibus forum, please find attached file Profibus_cycle_time by formula.xls)
Cycle Time = (Total Data / Baud Rate) * 2 (isnt this simpler than earlier one?? ) For your ready reference, I have already made an EXEL file for this calculation, please find attached file Profibus_cycle_time by formula.zip
__________________________________________________________________________________ Attachmentforum.zip (192 Downloads) |
Last edited by: Enigma at: 6/16/2009 1:19 PM |
|
This contribution was helpful to2 thankful Users |