SLC Problem

[Samneggs]

This shows the routine in question (ladder 8) runs every scan. Please trust me that there are no other jumps around that rung, there aren't. I don't feel comfortable posting entire program.

 

[Allen Nelson]

More straws slip through my grasp

OK, so what you've posted shows that there's no word-level usage of O:9.

And I'm willing to take your word on the lack of a JMP instruction in any of the LAD 8 rungs above 8:9.

An MCR would turn the output off, not leave it on. (just thinking out loud here).

A TND instruction would leave it on (even if the TND was in any ladder file called before LAD 8), but surely you would have noticed one.

Same with a RET instruction in rungs 8:0 through 8:8.

That just leaves indirect addressing. The cross-reference that you show is the "Usage Report" (a handy feature). But I need to see the REAL cross-reference (such as what OG had you turn on). Select O:9/0 (from anywhere), right click, and select Cross-reference O:9/0.

The list for O:9/0 will only show that which is displayed below the output. But if you scroll through the list, you might find an entry that looks like this:

[attachment]

The "trouble" may not be in the O:9 word. If, in my picture, N100:30 had a value of 32, I belive that O:3.0 would be affected, since it comes after O:2.31.

It's not good practice to code this way, but you never know.

I can understand your reluctance to post your code, but I assure you, it wouldn't make much sense without knowing how the machine is put together.

If you really want to make the code make no sense, then go to the Address/Symbol Database (available at the bottom of the Project Tree), and delete all the annotation. That will make it completely incomprehensible. (It goes without saying - do this on a copy of your program).

 

[Contr_Conn]

I think indirect addressing most likely the problem, unless you have a faulty hardware.
Also it is possible that another PLC sending MSG command to this processor and sets this bit. Disconnect all comms to see if it is true.
To see if you dealing with faulty hardware I would load a blank program to the processor (cycle power after load to reset all outputs). If output goes off, try to contorol it with simple logic or just setting data table address.

 

[CSE]

I apologize in advance for the short reply. I just had a quick thought that leakage current could be to blame for the false 'ON'. Have you verified the field connection and status of the device?

 

[93lt1]

...leakage current could be to blame for the false 'ON'.

It's an output that's giving the false 'on'.

 

[Operaghost]

Ok,

Here is a simple test....Right click on the output and select "Toggle Bit".

If it turns off then there is no logic controlling it so the rung, or subroutine, is not being scanned.

If it comes right back on then there IS logic controlling it and telling it to turn on. Or as Contr_Conn suggests, it is coming from someone on the network (not the DeviceNet though).

Leakage current is not the issue here as this is an issue we are seeing in the logic.

OG

 

[Guest]

Just a little off topic.....

I know this is a little off topic....

I have been playing around with messaging, and it has occurred to me that a remote SLC could send a message to the SLC in question, overwriting any number of binary bits or integers (or even outputs?).

My question is : Is there any way to prevent unsolicited messages?

 

[JesperMP]

I also back the idea of us having a look at the code.
Strip the comments, zip it, and PM the ZIP file to a few of us (I wouldn't mind to take a look).

Maybe you are not interested in experimenting with a running system.
That only leaves us with the code. It would be VERY interesting to have this strangeness confirmed.

 

[Samneggs]

Here is the cross reference. I really don't think anything else is writing to O:9.

 

[Samneggs]

Here I did a search for a '[' indicating indirect addressing. It found two hits buts not not on O:9.

 

[Operaghost]

Ok, your cross reference was oh so close, but we actually need to see what was just above what you posted.

Cross reference O:9.0

This will show us where the whole word is being written to which would include O:9/0.

Also, did you try disconnecting the network cable to rule out this coming from another controller? <see erlier posts>

Did you try my idea of toggling? <see erlier posts>

OG

 

[Samneggs]

Operaghost,

The search was done on O:9.0
I used O:9 as an abbreviation for posting only.

***Nothing else is writing to O:9.0***

After the devicenet was fixed the problem went away. The odd condition no longer exists. Disconnecting the network cable or toggling the bit will not prove anything.

Thank you very much for your effort. (and all the others too!)
But I don't think this one will be solved at this time.

Sam

 

[chorn46562]

Seen something similar

Yes I have seen something similar. It was using RSLogix 5000 and what I discovered was that the RSVIEW32 application, that was running on a computer with a touchscreen, had held the output on even though the rung was false. I checked with tech support and they found out that there is a bug with RSView but have offered no patch as yet.

 

[JesperMP]

That does not explain what samneggs saw:
That the rung evaluated as TRUE, while one of the conditions was FALSE - as displayed by RSLogix.

Even if "something else" is manipulating 0:9/0 then it cannot HOLD it ON if the state of the output is decided in every scan by rung 8:9.

Either RSLogix doesnt truly display the status of input I:8/17,
or rung 8:9 isnt scanned cyclically,
or output O:9/0 is written to somewhere else in the program.

Samneggs,
for the sake of our sanity, please do the following things:
1. XREF 0:9 (not O:9/0 !).
2. Search for any JMP, SBR, JSR, TND or RET instruction before rung 8:9.
3. Check that S:2/3 "Index accross files" is set to NO.
You can do the above easily without having to stop your proces.

 

[Klaus]

but the data table is the data table is the data table

Are you really sure? Have a look at the timebase of T4:117:

(Rslgx5 and PLC5)