SLC Problem

Help!

O:9/0 is on but should not be.
Anyone see this before?

Sam

1. That rung isnt scanned cyclically,
Could be that the calling JSR isnt executed.
Or there is a JMP instruction before the rung.

2. Somewhere else in the program the entire word O:9 is written to.

3. The logic in the rung changes so fast that you cannot see it. It would mean that i:8/17 is reset inside the program after rung 8:9 (unlikely).

Try to XREF O:9

Try to add a test bit OTL nx:y parallel to the OTE.
Then look if the test bit is set or not.

Yes,
If this in subroutine and was true when the subroutine was last scanned.
But you may have a condition in the jump instruction which won't scan this subroutine anymore.

One other thing, a "shot in the dark" is check out if I:8/17 is cycling on and off. Run a histogram on the input and output to see if the output is turning "on" then "off". I also agree with everyone else and their suggestions.

I'd keep a close eye on that "histogram" feature ...

the RSLogix histogram is a great feature ... but ... regrettably it is flawed in the SLC and MicroLogix processor families.

When you do a histogram with the larger PLC-5 (specifically the enhanced line) family of processors, the processor itself monitors the status of the histogram's bits. Then, whenever the processor gets a chance to communicate with your computer, the processor sends over a "chunk" of data to update the histogram charts. Incidentally, this "chance to communicate" does NOT come around on each and every scan. But even so, since the PLC-5 processor is keeping a close watch over the bit status internally, the PLC-5 histogram will give you pretty durn good results.

On the other hand, with the smaller SLC and MicroLogix processors, the processor itself does NOT monitor the status of the histogram's bits. All of the data on your screen MUST come through the (relatively) slow programming cable. In other words, the bits may go off and on several times before the histogram (which lives ONLY on your computer) gets a chance to check their status. With these smaller systems the histogram will update its status in "fits and starts" and so the status of the bits you are monitoring might not be reflected accurately in the histogram display.

So play with the histogram by all means. In many cases it may help you find the answer to a knotty troubleshooting question. Just be aware that (when using an SLC or MicroLogix) just as the screen lies - so does the histogram. I've seen technicians attempt to use this thing for days while troubleshooting a problem - only to find out later that the histogram had been lying to them all along. This is much like having intermittently broken leads on your volt meter. If you can't trust your test equipment - then whom can you trust?

And incidentally, for those of you who’ve never heard of it before – the histogram is found under the RSLogix menu at the top of the screen under “Comms”. Unfortunately you must be Online with a processor to even see it – it will be “grayed out” on the menu when you’re Offline.

With the SLC and MicroLogix processors, the "test bit" trick suggested by Jesper is usually a lot more trustworthy for confirming the "on/off" status of suspicious bits than the histogram.

1. The ladder file is a subroutine but it runs every scan.

2. The output is not written to anywhere else.

3. I:8/17 was constantly off - it never intermittently came on.

I believe the answer has to do with the fact that I:8/17 is from a DeviceNet scanner which was faulted. The 24VDC power supply to the DeviceNet loop failed. The manual states that a faulted scanner 'does not scan' IO and something other stuff about a default fail state. Either way, I would think that Logix would show the state that makes sense but apparently not. With the power supply replaced the rung displays and acts correctly.

Sam

Wow, thats a new one.

When there is a problem with i/o on DeviceNet RSLogix does not display the same state as the CPU uses to solve the code logic.

To follow your description, it would also mean that the 'default fail state' is ON !
It must be, otherwise the logic in rung 8:9 could not become TRUE as it happened to be.

Thats TWO dangerous things on top of each other !

If you can, I would try to change the default fail state to OFF.

JesperMP said:

Wow, thats a new one.

When there is a problem with i/o on DeviceNet RSLogix does not display the same state as the CPU uses to solve the code logic.

To follow your description, it would also mean that the 'default fail state' is ON !
It must be, otherwise the logic in rung 8:9 could not become TRUE as it happened to be.

Thats TWO dangerous things on top of each other !

If you can, I would try to change the default fail state to OFF.

Click to expand...

Jesper is correct here. And it can go a bit farther; even after restoring the DeviceNet comms, the scanned input may not correctly update the image table in the SLC until a restart, or sometimes even powerdown / powerup.

Set up one or more global communications fault status flags that latch on a comms fault, and use that to lock out critical outputs if needed, or trip a processor hard fault.

Thanks for the verification. I thought I was going nuts.

Sam

This can't be!

When DeviceNet fails, the I/O can remain in their last state. Scanner faults can be used to set I/O to a safe state with logic. The fact that I:8/17 has faulty data due to DeviceNet, should not prevent the SLC from controlling the output properly.

A bit of a shot in the dark, from your posting it looks like you had done a "bit" level search on your output, have you done a "word" level search on the secific output word that the output is still on in? If a register or the like is being written into the output word it could produce the result you are seeing? It has been very rare where I have seen this occur when someone transfers a value on a word level to an output word, but it is possible, and would give you the result you are seeing.
I have written logic before that writes to Output words, generally all "0"s in the event of a communication fault, mainly with pviews to compensate for power loss to Pview while a Pview button was pressed. If for some reason a different value was inputed into the word to write in on a fault condition, you may see a result like you are seeing.
Like I say, just a shot in the dark, good luck.

electrified3,

I just did a word search on O:9 and that word (as a whole) is not being used, only two bits. Also, those bits are only written to once. (that is, only one OTE per bit)

Derek McFarland,

I agree that it should not be - but it was. The DeviceNet power failed and the bit was somehow 'latched' in its last state (ON). The rung acted as if the bit was ON but Logix500 showed it OFF. My screen dump proves it.

Sam

Instead of a SEARCH, try a Cross-Reference. It will show File-level instructions that a Search will not. It can also help find indirect addressing (scroll down to the end of the O: list in the XRef. If there's a O:9/[N7:0] (and N7:0 just happens be 0), it will show up there.

I agree with Derek and others (Even Jesper - I don't think he confirmed what you were saying, merely marvelled at it). This cannot be. The DeviceNet may not update the data table, but the data table is the data table is the data table. There's not one for viewing and one for logical evaluation.

If you can post your code, I'm sure that someone can find the problem in just a few minutes.

Your screen dump doesn't prove anything. It poves that you are in a subroutine with an output that is turned on even though the logic is false.

You have indicated you have searched, but as Allen suggested, do a cross-reference. Or better still, turn on the cross-ref feature in the RSLogix so you can see for yourself exactly where it is being used. Go into View => Properties and click the Address Display tab and turn on the Show cross-reference features.

The other item we still haven't solved is how is the subroutine executing. We need to see that too.

As Allen said, post your code. we will find the problem! There could be JMP instructions or indirect/indexed addressing affecting this that we just cannot see from the screen dump.

OG

Here is the x-ref stuff.