TIA Portal V16 Upd 3;
CPU S7-1214C Fw: 4.4

Hi all,
in this following code, at the line 284 I had to remove the statment ELSE, due of a compiler error: the line 285 was performed even if the IF condition was TRUE. The monitoring screen was showing the line gray, as unprocessed, but in fact the CPU continuing to execute it in all cases.

[snip]

Kal.A

Not possible; it will be human error. And thus is way too much code for on function, break it up so that you can follow the logic and identify bugs.

I do not think the code is too much or too complicated for the code block to handle it.

Earlier today I have made an inspection of the code presented by the TS. I see no human error (which does not exclude my own human error). If this would happen to me, I would include an empty (case) ELSE in the CASE-statement that precedes the problem line.

I just wish the TS could have shared his code as an export SCL text file.

~

I don't think it is too much, I think it is way too much. I didn't look at the code and unlikely to.

But I am interested in the proposition that the code on the else clause could be executed in error, is that what you are saying, you believe that is possible? Is there precedence for this?

Kal.A

But I am interested in the proposition that the code on the else clause could be executed in error, is that what you are saying, you believe that is possible? Is there precedence for this?

Kal.A, I cannot recall seeing an ELSE not working.

We do not know how the TS knows that the ELSE was not executing properly. An effective way to debug the code would be to add debug counters.

IF (...) THEN
   ...
   "DebugCounter1" += 1;
ELSE
   "DebugCounter2" += 1;
   ...
END_IF;

Even after this investigation the question is if the condition in the  IF-statement is at the value that one expects it to be. A memory location written asynchronously from an HMI, communication partner or interrupt can cause confusion. These are much more likely than the ELSE not working.

Best health and sanity.

unknown user

I cannot recall seeing an ELSE not working. It may be helpful to know which software and hardware the TS uses

From my first post:
TIA Portal V16 Upd 3
PLC 1214C Fw: 4.4

unknown user

We do not know how the TS knows that the ELSE was not executing properly

This problem coming out after some adjustments of the code during the machine tuning. The preceding code was working correctly as the process needs. Due of these corrections, the variable named xAutoFwd never went to TRUE again in any conditions. I running a lot of debug test before to think that the problem can came from the compiler. Only after I checked, one by one each row where the variable is set to FALSE, I found the commenting this line, the function start to run again as wanted:

284 ELSE
285  //xAutoFwd := FALSE;
286  ;
287 END_IF;

Hello Mario.

I have checked your code in Step7 V15 and V17.
I do not have V16.
I cannot find any human problem. (see picture for offline code)

Try one thing for me please:
* Make the code as you want it to be. (as the above picture)
* Export the SCL source.
* Delete the FB and DB in your code.
* Import the SCL code and restore FB and DB as before.

A last question: Is your code using a DB or is it an instance of another FB?

We will have to see if there is any other user that experienced this type of problem. We have had some strange happenings on LAD code where a code network was skipped. I cannot help but wonder if it is related.

Ultimately only Siemens Support can help resolve this problem. For that you have to register a free service request. I assume you are Italian, so you should get a quick response (on Monday). Use the link: https://support.industry.siemens.com/tf/ww/en/header/supportrequest/

I wish I could help you more.
Please keep us informed.
Good luck.

qwazee

Try one thing for me please:

* Make the code as you want it to be. (as the above picture)
* Export the SCL source.
* Delete the FB and DB in your code.
* Import the SCL code and restore FB and DB as before.

No, now the machine is running and I don't waste my time for any more test, even because the customer don't stop it's work for play this game.

Siemens support? Uhmm, generally happen that I tell them how to solve the problem. As you say, the problem could be caused by some demaged block and, deleting them at all e recompiling all, can solve the problem, but this will be a case study for the future, with other process, others TIA Portal release, other problems. As we know fron long time, working with TIA Portal it's an nightmare.