GaryS,
I'll come back to you tomorrow. I need to sleep before attempting to decipher, digest and reply to all that!
JaxGTO said:
You running logic is fine. The little e on the left means the rung in NOT part of the program but just a new rung entry that has NOT been accepted. You can delete that with no effect on your running program.
It's like going to the END rung and just start typing stuff and hit enter. The rung is just ready to be accepted. Until it's accepted it is just in the programming software.
JaxGTO,
We need to be careful here. As I pointed out, and you are now reiterating; the logic on the above rung, as it appears above, is indeed not in the controller's memory. It is, as it appears above, only present in the offline image in the project file open on the OP's workstation. However, if the OP was online with the intention of editing an existing rung of logic, which is in the controller's memory, and corruption then occurred to this existing rung, then the now corrupted same rung in the offline image is not just a "new rung entry that has NOT been accepted". It is an existing rung which the software can no longer display correctly. The software is attempting to display the logic as best it can decipher while using the UNK instruction as a placeholder for each corrupted instruction instance. As the rung of logic in the offline image is not verifiable, the software automatically places the rung status in edit (e). But this rung does exist in the controller in its correct format and is still important to the offline image.
So, even though you can "delete that
rung with no effect on your running program", it is still an existing rung which is now corrupted and needs to be recovered, in the offline image. It should not be discarded as if it's a new rung that you may decide you now don't want to add. Again, the controller's compiled code for this rung is intact and will execute as it has been all along. But with the offline image corrupted, the OP's copy of the project now does not reflect what is actually in the controller and needs to be recovered, not deleted or forgotten about.
While explaining to you here - that just because you see "e" for edit on a rung, especially with UNK instructions, the rung is not automatically like any other new rung with pending edits, and you should not just discard them; it actually should not matter in the greater scheme of things. When you perform an upload, using the corrupted offline copy of the project, the controller will restore the rung of logic either way. So even if it had been deleted, it does not really matter.
I just emphasised not deleting them off-handedly above as I wanted to make the distinction here that these corrupted "e" rungs are not to be dismissed off hand as unimportant with respect to the code running in the controller. If you were at a customer's installation and this happened, and you deleted an apparently innocuous "e" rung that you didn't know where it came from, and then saved offline and left, you would now not have a current matching offline image for the customer's controller.
What I'm explaining here are facts, not opinions. I'm reading well intentioned guidance here but the conclusions have been somewhat misguided.
G.