The “L4.0” is a memory bit location / address. It points to the temporary (TEMP) variables. It is a point of failure. As variables / tags are added, that address space is occupied. Then changing L4.0 also influence the newly created variable.

Best to replace that with a proper symbol variable. Create a bit in the TEMP area like tempBit. Then replace the L4.0 with that tempBit variable.

Helpful?

Local data is predefined and available just like memory bits. It is a physical entity and not software defined. For example - Just because M100.0 is not assigned to a symbol does not mean that M100.0 is not there. Same for C / T / I / Q / .. and such physical predefined memory.

This is also the risk of using Lx.y style (pattern) of direct addressing. You could add LWx which overlaps and there would be no warning of this issue. The same applies to any direct addressing (knowingly or unknowingly) employed

Possible origin of the issue .. When a designer uses LAD programming and the code is converted to STL, this kind of behaviour is seen: Lx.y is put in place to carry over bit results. The software compensates when variables are added in the TEMP declaration if the LAD view is kept. But if the view changes to STL, the software does not track the temporary direct addressed bits (Lx.y). You have to compensate for this problem by yourself, by changing the Lx.y to some defined named (symbol) variable.