I have an application where I have cascaded a ONS instruction and a OSR instruction. The ONS instruction preceeds OSR instruction. Is it advisable to do so? Do you foresee any problem when using instructions in this fashion.
if you don't use ONS-memory any more after this rung, You can
use -( )- as well, but this case it happends on same program scan.
In your model it heppends on next program scan when (OSR) conditions Rising. Anyhow it seems usable.
Use B3/1 and B3/3 as "one shot" bits for I:0/0 throughout your program. Or in your case U1_gripper_clear input.
In your code, because of the ons after the gripper_clear input, the result of the rung--even if it's a normal B/* coil, is only on for one program scan. The OSR at the end is a waste of a bit. Now if you need to examine the gripper_clear later as a one-shot, you'll waste another bit on another one-shot--plus you have to fat-finger more code.
What I do normally, is figure out which of my inputs I will need as one-shots--anywhere--then do them as I did above. Then I've got a "one shotted" bit to use over and over again.
With the addition of the picture, it becomes more clear. In the OTHER THREAD, I was picturing this:
|
|---] [-----[ONS]-----[OSR]
.
With the ONS immediately preceeding the ONS, and therefore my response was wrong.
In THIS thread, the ONS creates a 1-shot for the "U1 GRIPPER CLEAR" switch, while the OSR creates a 1-shot for the output. From what I see, the OSR can be safely replaced with an OTE, but the ONS CANNOT be removed (or moved).
Again, The purpose of the ONS is to look for the leading edge of the "U1 GRIPPER CLEAR" switch!...