Discussion on the FAQ 67519310

Hello,

this FAQ describe the rules of jump labels in logic operation sequences and jumps from Boolean logic operation sequences or to logic operation sequences is not permitted. Otherwise it is possible in dependent of the complete control that the CPU goes in STOP. The FAQ describe also the advantages in refer to this rule.

With best regards
Cicero

Is this FAQ solution a real solution?

If the desscribed behavior indeed occurs (CPU can go tostop) then this looks like a firmware bug.

After a jump the RLO shouldalways be SET automatically; an extra SET instruction is not required (Step 7 classic) I've been programming Siemens Step7 since it has been released and rely on this behaviour since.

I have seen people making mistakes with RLO logic and then they start using a SET-initiator to 'solve' strange behavior, which isoften caused by 'commenting' an earlier jump or '=' statement.

Some old S7-300 PLC's had an issue with RLO behaviour because initiation of RLO was determined during compile time which could lead to faults... in situations where the compiler can't predict the RLO (or other bin-flag?) at compile time.

In my opinion the CPU should never go toSTOP because of a possiblemistake (unless you make a loop of course).

Can you post some example code which causes the described faults ?

best regards,

Remark

Hello,

in STEP 7 V5.x it was possible to define the jump destination in a logic operation sequence. In most of applications there are no problems. But unexpected results might occur during program processing. In some cases the CPU goes into the STOP mode. The STOP mode of the CPUis better as when the facility runs in an out-of-control process.

This is the reason that in STEP 7 (TIA Portal) V12 jumps from boolean logic operation sequences or to logic operation sequences are not permitted. In this case you will receive a compilation error, if you not use the SET instruction. The SET instruction ensures a define beginning of the new "logical unit".

With best regards
Cicero

Hi Cicero,

I was wrong about the RLO flag, this has probably something to do with the /FC-flag instead of the RLO. The CPU does not set the RLO flag because of a jump instruction. It detects a new logic string which causes a init of the RLO before processing the new logics. The S7-300 does this apparently by looking at the previous code lines (line directly above new logic which might not have been executed-> error behaviour) while it should look at the last processed instruction (the jump)

The S7-400 CPU's and the simulator did not have this strange behavior... according to tests the 300 CPU's determine the init the /FC flag requirementsat compile time.

This TIA issue seems like the same sort of problem...

I think it would be nice if the compiler checks for possible programmingerrors like in this example:
Although it would be better if the software could handle this... it's probably caused by a limitation of the 300-CPU's. I hope/expect the TIA cpu's can handle this as expected since they are state of the art (modern)

A M1.0
AN M1.1
JC n_ok

A M2.0 // <-- this can cause error behaviour in a 300-cpu since
n_ok: AN M2.1 // when a jump is made to n_ok
= M10.6

The nextcodeshould be okfor a S7 300 (-> Is this OK for TIA ?)

A M1.0
AN M1.1
JC n_ok

A M1.0
SM10.0

n_ok: AN M2.1
= M10.6

A separate SET instruction should not be required... if this is still required then it seems Siemens has used the old S7 300 mnemonic handling instead of the better S7 400 behaviour.

I am now very curious howTIA V12 handles this andwill test it with aS7-1500 later this week...

I guess you agree that it would be very silly if TIA programmers would have to add a SET instruction after each jump because the new CPU's can't handle this (if this is the case it should be fixed at the source of the problem)

best regards,

Remark