I feel like a lab rat in the CCW maze

[drbitboy]

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:

​

 

[lostcontrol]

Considering it contiguous scans, why not just roll yr own?
Surely that be a menial dash for the doctor of bits.. ��

 

[Steve Bailey]

What is the number of bits in BSL_BITS? Can it be multiplied by 2? If not, can it be transferred to/from an integer that can?

 

[drbitboy]

What is the number of bits in BSL_BITS? Can it be multiplied by 2? If not, can it be transferred to/from an integer that can?

2000, but it could as easily be 2048. Why?

Anyway, I don't have a question, this was just an interesting FYI of the comedy of errors, clown fiesta that is CCW, and what workarounds are available.

After a while I stopped being annoyed and just started enjoying the stochastic ride "Oh dear, AFI does not work there, hmm, but [XIC a_bit XIO a_bit], which is equivalent to AFI, does work there."

 

[ASF]

So far I've resisted all attempts to use CCW for anything other than drives (and even then, not for several years - I just use Logix now), but the way I'd approach this in Logix would be to unlatch the bit that stores the previous rung-in state.

E.g. the CTU instruction is likewise an instruction that counts once every false-to-true transition, but you can make it increment every scan by placing the counter on a rung immediately followed by an OTU addressed to Counter_Tag.CU.

No idea if you can do the same thing with CCW but that'd be my first approach.

 

[drbitboy]

So far I've resisted all attempts to use CCW for anything other than drives (and even then, not for several years - I just use Logix now), but the way I'd approach this in Logix would be to unlatch the bit that stores the previous rung-in state.

E.g. the CTU instruction is likewise an instruction that counts once every false-to-true transition, but you can make it increment every scan by placing the counter on a rung immediately followed by an OTU addressed to Counter_Tag.CU.

No idea if you can do the same thing with CCW but that'd be my first approach.

Yeah, as I wrote in the OP, that was my first attempt, but CCW will not let me clear the value of the .Done bit of the BSL object, apparently it cannot wrote to at least some object-internal members.

So like I also said, the purpose of this thread is to document functionality not readily available in CCW, and to show some possible workarounds.

 

[ASF]

That'll teach me to skim read

As you were!