Siemens S7-300 function call problem

Hi all,
Please bear with me on this one as I try to explain my problem.

I am only a beginner with Siemens so please be gentle.

This morning we had a problem with none of our analogue inputs being processed.

I traced the problem to OB1 where the inputs are called, the problem being that the FC for the analogue inputs was anded with the FC for the Digital inputs. The ENO for digital inputs FC was not 1 therefor the analogue inputs FC was not being processed.

To get the system back up and running I created a new network and called the analogue inputs FC and all was well.

What would be a possible cause of this as there seems to be no other problems with the system.

hope you can shed some light on this.

regards

Hello gunner;

Please clarify your description of the problem. Do you eman to say OB1 programm changed by itself, that existing networks disapeared without programmer's intervention?
What CPu are you using (what part no., if you are not sure of details), does it have a (required) MMC slotted in? Or is it a battery-supported memory?
Of course a block will not be processed if it is not called in sn OB or an FC/FB. It actually shows that as an error message in the LAD/FBD/STL editor when you try to monitor the block "Block is not called".
Can you give us a screenshot of the problem networks?
Hope this helps,
Daniel Chartier

Gunner - the ENO output (called the block result) from a block can be true or false depending on the logic within the block. If you have block calls cascading after each other, then if any of the block results are false, the following blocks will not be called. This can be done by design whereby you don't want to process certain blocks if the previous block result is false, or by accident in which case you may get unpreditable results.

Please have a look at this related thread:-

http://www.plctalk.net/qanda/showthread.php?t=30744&highlight=block+result

I'll say that the original programmer probably just thought that it is a more compact way to display the code.
So I think you can simply change the FC calls from being connected in serial to parallel.
If you want to be sure, you have to look inside the preceeding blocks to see if there can be an intentional relation between the blocks that are connected in series.

There is no relation between the blocks, the first loads the Binary input words and transfers them to a data block. The second loads the analogue input words and transfers them to a data block.

If the first block was not processing correctly wouldn't it be reasonable to expect that the machine wouldn't operate correctly as some inputs would not be processed?.

Once the FC's where put in parralell the program worked as normal.(But the first FC still doesn't execute and set the ENO bit.)

I even looked at a backup program and the code is exactly the same in fact the Binary outputs and analogue outputs are programed in the same manner and are processed with no errors.

The machine is up and running but I would still like to find out why this has happened. Siemens support here has never heard of this.

Hope you guys may know something

regards

If the machine works in a way that everything is functionally interconnected, then it would not be so strange to put the analog block after the digital input block. I would not do like that myself, but there is nothing wrong with it in priciple.
My own programs consists more of many parallel processes.

To find out why the ENO output is not set, you should go online and investigate the logics.
You can also post the code from the block here (or the entire archived project). But in cases like this online debugging is the way to go.

Gunner said:

But the first FC still doesn't execute and set the ENO bit.)

Click to expand...

Have you read the related thread ? - just because the block is not highlighted does not mean it is not executing !

At first sight yes - but was the guy preventing the call of the analogue blocks if the EN0 of the digital blocks wasn't good ? It does seem a bit odd to do so , particularly with no comment . Perhaps as you say , he was trying to save space , but didn't realise that the EN0 could actually be false - why has this changed suddenly ? is there a probalem internal to the block , or did he just forget - CLR SET SAVE ?