7/7/2013 11:07 AM | |
Posts: 8946 Rating: (999) |
puh, this little yellow minions make me addicted.... |
Last edited by: IBN-Service at: 7/8/2013 7:12 PM |
|
7/7/2013 6:52 PM | |
Joined: 1/28/2009 Last visit: 4/1/2024 Posts: 6836 Rating: (1359) |
Hello again, I just re-phrase again the points mentioned by Jürgen :
Best regards Hamid Hosseini |
Last edited by: hdhosseini at: 7/18/2013 9:49 PM |
|
This contribution was helpful to1 thankful Users |
7/10/2013 3:50 PM | |
Posts: 378 Rating: (73) |
Dear hdhosseini, Thank you for creating this discussion. Others have already posted above about IEC Timers and I want to say some about S5Time data type. S5Time data type is encoded time values ranging:
Problems: -> We can not use other values except in the above range (e.g we can't use 10s10ms or 1m41s990ms) S5Time Values: S5Time memory uses "16Bit" and the time values are encoded in 4Bit BCD value ranging from 0-999, (see the attached picture taken from S7 help file) [img=400x172]/tf/WW/en/postattachments/download?attachmentId=38322[/img] Wastage of memory area: Now it is not clear for me why not limited to only 999 (=9*100+9*10+9? Since each digit is represented by 4Bit BCD value and in 4Bit it is possible to represent 0-15 (0000 to 1111) therefore it is possible to represent the three digits 15*100+15*10+15=1665 from this case we can have a larger time values range for example: 0ms to 16s650ms ---- in 10ms steps Another unclear point for me is Bit-14 and Bit-15 is irrelevant, why not this bits included to extend time values range?S5Time datatype has "WORD (16Bit)" length but practically it has 14Bit of memory length--- This is another waste of memory. My Conclusion: The number of S5Time values is 999*4+1=3997, but it uses 16Bit memory and in 16Bit we can represent 216 + 1 = 65536 values thus the memory utilization efficiency = 3997/65536 = 6% thus I can coclude that S5Time datatype is 94% wastage of memory . Regards and Thanks all, |
Last edited by: desmul24 at: 7/10/2013 3:53 PM |
|
This contribution was helpful to2 thankful Users |
7/10/2013 4:39 PM | |
Joined: 1/28/2009 Last visit: 4/1/2024 Posts: 6836 Rating: (1359)
|
Dear freinds AMAZINGAHMED ,viralpatel and desmul24 Thank you for sharing your knowledge and experience regarding the topic.About the first cases proposed by "AMAZINGAHMED "and "viralpatel ", I add that as the main topics of concerns here.Mostly in factory automation, you need new features that not be provided by standard tools.Using cyclic interrupts OBs and plus clock memories of CPU recommended by Experts in the forum if there were a strong reason for that (e.g limitation and needed features).To complete this topic,I only provide some previously discussed issue for this cases: 1-Case for using OB3X for generating a simple on-delay timer Timer which does not reset itself2-Case for using clock memories for generating pulse patterns(in SCL) help on SCLCase related to deficiencies in SIMATIC Timer data type introduced by "desmul24" should be checked and compared with TIME data type and will be added soon in the 3rd row. I will rate all posts till my rating Budget re-charged Hamid Hosseini |
This contribution was helpful to4 thankful Users |
7/14/2013 12:12 AM | |
Posts: 197 Rating: (3) |
Sorry to interrupt such an interesting discussion. But I just noticed some remarks from desmul24under Wastage of memory area: Now it is not clear for me why not limited to only 999 (=9*100+9*10+9? Since each digit is represented by 4Bit BCD value and in 4Bit it is possible to represent 0-15 (0000 to 1111) therefore it is possible to represent the .......................". |
This contribution was helpful to1 thankful Users |
7/14/2013 5:11 PM | |
Joined: 1/28/2009 Last visit: 4/1/2024 Posts: 6836 Rating: (1359)
|
Dear Friends, Case related to impressive and detailed introduced by "desmul24" has been checked and will be added as "Deficiencies of SIMATIC TIME data type".Note,We inherited this data type from S5 Timers introduced in 1979,So please consider the limitations from that S5 era.May be in that time it was a great achievement with 16 bit variable.From our point of view from era of fast (64-32 bit) processors, it seems to be a deficiency.Points are listed based on chronology of original post.I do not quote but will mention the case:
We are encountering SIMATIC data type in new controllers SIMATIC S7 1500 only because of people are really accustomed to using this old heritage. Best regards |
Last edited by: hdhosseini at: 7/14/2013 5:29 PMLast edited by: hdhosseini at: 7/14/2013 5:21 PM |
|
This contribution was helpful to4 thankful Users |
7/15/2013 12:38 AM | |
Posts: 378 Rating: (73) |
Hello nbk, Thanks for your post The reason I have said "15" instead of "F" is for experession purpose only, It is obvious that there is no such thing 2,3.4 ... 15, or F in "Binarry world" it is a way of representation (saying) and expertly elaborated in the above hdhosseini's post. Thanks again |
This contribution was helpful to2 thankful Users |
7/17/2013 8:53 PM |
|
Posts: 621 Rating: (10) |
good topic ICE timers |
7/22/2013 3:56 PM | |
Joined: 10/7/2005 Last visit: 4/24/2024 Posts: 3004 Rating: (1046)
|
Dear all here's my take on things: First thing first, S5 Timers BCD format and "wastage" of bit 14&15 date back to the way a Time value was declared in an S5. Back thenyou had to explicitly declare the time base which was either 0 (10ms) 1(100ms) 2(1s) 3(10s) A 1 second Timer could as suchhad Setpoint of either: 001.2 (1*1s, accuracy of 1s) 010.1 (10*100ms, accuracy of 100ms) 100.0(100*10ms, accuracy of 10ms) Note how a dot seperated the (BCD) time value and the time base. The time base was as such simply taken over as the bipattern for thebit12&13, wheras the BCD time value used bits 0-11. Stating things like "S5Time datatype is 94% wastage of memory" is pretty meaningless in my opinion and their (16 bit) Setpoint is still 50% more efficient than an (32 bit) IEC Timersetpoint (let alone the already mentioend IDB storage that is consumed by an IEC Timer). As for other things to note about S5 Timers versusIEC Timers that I thinkhaven't been mentioned yetin this thread: 1.) Update: S5 Timers are updated by the operating system asynchronously to the user program scan. IEC are updated when called by the user program. Sounds trivial but can lead to unintended consequences when using S5 Timers and for example directly questioning the Timer (e.g. A T 7) in more than one place in the user program. The solution to this is to alwasy assign a bit to the output of the S5 Timer where it is started and then questionthat bit elsewhere in the user program. 2.) FC/FB Parameter usage: S5 Timers can be passed on to FC's and FB's, IEC Timers can not. 3.) Accuracy: S5 Timersaccuracy is based on its timebase. IEC Timers accuracy isconsistent across the whole setpoint range. Starting an S5 Timer for example with a setpoint of 10s meansit willbe counteddown by the OSin 100ms steps andas such have an accuracy of 100ms (i.e. it can expire anytimebetween 9.9s and10s). Starting an S5 Timer howeverwitha setpoint of 9.99s meansit will be counted down in 10ms steps and have an accuracy of 10ms (i.e. it can expire anytime between 9.98s and 9.99s). To make matters worse, in an S5 you had to specify the timebase (see above) and were as such aware of the timebase and accuracy (and would of course always nominate 1sec. as KT 100.0 instead of KT 001.2). The more user friendly S7 way of specifying the time for an S5 Timer now hides the timebase from use (and as such the accuracy). 4.) Software redundancy: IEC timers are supported as part of the redundantprogram, S5 Timers are not That's all I can think of for now on this subject and I hope it helps |
Last edited by: fritz at: 7/23/2013 2:03 AMFixed up expire time ranges Cheers |
|
This contribution was helpful to6 thankful Users |
7/22/2013 4:40 PM | |
Posts: 378 Rating: (73) |
Hello fritz, Thanks for detailed explanation, 94% wastage of memory is in respect to the capacity of 16bit memory not in respect to IEC timers. Regards, |
7/23/2013 3:08 AM | |
Joined: 10/7/2005 Last visit: 4/24/2024 Posts: 3004 Rating: (1046)
|
Hello Juergen all is well Down Under (or wherever else I've been in the past few weeks) and I hope you enjoy the summer weather in good old Germany. As for "S5 Timers can be passed on to FC's and FB's, IEC Timers can not": FC's/FB's have the parameter data type "TIMER" aswell as "S5TIME" which allows you to pass onthe S5Timer number and the S5Time setpoint respectively. For IEC timers you can only pass on the Time setpoint (parameter data type "TIME" which you correctly noted). As IEC Timers have no number (their IDB is their "number"), there is no "IEC timer number" parameter. You could though specify "BLOCK_DB" as an input and use it to pass on the IEC timers IDB to the FC/FB (which you wouldn't in case of an FB where you'd of course you the IEC timer as a multi instance call). I suppose this difference is probably more of a semantic nature than a anything else, but still a difference. Last but not least, one other difference between S5Timers and IEC Timers is that the S5 Timer outputs the remanining time (time counts down to zero) whereasan IEC Timer outputs the elapsed time (time counts up to the setpoint). |
Cheers |
|
This contribution was helpful to3 thankful Users |
7/23/2013 7:49 PM | |
Posts: 8946 Rating: (999) |
Fully agree. |
7/29/2013 10:12 AM | |
Joined: 4/24/2009 Last visit: 2/19/2024 Posts: 2683 Rating: (135) |
New question splitted to “hanging” outputs on IEC Timers? Best regards O_Moderator |
2/4/2014 11:55 AM | |
Joined: 8/27/2010 Last visit: 4/13/2024 Posts: 417 Rating: (37) |
Hi! I prefer to use clock memory and cyclic interrupt OB's
|
2/6/2014 1:47 PM | |
Posts: 378 Rating: (73) |
Hello Remark,
If you use SFC64, the error will be +/- 1ms +/- current_scan_time, thus depending on your program the scan time may vary each cycle therefore you can not predict your error range. In this scenario I prefer interrupt blocks.
Regarding siemens I trust siemens sites only, why not ""STAR - LIB"" is posted here and let the experts to brainstorm on it? Regards |
Follow us on