6/15/2009 1:44 PM | |
Joined: 10/7/2005 Last visit: 9/25/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/24/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/25/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/25/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 (193 Downloads) |
Last edited by: Enigma at: 6/16/2009 1:19 PM |
|
This contribution was helpful to2 thankful Users |
Follow us on