False logic execution

[crl 0]

As shown in screenshoot below, I encounter a strange behaviour with logic execution. First of all I trought "DEM_DEGIVERAGE" is reset somewhere else in the program. But : "DEM_DEGIVRAGE" is a local variable of FB POU "_FRIGO. So I Consider It must/should not be written outside the POU. "DEM_DEGIVRAGE" reset condition, just below, is the only on. And this reset condition is not true. On the left I display network code and data visualisation. I submit this problem to my local country support but, up to now, they where not able to help me. The problem is not always present, but appear unexpectedly. As this program is running in production, I can not trust it and the situation is critical ! Dose somebody may have an explanation for that ? Dose somebody may help me ? Many thanks in advance CRL

[kaare_t 155]

First of all, the EntryDataMonitor image has an error; Position 3 should be M6784 and not M6874 as it shows so you should correct this first. Second; since you experience a variable being automatically resetted this is almost always caused by something in the program being overwritten.... You say that the variable is a local variable inside the specified POU, but have you used any hardware addresses inside the project anywhere? I see that you've used a SET instruction, do you have multiple reset points? Also; it's very hard to see in the picture if both the SET and the RST instruction of the specified variable is inside the same network. NEVER put the SET and RST inside the same network! Make two different networks!!! This is probably the problem if inside the same network.

[crl 0]

Thank you Kaare_t Set and reset condition are in two separate network. Else, "DEM_EGIVRAGE" is a VAR OUTPUT variable of the POU. This output is linked with a VAR INPUT for an other POU. The link is made by a local variable within uper level POU, where both POU are called. I am not sure, but I may have observed that address are identical between the "var output" and the upper level "local var" Could it be possible that complier do some optimisation? This may be in relation with options in menu EXTRA/OPTION/CODE GENERATION and "Use SET/RST for Boolean Outputs" and "unique temporary variable for an output". Where could I find detailed informations about these options ? Regards CRL

[BobLfoot 302]

I've not worked on a melsec plc in 15 years, but some basic concepts might garner you some help here. If you think something is resetting the variable elsewhere in the program, prove this beyond a shadow of a doubt by removing the one known reset from the program and see if the variable resets. This will prove emphatically if there is another reset at work or if your reset rung is behaving contrary to your understanding. If your reset rung is behaving contrary to your belief, and in my experience this is a good money bet. Then break the complex rung into simpler multiple reset rungs and determine which branch is the phantom culprit. I know I've not given you specifics, too rusty for that, but hope the basics notes above and your research can shed some light.

[kaare_t 155]

Just like The Wizard is saying, there must be one of the following: 1. The variable gets resetted somewhere (most likely) 2. The variable never gets set for some reason (unlikely) In addition to what he says, if the above fails, you can remove all other POU's in the Task-list so that only the respective POU is ran. When I refer to "Hardware addresses" I mean if you, anywhere in your program, has used direct addressing (e.g. M200 or M4500) instead of using names. If you have used any kind of direct addressing you must review these to.