Thanks for the reply.
I will try your codes on simulator (and with all due respect I know it will work)
But I just wanted to know what is the EXACT reason for M100.0 for not getting set in my original codes.
In short, can u explain in words , why it doesn't get set?
Regards
Dear hardy,
Just 1 more thing with respect to your modified codes:
I haven't simulated your codes yet ......... but do you mean M100.0 will get set after 10s ?
Plz comment back.
Regards
The reason is, that timers works asynchronous to the Step7 program. When you wait long enough, the Marker 100.0 will be set, depending when the timer will elapse (tested on a real CPU).
| When timer elapse here, first T11 will be set back and then also T10 -> M100.0 can't be set.
AN T10
L S5T#5S \
SD T11 __\
_________ \
A T11 ____| When timer elapse fortuitous here, -> M100.0 will be set.
L S5T#5S _|
SD T10 __/
_______/
A T10
S M100.0
| Also here -> when timer elapse here, first T11 will be set back and then also T10 -> M100.0 can't be set.
When you shift the last two statement on the top, M100.0 will always be set, when timer T10 elapses, because there is no condition before the two statements that could reset first T11 and with that T10.
Dear sventek,
Many thanks for the reply.
Definitely, u gave the insight of the s7 STL codes (Thx again !)
My estimate was this (which may be wrong):Since the timers are updated every 10ms, the scan of CPU may not be able to set M100.0 immediately below the original codes. However, when the last 2 statements are relocated to the top of the codes, M100.0 will get set in the next scan cycle of the CPU (because , by this time the timer status of T10 will be already updated)
Does this makes sense? Plz comment bk.
Reagards
nashama wrote:Dear sventek,
My estimate was this (which may be wrong):Since the timers are updated every 10ms, the scan of CPU may not be able to set M100.0 immediately below the original codes. However, when the last 2 statements are relocated to the top of the codes, M100.0 will get set in the next scan cycle of the CPU (because , by this time the timer status of T10 will be already updated)
Reagards
I'm sorry, but you are wrong. It's simply so as I mentioned: Timer is running asynchronous to the program. At a time, time is elpased. When timer is elapsed before the first code line, all timer will be initialized -> M100.0 can't be set. In your short code snipped last line is more or less before first line, so there is not so much space where you can prove T10 successfully onto TRUE. But when you set the last two lines into first, M100.0 will always be set when timer is elapsed.
Thanks again dear Sventek.
In context of this thread , I found something in your explanation which I couldn't find even through "F1" of Simatic Manager. Thank u.
How about this?(hope you will respond with an equally interesting reply)
AN T5
L S5T#1s
SD T5
A T5
CU C5
Will C5 keep counting? or this situation will be similar to the last one as well?
Sorry for raising "basic" type questions ....... but I guess I will get to know something in the end from your experience and expertise !!
Regards
Will C5 keep counting? or this situation will be similar to the last one as well?
Sorry for raising "basic" type questions ....... but I guess I will get to know something in the end from your experience and expertise !!
nashama wrote:Thanks again dear Sventek.
In context of this thread , I found something in your explanation which I couldn't find even through "F1" of Simatic Manager. Thank u.
How about this?(hope you will respond with an equally interesting reply)
AN T5
L S5T#1s
SD T5
A T5
CU C5
Will C5 keep counting? or this situation will be similar to the last one as well?
Sorry for raising "basic" type questions ....... but I guess I will get to know something in the end from your experience and expertise !!
Regards
Hi nashama!
I could not test this on a real CPU, because I'm out of office this week. But anyway and without testing it is the same. Did you get another result? I think again, when you wait a longer period, the counter should count from time to time.
No poblems with the "basic type questions". It's always possible to learn something new, also for experts (and I'm realy not an expert )
You demonstrated another way of HOW to set M100.0 , while I was asking for the reason WHY M100.0 was not getting set in my original post.
Nevertheless, thank u for sharing the new idea to set M100.0.
Regards
Dear Trafo,
Thanks for the reply.
May I ask u few things?
1) Why can't you use " + I " instead of " +D " to increment MW1000 since it is a WORD, not a DOUBLE WORD.
2) Trafo : "The reason why I called SIEMENS folklore, so you get used to it."
Couldn't understand that ......... is it some kind of mystery or something mysterious with Siemens you mean? I'm not sure what does that mean. But thanks for your time and attention.
Regards
The reason is, that timers works asynchronous to the Step7 program. When you wait long enough, the Marker 100.0 will be set, depending when the timer will elapse (tested on a real CPU).
| When timer elapse here, first T11 will be set back and then also T10 -> M100.0 can't be set.
AN T10
L S5T#5S \
SD T11 __\
_________ \
A T11 ____| When timer elapse fortuitous here, -> M100.0 will be set.
L S5T#5S _|
SD T10 __/
_______/
A T10
S M100.0
| Also here -> when timer elapse here, first T11 will be set back and then also T10 -> M100.0 can't be set.
When you shift the last two statement on the top, M100.0 will always be set, when timer T10 elapses, because there is no condition before the two statements that could reset first T11 and with that T10.
I hope that help's you.
sventek[/quote]
This explaination is totaly right, but shifting the 2 statements on top only minimizes the chance to loose single settings of m100.0 ->
A T10__ \
S m100.0 |... if executing this AND timer ellapses..... (unlikely but possible)
AN T10_ /
....
the cure is:
A T11
L s5t#..
SE T10
AN T10
L s5t#..
SE T11
A T10
S M100.0
Anyway : i can not imagine any practical use of accumulating times this way
Dear pwkoller,
Thanks for suggesting another way to set M100.0 pwkoller : "Anyway : i can not imagine any practical use of accumulating times this way"
That's right. It is just for testing purpose only ....... Though it looks so simple to the naked eye , for the first time when you see the codes that M100.0 will get set easily in the original STL , however , it requires some "internal understanding" to know WHY M100.0 don't get set that easily !!
Regards
while maintaining large programs it is possible to get constructions like the m100 problem -
hidden the three parts of it somewhere in the whole program.
as we have seen, only one sequence of the three parts gives us a proper result
so what if a necessary program change forces us to alter the sequence of called programparts
-> we have done everything right, but it does not work.
the reason is : a signals state does not last at least ONE cycletime lenght
(similar are problems with inputs witch maintaine states shorter than cycletime)
so a general rule should be: make your signals at least one cycletime long ( to be seen from the whole program )
another point is : nobody pays you for the minimal amount of statements in your program
but only for 100% realyability and 100% functionality. And you will do yourself a favour if you have to
maintain the program.
for our example this means the following: ( the three parts could be called in ANY sequence and it will work )
-> part 1
UN M 1.1 // Signal timer 10 (consumed)
L S5T#500MS
SE T 11
U T 11
= M 1.0 // Signal timer 11 (provided)
-> part 2
U M 1.0 // Signal timer 11 (consumed)
L S5T#500MS
SE T 10
U T 10
= M 1.1 // Signal timer 10 (provided)
-> part 3
U M 1.1 // Signal timer 10 (consumed)
S M 100.0
Thanks pwkoller.
So my idea of time resolution (or time base of S5timer) versus scan cycle time of CPU is not the reason of the problem as Sventek clarified that timers run asynchronously to the user program.
Further to that , I take your advice to make sure the signal state is made to last more than atleast one scan cycle time.
Regards