S7 Program execution

RMA

Member
Join Date
Sep 2004
Location
North of Hamburg, Germany
Posts
2,052
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!

FC9.JPG


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.

FC20.JPG


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!
 
Roy, I don't use breakpoints, so I'm not sure if there is something in the Siemens breakpoint functions that could be causing strange symptoms.

Could you try something else? Insert an int variable in various parts of the program, and see how ofetn they are scanned. For instance:

L MW80
+ 1
T MW80

Then, look at it with a vat table under normal running conditions and see what's going on. I would put these in all of the places you would normally insert breakpoints.
 
@S7Guy, the problem is that this is the communication link with the FM352-5, which of course is completely self-sufficient and uses only local memory, having no access to CPU memory, so I can't do things like that there. Nothing stopping me from doing it at the other end though, so I'll give it a try.

However, the main point is that I'd like to discover what's going on here - I don't like having things happen that I don't understand! And on top of that, I like working with Breakpoints, I'm somehow fairly comfortable with them, when they work properly, that is! Maybe it's because I'm a bit slow on the uptake and with Breakpoints, I have all the time in the world to examine all the available information. :)

@Simon, no I haven't tried that, but it's no problem to do, so I'll try it out later on today.
 
Now that just ain't nice!

Well I've been off playing and tried out both suggestions.

Putting a single Breakpoint at the SET command as shown above worked, it got hit as expected. So then I added a couple of lines underneath the "S Transfer Started Bit" command and sure enough, it counted up every time I ran the program.

So then I pu Breakpoints in FC9 and in FC20, as I initially did, with exactly the same results - FC20 was immediately re-entered a second time without the Breakpoint in FC9 trapping BUT the counter had counted up 1!

So it looks like you can't rely on the Breakpoints - not nice at all!
 

Similar Topics

Hello gentlemen, If I have more than one Program POU assigned to the same PlcTask, how do I changed the priority of which program executes...
Replies
9
Views
3,374
hi all, under the continuous task, i have 3 programs. the first one copy a value from HMI linked tag to a tag called new_val, the third program...
Replies
1
Views
1,564
I am new to Red Lion HMI's and their Crimson 3.0 Software. I have a program that I know will run properly but I am unable to figure out how to get...
Replies
6
Views
4,610
Hi All, i would like know how to set the internal device to interrupt execution
Replies
5
Views
1,724
Isn't there a button that should be placed somewhere in a display to stop the execution of the program? I can't think of what it's even called...
Replies
9
Views
2,141
Back
Top Bottom