Strange S7 Memory bit problems

Hi Guys, good day to you all.

I have a strange problem occuring with one of the machine programmes we have, The CPU is a S7-300 series. We are selecting a (M) bit through a compare function in FC2 from a HMI, I.E, Compare MW180= 0 then coil output M2.0 is on, Everything works fine from the screen selection process, we test several varients of a pedal and select these through the same compare commands looking at different bit values.

The problem I have is, When we select the version controlling the M2.0 bit on the HMI, all the relating bit,s are made in the programme, these appear 16x throughout various FC,s and work fine apart from in 1 FC, where M2.0 stays on constantly !If we change varient all the other associated bits work fine, including those in the 1 FC that has the problem bit in it, these all switch with the screen selection as they should but M2.0 stays on although it,s off in all the other FC,s including the Compare output coil.

I,ve scratched my head to the point where I,ve now got an even bigger bald spot appearing. Does anybody have any idea why this one bit is staying on all the time in the 1 FC only but goes off in all the other FC,S ?

Regards

John

Is M2.0 being driven by coils or SET/RESET instructions ?

Please post some screen shots showing what is going on.

Hi LD,

It,s being driven by a coil activated by a compare instruction, the bit in question appears 16x throughout the programme, The coil and 15 of the other bits work as they should throughout various FC,s, it,s only the 1 bit in a seperate FC that does,nt.

For the time being and to get around the problem what I have done is branch another coil off the Compare function naming and creating a new bit, The offending bit in the FC that is not working has been replaced with this new bit and works fine !!!

I,m starting to think that the amount of bits you can use throughout various FC,s is restricted to 16 or something from 1 coil, anything over 16 does,nt work !

John

Could you post screen shots of the code or maybe post the code for that specific bit?

Screen shots added, like I say the bit works fine throughout the rest of the programme, the coil turns on and off like it should etc. The offending bit is M2.0, I,ve branched off the compare and created M2.4

In the FC with the problem I have replaced M2.0 with M2.4, and this works fine! another thing to add is, it does,nt matter what state the coil is in, the M2.0 bit remains ON all the time, but only in this 1 FC...


John

Could you post the source code for that specific FC ?.
I'm just wondering what it could be, maybe the full code ?

How many coils are there with M2.0 on them (after your fix has been implemented) ?

There,s only 1 coil in the whole programme, and everything after that is a Bit throughout several FC,s. All the other bit,s work correctly apart from this one !

I was thinking what you may be LD, is there another coil in the programme keeping this bit active or on all the time, there is,nt and if there was would,nt this coil keep all the other bit,s addressed the same on to ?

John

Sorry if you say there is only 1 coil, readed it wrong
If there would be more coils then the last coil before the bit controls the bit after that coil, that is how i know it

Re-stating your problem:

M2.0 is false in the FC where the M2.0 coil is processed.

M2.0 is true in another FC

Ok, Not sure how, but after redownloading the entire programme to the plc, the bit with the problem has started working as it should ! the programme being worked on was an uploaded copy from the plc itself with the same time stamps etc. the only thing done to it was to add the comments and symbols to it !

Got me baffeled for sure.

LD, Thim.... Thankyou for your support

John

Although it's not obvious from the screenshots, the symptoms sound very much like it might be one of our old classics, uninitialised Temps, or passing compound parameters to an FC. (I had the latter problem a couple of weeks back in a supplier program which was using "well proven standard FBs and FCs". Unfortunately, the program had been originally written and tested using Merkers and in the current implementation modified to use only DBs. The result was exactly as described above - in one FC the result of a scaled analogue input (stored in a DB) was correct in one Network and incorrect a few Networks later.)

That would also explain why the symtoms change/disappear after downloading the program again.