'Temporary Flags' in Step 5

[PLucas]

In all our programs written with Step 5 (come to think of it, all our programs. Full Stop!)we use 'temporary flags', these are flags that are used many times within the program just to carry over a result from one network to the other.....Well, you all know what 'temp' flags are, so I won't go on.

Anyway, I had to do a modification to our programs, this mod was to protect certain areas from having the automated cranes drop containers on them.

I wrote the logic in an FB and within the FB I used temporary flags, here's a snippet from the FB.....

L DD70 //load DD70 from DB11 

L KG+3785000+05 //load constant 38570

>G //compare DD70 for greater than 38570

= TMPF1-0 //If compare is true set temporary flag 1.0

L KG+4050000+05 //Load constant 40500

L DD70 //load DD70 from DB11

>G //compare the constant for greater than DD70

= TMPF1-1 //if compare is true set temporary flag 1.1

 

A TMPF1-0

A TMPF1-1

= TMPF2-0

It continues in that vain until the end of the block when I set an output which is used in the main program.

I put the logic on a crane and tested it at it's target areas and it worked exactly as I had hoped, but.....

on very intermittant occasions the protection activates in an incorrect place, the place it occurs is not a set place and it doesn't happen everytime, the mod has been on the cranes for over a week now and we have probably had maybe 1 mis-trigger a day.

I was think along the lines that the temporary flags in use are not totally working as I expect them to, maybe they are 'retaining' their state from other parts of the program and not being written over by the logic in the Function Block.

Has anyone else had a problem similar to this?

Suggestions on how to overcome this would be fine, but I used temporary flags in the FB as I am very limited to the number of flags left available in the program.

If anybody wants it I can post the whole function block including the call to it from the main program.

Paul

 

[geniusintraining]

Paul,

I’m not going to pretend that I’m in the same class of programming that you are, but have you tried to set and reset the flags?, do you think that it’s dropping out every so often?

I have not seen that with any of my programs, what's the processor?

 

[PLucas]

what's the processor?

Christ! You've put me on the spot there....

S5 135 CPU928.. I think, it might sound stupid but I don't take much notice of the CPU

I was tempted to reset all the flags at the beginning of the FB once I noticed this problem occur, but I have never had to resort to this previously, although I must admit this is the first time I have used temp flags within an FB.

If anyone does confirm a 'problem' with the behavour of temporary flags in Step 5, then I will have to set aside an area within DB11 and use the DB bits as flags with the FB, that is one option open to me, the other is to 'ignore' the problem as it is very intermittant and doesn't really cause a loss of production as the crane seems to 'ignore' it and carry one, so I can only assume that this problem occurs for one scan only, but that one scan is enough for the PLC to send back a message via our RDT messaging system to the control room. This is how I actually found out about the fault, by looking through the messaging archive.

Paul

 

[krk]

Paul,

It's a common technique in S5, just make sure any flags you use for your 'logic carry' aren't used in any cyclic interrupt OB's...

Kev

 

[rdrast]

Are the temporary flags like the 'L' memory in S7? I don't recall much of my S5 days..., but I do use the 'L' memory often in S7, but I need to be very careful.

If they are the same, then they can be overwritten anytime a larger stack variable exceeds it's bounds.

When I'm working on programs where I don't need (or more, want) to be so careful, I declare a couple global flag bits, designated for that particular FB/FC (Siemens) or Task/Program (AB & others) that I know absolutely will be invulnerable to external routines or internal, unexpected, conflicts.

Most of my programs are liberally sprinkled with "OB1_Dummy_Bit", "OB1_Dummy_Int", "OB1_Dummy_Real" for example, and I use those for my temporaries.

 

[S7Guy]

Paul, is it possible that an interrupt is being called that is using those temp flags? Don't hold me to this, because I haven't touched an S5 for a few years, but I seem to remember that interrupts will not wait for the end of a function before jumping. That is why interrupt functions will typically store the current status to the temp flags it wants to use, execute its code, and then restore the temp flags upon exiting.

It must be something like that, because no variable just changes for no reason.

 

[PLucas]

