drbitboy
Lifetime Supporting Member
FYI, I have a BSL that may need to shift its Source's bits on contiguous scan cycles; a single BSL will not do that because it only executes a shift on the rising edge (FALSE-to-TRUE transitions) of its input rung.
The way to get around this is to call the BSL/BSL object a second time, during the same scan cycle, with a FALSE input rung; this effects the equivalent of OTU R6:0/EN or OTU control.EN in RSLogix-land, because CCW will not let me reset the .Done bit of the BSL object.
Here's the FYI: I tried several approaches, some of which should be functionally equivalent, but only a few successfully compiled.
This does an unconditional reset of the BSL object, but fails to compile ...
... but moving the AFI/BSL pair on that second rung to a branch of the first rung does compile ...
... while putting them on the same rung fails compilation ...
... then, removing the AFI, which is logically incorrect, allows it to compile ...
... while, finally, replacing the AFI with its logical equivalent to make it correct, does compile:
The way to get around this is to call the BSL/BSL object a second time, during the same scan cycle, with a FALSE input rung; this effects the equivalent of OTU R6:0/EN or OTU control.EN in RSLogix-land, because CCW will not let me reset the .Done bit of the BSL object.
Here's the FYI: I tried several approaches, some of which should be functionally equivalent, but only a few successfully compiled.
This does an unconditional reset of the BSL object, but fails to compile ...
... but moving the AFI/BSL pair on that second rung to a branch of the first rung does compile ...
... while putting them on the same rung fails compilation ...
... then, removing the AFI, which is logically incorrect, allows it to compile ...
... while, finally, replacing the AFI with its logical equivalent to make it correct, does compile: