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.

was it written in LAD then modified?

Sometimes STEP fails to update L x.y addresses internally used by LAD program.

in such case (when network which used to be displayed as LAD shows as STL)

change all Lx,y to an empty addresses paying attention to bits, for example

change L4.0 to L104.0
L4.1 to L104.1 

etc.

then save it and compile

compiler will update these LAD references to a first empty local temp addresses