Continuing with the Bit Shift Theme-Using a MOV to move a BSL bit into another ?

Good Morning ,


I appreciate your help on a previous post.Your advice helped
me understand more.


My next question involves the same project using a CompactLogix L33




I have 2 conveyors with different speeds.One conveyor 98 fpm
and the other 30 fpm. I'm using a timer of " roughly" 100 ms , to shift the result of the vision system on the one conveyor in the BSL. 100 ms , DN , Shift then 100 ms , DN , shift , etc.


When I get to the other conveyor running 30 foot per minute ,
I need to have another timer, slower than the first one , let's say 300 ms , to index another BSL to keep track of those failures. I still need my first BSL so I can keep track of the
new results coming on the first conveyor.


What I'm trying to say is everything is working well but I need to take the final bit from the BSL for conveyor 1 , and use a MOV to move this 1 or 0 into the first bit of the new BSL . For example ....


MOV Instruction
Vision Result Conv. 1 [3].31
Vision Result Conv. 2 [0].0


When I verify I keep getting. Invalid data type. Argument must match parameter data type


Any thoughts why I can't do this MOV ? It seems fairly straight forward. I know I'm missing something .


Thanks so much in advance .

Years since I used AB but pretty sure that a move is 16 bit so may create an error, perhaps use AND Source_Bit[31] set Dest_Bit[0]
SourceBit[31] DestBit[0]
-----| |---------------(OTL)

The compactlogix is a 32bit beast, I would take the fullstop out of your tag name ( after Conv), the compliler don't like it.


Steve

Cydog said:

What I'm trying to say is everything is working well but I need to take the final bit from the BSL for conveyor 1 , and use a MOV to move this 1 or 0 into the first bit of the new BSL . For example ....


MOV Instruction
Vision Result Conv. 1 [3].31
Vision Result Conv. 2 [0].0


When I verify I keep getting. Invalid data type. Argument must match parameter data type


Any thoughts why I can't do this MOV ? It seems fairly straight forward. I know I'm missing something .

Click to expand...

MOV is for transferring the numeric value from one multi-bit tag (8- or 16-bit or 32-bit integer, 32-bit real) to another. e.g.


where Conv.1 and Conv.2 are arrays of integers, most likely.


The BSL is moving a bit, and that is done with an XIC tied to an XIO:


That said, this is much more difficult to make happen only on a rising edge e.g. of a timer done bit; you may need to use OTL and OTU: OTL if the source bit is 1 and OTU if the source bit is.


But rather than doing all that, I think you want to make {Conv.1[3].31} the source for the BSL on the Conv.2 array, triggered by the edge of a single timer i.e. the timing for the two sides run at the same rate.


The fpm of the conveyors is not what is important and what sets the timers; it is the ratio of the lengths of each conveyors to their fpm, which are the residence times of the conveyors. those residence times need to match the residence times of a bit in the arrays which are being BSLed i.e. the number of bits times the timer duration.


And once you have a single timer, then you don't even need two arrays: the time between the pass/fail detection on the earlier 90fpm conveyor and the exit from the later 30fpm conveyor is fixed and can be handled with one array.


If you have two BSLs being triggered by the rising edges of the done bit of two different timers, 100ms for the first and 300ms for that second, then you will be throwing away two out of every three bits from the first conveyor.


This all assumes the transfer from one conveyor to the next is automatic and repeatable, and breaks down if it is not.

Should not need to unlatch it as the shift should push it into the fifo & replace it with a 0, in saying that, some shift registers require a different bit not bit 0 as the data so resetting it may be only option. but there is no reason not to set the bit directly in the shift & have a dummy as the source it depends on the shift code. I have come across different ways in various PLC's and not having RSL loaded at the moment could not try it. One problem I can see is having two shift registers running at different rates is if the first is running faster than the second you will miss some data or overwrite existing. Use the same clock rate but increase the size of the slower conveyor fifo.

drbitboy said:

But rather than doing all that, I think you want to make {Conv.1[3].31} the source for the BSL on the Conv.2 array, triggered by the edge of a single timer i.e. the timing for the two sides run at the same rate.

Click to expand...

The way to do this is to have the .UL (UnLoad) bit of the control structure of the upstream conveyor and bit array be the source bit of the BSL for the downstream conveyor.


But again, if the rising edges (of timer .DN bits) come in at different rates, bits will be either lost or overwritten, and if the timers run at the same rate then you need neither two timers nor two arrays.

Thank you guys , so much . Let me digest this , this evening , and put it in my program in the morning .

Have a great evening ,

It might be easier to use a block of contiguous data to do your BSL on and then move chunks of it onto your structure.

Just in case you do choose to cascade the bits between the respective conveyors at different rates, here is an attempt to ensure approximately every three bits BSLed off of the 98fpm conveyor at 100ms intervals will be ORed into one bit BSLed onto the 30fpm conveyor at 300ms intervals.


The bit source is from the low ten bits of a poorly pseudo-randomized DINT shuffled on rung 0, with a a bit index incremented on rung 3 at each 100ms timer expiry.


Use or use not, there is no cry.