RMA
Member
I've mentioned this problem in passing a few times, but nobody ever took up on it and I initially just wrote it off as another of those Siemens curiosities. Now I'm not so sure, I've discovered that I get different results from my program depending on whether or not I let it run straight through (it's a data transfer which only executes once per experimental run) or whether I follow the program through using Breakpoints. I also get different (read better!) results if I set Breakpoints every few commands and definitely check each Jump command, than if I set the Breakpoints to allow bigger chunks of the program, in particular including calls to subsidiary Blocks to run.
I've always assumed the following:
Once a Block starts executing that (neglecting Interrupts) it runs to completion unless there are BE commands in the Block.
If there are BEs, whether conditional or absolute, in the execution path, the Block stops executing at that point and restarts from the beginning in the next cycle.
If the Block calls a subsidiary Block (as a Subroutine), then execution transfers to the called Block which then executes to its end before returning program control back to the calling Block at the command following the CALL command.
I also assumed that if the called Block terminates with a BE command that program execution also returns to the calling Block at the command after the CALL command - but now I'm wondering if this is actually the case.
In the following Screendump of the calling program, FC9, I've set a Breakpoint immediately after the CALL to FC20 - I have never managed to hit this breakpoint - ever!
In the second Screendump of FC20, the program has stopped on the Breakpoint at the entry point. However, this is the second time through. Having followed the program step for step down to setting the New_Data Flag in NW4, before exiting via a BEA in NW5, I then reset the Breakpoint up to the top to catch it following the next call to check whether the data transfer was OK or not. However, on restarting the program with the "Move to next Breakpoint" Button, instead of trapping at the SET command in FC9, the program re-entered FC20.
So either something very strange is going on here, or my understanding of how Step7 programs execute is seriously flawed!
I've actually solved my problem as such (an old version of the Block had somehow got mixed into the current version of the program), but I'm a bit bothered, that I don't know what's happening here!
I've always assumed the following:
Once a Block starts executing that (neglecting Interrupts) it runs to completion unless there are BE commands in the Block.
If there are BEs, whether conditional or absolute, in the execution path, the Block stops executing at that point and restarts from the beginning in the next cycle.
If the Block calls a subsidiary Block (as a Subroutine), then execution transfers to the called Block which then executes to its end before returning program control back to the calling Block at the command following the CALL command.
I also assumed that if the called Block terminates with a BE command that program execution also returns to the calling Block at the command after the CALL command - but now I'm wondering if this is actually the case.
In the following Screendump of the calling program, FC9, I've set a Breakpoint immediately after the CALL to FC20 - I have never managed to hit this breakpoint - ever!
In the second Screendump of FC20, the program has stopped on the Breakpoint at the entry point. However, this is the second time through. Having followed the program step for step down to setting the New_Data Flag in NW4, before exiting via a BEA in NW5, I then reset the Breakpoint up to the top to catch it following the next call to check whether the data transfer was OK or not. However, on restarting the program with the "Move to next Breakpoint" Button, instead of trapping at the SET command in FC9, the program re-entered FC20.
So either something very strange is going on here, or my understanding of how Step7 programs execute is seriously flawed!
I've actually solved my problem as such (an old version of the Block had somehow got mixed into the current version of the program), but I'm a bit bothered, that I don't know what's happening here!