SLC 5/05 and OSR instruction

[Soggy Canuck]

I have a program (written by others) at a customer of ours, which is using a poor mans shift register as a method of tracking items on a long conveyor. There are multiple destinations and each destination has it's own shift register. As the item moves along the conveyor a series of sensors are used to hand off the product from one area to the next, a Bit is latched in the new zone and that same bit is fed back via an OSR to unlatch the previous zone. Most of the time the system works flawlessly, however on occasion an item will end up at the wrong destination. while online trying to troubleshoot this(OF COURSE works fine while I'm there!), I noticed that occasionally the latch would not unlock even though the preconditions on the OSR had been met? Long story short when will an OSR not trigger correctly?

Mike

 

[bernie_carlton]

If the items are back-to-back could the bit in the new zone never go false between the items thus not generating a second OSR?

 

[OkiePC]

If the storage bit for the OSR is used elsewhere in the program, that could make it "not trigger correctly". That is the only thing I know of that could be truly wrong.

When all of the conditions preceding the OSR makes a false to true transition, the OSR will pass logic one time, and set its storage bit. If any of the logic preceding the OSR is false, it will reset the storage bit. The storage bit is how the OSR knows what it did on the previous scan.

Most likely, something is latching the bit very quickly after the OSR to unlatch it goes true. Due to windows refresh rates, this might be very difficult to see on screen, especially if it is happening during the same scan in which it's unlatched.

I'd recommend that you duplicate the rung in question (use a unique address for the OSR storage bit) and put a spare counter as the output instruction so you can watch the thing in action and see what's going on. Also, monitor both the latch and the unlatch instructions at the same time (you can use the split screen view if they're not adjacent in the programs).

Hope this helps,
Paul

 

[gmferg]

My first thought is what Bernie has just posted.
An OSR can behave unexpectedly if the OSR has an address that is used elsewhere.

 

[Soggy Canuck]

The OSR bit is used as an examine on elswhere in the program, all of the OSR's for a given shift register are in series to a coil(which does nothing), I suspect that the original programmer was using these as a monitor.But how he was expecting to see OSR function on a PC screen is beyond me.

I will try the counter trick and see if I can catch any discrepencies, thankyou for the suggestion.

Mike

 

[Lancie1]

The OSR bit is used as an Examine ON elsewhere in the program,..[/QUOTE]If the same memory address is being used for XIC instructions, then you have found your problem. The OSR bit should not be used for anything else, if you expect it to work properly.

OSR [One Shot Rising]
Description
The OSR is a conditional input instruction that triggers an event to occur one time. Use the OSR when an event must start based on the change of state of the rung from false to true, as triggered by a pushbutton. An example would be to use the OSR to freeze rapidly displayed LED values.

Place the OSR on the rung immediately before the output instruction. Then reference the output as the one-shot in your program. The address that you give to the OSR input instruction is where the previous state of the rung is retained.

You must enter a bit address for the OSR. Use either a binary file or integer file address. The bit address you use must be unique. Do not use it elsewhere in the program.

The address assigned to the OSR instruction is not the one-shot address referenced by your program, nor does it indicate the state of the OSR instruction. This address allows the OSR instruction to remember its previous rung state.
Rockwell Software 2000

 

[OkiePC]

I disagree, Lancie. As long as the address is not used in destructive instructions then it should not hurt anything. I have never done that, so I have no proof, but I would be surprised if reading the state of the bit would cause any problems.

 

[jshiepe]

Hopefully the replicated address is your issue. But if not, the other thing to be wary of is if the OSR is preceded by branches. Keep in mind that everything preceding an OSR must transition from false to true in order for the OSR to pulse. If one parallel branch remains true while the other transitions, the OSR will not pulse.

 

[Lancie1]

Okie,

So, do you think Rockwell put that warning in RSLogix just to confuse us? The word "unique" means one of a kind, no others like it.

 

[OkiePC]

Okie,

So, do you think Rockwell put that warning in RSLogix just to confuse us? . . . .

Yes of course they did. No, seriously, I am sure they meant don't use the address in a way that it could be modified by another instruction. XIC does not modify the address.

I actually found some running logic using OSR instructions in a running machine and put a dummy rung in using XIC for three addresses and watched it for a while to see what happened. If the XICs had caused a problem, all hell would have broken loose on this particular application. The OSRs were fired to trigger a case sorting sequence running about 20 boxes per minute to 3 different conveyors. After an hour, nothing happened, so I removed the logic.

I stand by my belief that there is no harm in using an XIC on the OSR storage bit...unless someone can prove it to me...

 

[robertmee]

Very interesting debate...Although it certainly is explicitly spelled out in the help as Lancie pointed out, intuitively I would agree with Okie, that examining the state of the storage bit (which is what the address is used for) should not cause any issues. Not that I have ever done it, tho.

Back to the original problem, out of curiousity, is the OSR in a conditional subroutine? If the subroutine with the OSR is not called each scan, then there's a possibility that the storage bit is never cleared because the logic is never scanned and that the next time it is scanned, the condition ahead of the OSR is still true. This will also cause a problem on first scan, because the processor sets all OSR storage bits to true on first scan regardless of the rung logic ahead of it. This is to enforce the FALSE to TRUE restriction of activating a OSR. So, if on a first scan, the logic is already true ahead of the OSR, it will not fire. Only when the logic goes false and then true again.

 

[Soggy Canuck]

Sorry for the delay in replying

I double checked the subroutine, and it is not conditional, I have pulled the "monitoring rungs" out of the program and the customer will advise of any further occurance of this issue. I suspect that whatever is causing it is still going to occur as the "monitoring rungs" have been in place since the machine was comminsioned some 8 years ago. The only major change made since that time was to upgrade the processor from a 5/04 to a 5/05 (one way messaging to a CLX-L43). I have yet to actually catch the problem as described but have installed some counters to monitor operation, time will tell.