vipa plc got crasy !

tny · Jan 31, 2007

hi,
on a working system, i only set a marker bit according to some conditions and i "never" reset it again. the bit isn't used in any where else, the only row in the reference table about the marker is my set commands row. but a copule of seconds, it resets its self!! the marker bit is not a clock memory bit. finally i changed it with an other marker bit, and the problem solved.

have you ever seen any anomalies like this?

JesperMP · Jan 31, 2007

Hello tny.

Try to select the merker bit in STEP7 and then select "go to".
In the dialog box, have "display overlapping adresses" turned on.
Maybe that will turn something up.
In particular for Merker addresses it is possible to accidently address variables that overlap.

tny · Jan 31, 2007

hi jesper!
i tried it but unfortunately i couldn't see it anywhere.
i think you meant any byte,word etc acces to the marker bit,
but there isn't such access.

one day,with an s7 200 plc, after reseting the plc and clearing all the program, i only wrote:

ld i0.0
s q0.0

no other subroutines or interrupts!

then, when i activate the input for approx min. 0,5 second,
q0.0 sets, but if i just give a pulse to the input, q0.0 just activates momentaryly.

so i had to latch it.

no one could explain it.
it is like twilight zone story!!
may be this is somethink like that

L D[AR2P#0.0] · Jan 31, 2007

tny said:
hi,
on a working system, i only set a marker bit according to some conditions and i "never" reset it again.

Why have you put never in quotes ?

tny said:
have you ever seen any anomalies like this?

Lots of times -
coding errors in indirect addressing
HMI's writing data
Host PC's writing data

If you don't understand or can't explain why something is happening, then you can never be sure what your "fix" is really doing.

tny · Jan 31, 2007

i just wanted to emphazise that i didn't reset the bit in any where.
the bit was m11.0 and the only commands for it was:

a i23.0
a i23.1
fp m11.1
a m11.1
s m11.0

there is no reset instruction for m11.1 and there is no byte access to mb11. there is no hmi in the system.
but the other s7 200 problem is more interesting i think.

PeterW · Jan 31, 2007

no byte access, what about word or double word?

what address did you change to?

tny · Jan 31, 2007

yes, no byte, word or dw or bit access. the bit m11.0 seems availbe. i changed it with an other available bit m14.7. now it's working. here is the real program.

in the fc104 from the nw14 i set the bit m14.7. and than reset it. it's a simple code so it works. but when i write m11.0 instead of m11.4, it resets. i deleted the reseting commands when i was trying with m11.0, but it was reseted again.

PeterW · Jan 31, 2007

I cannot see anything where MB11 bits reset. Your clock memory is MB200, so not that.

I did notice a mistake in FC1 though, in Network 3 you are using the OUT bit #motor to run #timer_1, you don't condition #motor until Network 4, therefore at Network 3, the bit state is undeterminable.

You either need to change #motor to an IN_OUT or move it to after you condition it, i.e. switch Networks 3 and 4.

As far as M 11.0 is concerned, I'd set it at the very start of OB1, then use it to SET other flags at various points in the program i.e. bits in MW600 or something, then monitor the bits in a VAT table, keep resetting MW600 once set, see if its switching at the same place or at various places. If its the same place then look at the code between that and the previous bit, if its not the same then its likely something external or some diagnostic setting etc...

tny · Jan 31, 2007

PeterW said:
I did notice a mistake in FC1 though, in Network 3 you are using the OUT bit #motor to run #timer_1, you don't condition #motor until Network 4, therefore at Network 3, the bit state is undeterminable.

is it undeterminable or the state which is determined at last cycle? i think the second one is true.

PeterW · Jan 31, 2007

tny said:
is it undeterminable or the state which is determined at last cycle? i think the second one is true.

No, the first is correct, undeterminable.

The OUT parameter is assigned to a temp flag for the duration of the FC call, the output is only updated from that temp flag on leaving the FC, it is not updated with its last state on entry.

Similar for IN parameters, you cannot set them in the FC.

tny · Jan 31, 2007

PeterW said:
No, the first is correct, undeterminable.

The OUT parameter is assigned to a temp flag for the duration of the FC call, the output is only updated from that temp flag on leaving the FC, it is not updated with its last state on entry.

ok, but it is not a new system, the functions was written min 2 or 3 years ago and its working. doesn't the functions read all of its parameters when starting to run then write real i/os when exiting? if so it will read the status of the motor output activated from the last cycle.so if the motor is runing when the fc starts to run, it will read the status of real output as 1 and until network4, #motor variable (so and the s input of the timer) will be 1.

PeterW · Jan 31, 2007

tny said:
ok, but it is not a new system, the functions was written min 2 or 3 years ago and its working.

Luck more than judgement I'd say.

tny said:
doesn't the functions read all of its parameters when starting to run then write real i/os when exiting?

In a nutshell, No.

tny said:
if so it will read the status of the motor output activated from the last cycle.so if the motor is runing when the fc starts to run, it will read the status of real output as 1 and until network4, #motor variable (so and the s input of the timer) will be 1.

Again, No.

The only way its working is as I say luck. Are you sure its working correctly or for the most appears that way? Maybe the programs so small each call is using its own area of temp storage with no overlapping, but I assure you it does not intentionally remember. I'd change it to make sure.

On Entry (or just before as was explained by someone earlier this week), INs and IN_OUTs are read from the data entered at the FC call.

On exit, IN_OUTs and OUTs are updated from the status of thier temp memory storage.

An FB is different, as they are stored in an instance DB, the only parameters not stored are the declared TEMP flags.

tny · Jan 31, 2007

so you mean that if the operands were real i/o s, or #motor was defined as IN_OUT there shouldn't be any problem about the sequence of nw 3 and 4.right?

PeterW · Jan 31, 2007

Doesn't have to be real i/o, for instance FC1 is called 40 times, had you repeated the code 40 times instead of creating an FC and the operand was a unique adressed operand each time for that timer, that wasn't switched elsewhere, then yes it would works.

In the FC, if the operand was assigned as an IN_OUT, it would work.

If it was an FB it would work.

It is purely the fact the fact that it is an OUT parameter of an FC call that it doesn't. The OUT parameters in an FC should be treated the same as any TEMP parameters, that is the state is not trustable until it is conditioned. Once conditioned it can be used for other things.

Whoever programmed the PLC doesn'tlike symbols and comments does he..

PeterW · Jan 31, 2007

It would be easier to exchange networks 3 and 4, because if you change the parameter to an IN_OUT, you would have to re-compile every blockl call and it may change the order of things.

vipa plc got crasy !

tny

Member

JesperMP

Lifetime Supporting Member + Moderator

tny

Member

L D[AR2P#0.0]

Lifetime Supporting Member

tny

Member

PeterW

Member

tny

Member

PeterW

Member

tny

Member

PeterW

Member

tny

Member

PeterW

Member

tny

Member

PeterW

Member

PeterW

Member

Similar Topics