OSR indexing issue

[srsicard3]

Hello, I am having an issue with an OSR bit starting a rotary indexer.
Running AB studio5000 on a 5069 L320ER v32.1

I have 13 inputs before an OSR instruction. the output of the OSR instruction is to start a rotary indexer logic. i have used this practice on multiple machines with no issue.
this particular machine seems to not respond the same way.
the logic before the OSR is all true, and the output bit seems to never go high as the indexer does not respond.
I have tried using the output bit to latch a bit to start the indexer and breaks the latch when the drive responds.
the machine will run for about 15-25 min then hang up waiting for the output bit to start the logic.


Does anyone have any input on this?


I have attached the code. I am on the greener side when it comes to machine programming.


Any help is much appreciated!



Edit:
Second picture added of PLC in hangup state.

 

[parky]

It looks to me as if the NOT VFD4 start bit is the problem, when the one shot is triggered it sets the cycle latch but on next scan because the VFD Start bit is on this will reset the cycle call latch. therefore resetting the VFD Start. Not looked too deeply into it as some other bits on the VFD start appear to be false so not sure if the cycle call latch needs to stay on, if not then don't see the point in latching it. Try removing the Not VFD contact out of the latch.

 

[srsicard3]

I just need something to reset the latch so it does not stay on continuously. maybe i can try to VFD4.AtReference bit.
the run that contains the VFD4.Start coil latches and unlatches based on the position of the indexer. so as long as it starts, it will stop at the correct position. just getting it started seems to be the problem.


Thank you for the input!

 

[parky]

It may be that it is only on for one scan so does not see it. So I assume that the VFD is a Start command that pulses only, maybe you need to latch it for a few milliseconds or longer for the VFD to "Catch" the pulse.

 

[drbitboy]

Either DialProx needs to be 0 or DialBRKTIMR.TT needs to be 1 for the VFD4:O.Start seal-in on the bottom branch of rung 7 to work, when CycleCallLTCH is assigned a 1, or else VFD4:O.Start will be, in effect, a one-shot. I think this is equivalent to what Parky said earlier, but with a different focus.



What resets the TON (InFeedPartSensorDebounce) on rung 4?



I am guessing that the CycleCall OSR output was normally at the XIC that examines CycleCallLTCH on the middle branch of rung 7, before you added CycleCallLTCH. Is that correct?

 

[srsicard3]

DialProx is a sensor on a cam. when the drive starts DialBRKTIMR.TT mutes the DialProx bit until the cam moves off of the sensor. when DialBRKTIMR.TT times out the drive will stop once it sees the DialProx signal come back.


this is a weiss rotary indexer. its a fixed station indexer. the cam triggers the sensor when the indexer is in position. to index to the next position i need to mute the sensor to allow the cam to move off the sensor then look for the sensor to come back high to stop.


the logic works fine for anywhere between 15-30 min (3 sec cycle time) then locks up as if the OSR output is not triggering.

 

[drbitboy]

On rung 6, add a branch around the [XIO VFD4:O.Start] i.e.

XIC DialProx XIO DialBRKTIMR.TT
​

so CycleCallLTCH will stay latched until that bottom seal-in branch on rung 7 goes true.


Otherwise VFD4:O.Start may be a one-shot.

 

[srsicard3]

Got it working correctly again. thank you all for the input

 

[drbitboy]

What was the fix?

 

[srsicard3]

ended up controlling the VFD4:O.Stop coil with a NOT VFD4:O.Start bit.
there were a couple of issues where the start & stop commands would be on at the same time, thus locking up the process.
too many cooks in the kitchen as they say!