Thanks for the replies so far, it seems that S7Guy and Kevin (KRK) are saying much the same thing, I will probably have to look into this on Monday when I get back to work.

I did state earlier that the place this occurs is not a set place, but I have noticed a bit of a pattern to the ocurrance, this only seems to happen when DD70 contains one of 4 numbers, it could be any one of the four, I have looked at the messaging for all the cranes involved, then noticed this pattern.

I will have to post the whole FB for you to look at, then you can see that I am setting 'windows' dependant on the container size (20ft or 40ft), if the figure in DD70 falls within one of the windows then the 'protection' is activated. The values in DD70 when the activation is incorrect are well outside the windows and for the life of me I couldn't work out why.

I can't even think of any interupt OB's that could be called in relation to these figures....

I think that I should state that we have set aside FB1 (Flag Byte in this case) to FB7 as temporary flags, in S7 speak that would be MB1 to MB7, we do only write to these as bits and not as bytes or words.

Paul

 

[SimonGoldsworthy]

Just a couple of suggestions:



1. Use brackets to eliminate the need for temp flags


A(
L DD0
L DD70
>G
)
A(
L DD20
L DD80
>G
)
...
...
= Ouput

2. The 928B has an area called S flags (which tend not to get used very often). You could replace your F bits with S bits in this block.

3. Extend the DB (if possible) and use the new data bits for temp bits

4. If using interrupts (OB10, OB11 for example) save the F bits at the start of the interrupt and restore them at the end of the interrupt. Use a new DB for the purpose.

 

[PLucas]

Simon

Thanks for the suggestions,

Suggestion 1..

I never thought of doing it that way, I have to admit that I have always done it the way in my example, so I tend to stick with what I know. I will look into that.

Suggestion 2...

S flags are out, they are extensively used in our programs, plus I am not sure how many are available for this CPU, nor what ones are not used in the program.

Suggestion 3...

I mentioned that I might do that in one of my previous replies.

Suggestion 4....

I am not sure what interupt OB's are used in the program and when, I will look into that and see if any are called and if they are using the same flags that I am using.

Although I do quite a bit of S5 work, I still don't like it, it tends to catch me out on a few things. But that is what I am paid to do, so I best get on with it.

On Monday I will post the FB complete and also post the details of the 4 values that seem to be causing the problem, then maybe we can sort this out once and for all.

I can just change things to see what is causing the problem, but I would much rather have a definitive answer to this, if that's possible, if not I will just change the Flags to DB bits and see what happens.

Paul

 

[S7Guy]

Paul, what are the actual addresses of the temp flags you are using? I know that many programmers used the 220-255 area for their scratch data. You could try using different addresses, and see if the problem goes away.

 

[PeterW]

I was going to say similar to S7guy. If any interupts are using standard siemens FB's, they tend to use flags FB200 and above as their scratch flags, if I remember right the FB doc's used to mention memory area used by the blocks.

We used to use these flags as our scratch flags in our blocks, but the rule was condition it before use and use it straight away, don't pass it to other blocks because the interupts would generally occur at the end of the current block when it was instigated.

 

[PLucas]

Right it's now Monday (alright Monday evening), I did say that I would post the complete function block today, so here it is...

 

Name ROTECT

Decl :IN20 I/Q/D/B/T/C: I BI/BY/W/D: BI

Decl :IN40 I/Q/D/B/T/C: I BI/BY/W/D: BI

Decl :REEF I/Q/D/B/T/C: Q BI/BY/W/D: BI

Decl B I/Q/D/B/T/C: B

 

     O =DB

     :A =IN20

     :JC =M001

     :A =IN40

     :JC =M002

     :JU =M003

     :

M001 :L DD70

     :L KG +3857000+05

     :>G

     := -TMPF1-0

     :L KG +3982000+05

     :L DD70

     :>G

     := -TMPF1-1

     :A -TMPF1-0

     :A -TMPF1-1

     := -TMPF2-0

     :L DD70

     :L KG +4050000+05

     :>G

     := -TMPF1-2

     :L KG +4162000+05

     :L DD70

     :>G

     := -TMPF1-3

     :A -TMPF1-2

     :A -TMPF1-3

     := -TMPF2-1

     :

M002 :L DD70

     :L KG +3857000+05

     :>G

     := -TMPF1-0

     :L KG +4014000+05

     :L DD70

     :>G

     := -TMPF1-1

     :A -TMPF1-0

     :A -TMPF1-1

     := -TMPF2-0

     :L DD70

     :L KG +4050000+05

     :>G

     := -TMPF1-2

     :L KG +4162000+05

     :L DD70

     :>G

     := -TMPF1-3

     :A -TMPF1-2

     :A -TMPF1-3

     := -TMPF2-1

     :

M003 :O -TMPF2-0

     :O -TMPF2-1

     := =REEF

 

The flags -TMPF1-0 to TMPF1-3 are F1.0 to F1.3 and -TMPF2-0 to TMPF2-1 are F2.0 and F2.1, these are used extensively in the program.

Anyway, today, as an experiment, I replaced all the -TMPF's with spare flags that I found not used in the IQF listing, so far the problem has dissapeared! I wasn't surprised by this, as I suspected all along that these were causing the problem, i just couldn't understand why they were not being over written by the controlling logic in this FB, I have not noticed this when using the TMPF's in PB's.

Paul

P.S Phil or anyone... why did I have to keep resetting the text between the 'ladder' tags after every preview post?

 

[PeterW]

One thing I've noticed, in the beginning of the block, if the first two inputs are not in the right condition, it jumps to M003, at this point your temp flags used to condition REEF could be in any state.

Also it has no jump to M003 after M001 code, so it always runs M002 code and changes the temp flags.

 

[PeterW]

As someone mentioned earlier, it can be achieved without temp flags.

Name ROTECT

Decl :IN20 I/Q/D/B/T/C: I BI/BY/W/D: BI
Decl :IN40 I/Q/D/B/T/C: I BI/BY/W/D: BI
Decl :REEF I/Q/D/B/T/C: Q BI/BY/W/D: BI
Decl : DB I/Q/D/B/T/C: B

: DO =DB
:A =IN20
:JC =M001
:A =IN40
:JC =M002
:BEU çChange to Block end if you there's nothing to be done. Or to place code before the BEU to turn on or off REEF if you want.
:
M001 :A(
:L DD70
:L KG +3857000+05
:>G
: )
:A(
:L KG +3982000+05
:L DD70
:>G
: )
:O
:A(
:L DD70
:L KG +4050000+05
:>G
: )
:A( :L KG +4162000+05
:L DD70
:>G
: )
:= =REEF
:BEU ç Set the flag then block end
:
M002 :A(
:L KG +3857000+05 :L KG +3857000+05
:>G
: )
:A(
:L KG +4014000+05
:L DD70
:>G
: )
:O
:A(
:L DD70
:L KG +4050000+05
:>G
: )
:A(

:L KG +4162000+05
:L DD70
:>G
: )
:= =REEF
:BE


Havent checked it properly, but think its the same, just depends on what you want REEF to do if the IN's are not on, keep it the same or turn it off.

 

[PLucas]

One thing I've noticed, in the beginning of the block, if the first two inputs are not in the right condition, it jumps to M003, at this point your temp flags used to condition REEF could be in any state.

Also it has no jump to M003 after M001 code, so it always runs M002 code and changes the temp flags.

I will deal with your last point first....

That's just a typo on my part, at the end of both M001 and M002 there is a JU =M003.

Your first point is a good one, that is where I suspect the problem lies! I obviously couldn't see the wood for the trees when I was looking into this problem, still that's what this forum is for!

Having said that, I couldn't understand why =REEF was only falsely triggered when DD70 contained one of 4 numbers, 38490, 37530, 36250 and 35290, there are at least 50 other 'targets' that DD70 could contain, yet the problem does not appear when DD70 contains one of these, then it is not everytime it contains one of the 4 numbers I quoted. Still, I tend to think that you are right though, it has probably got something to do with the state of -TMPF2-0 and -TMPF2-1 when the block is called and neither of the inputs are true (=IN20 and =IN40)

Paul