Bit-Shifting in Omron PLC's

[scrambled]

Hi,

I need to bit-shift a block of words in an Omron PLC by a certain amount. Is SFTR the only way to do this? I've tried NSFR/NSFL but from testing it, it seems those instructions are only restricted to a single word.

SFTR seems to do what I want but it looks like it works off a pulse input, which is a bit annoying as I want to run it on consecutive scans within a FOR loop to do my bit-shifting. The help file for this instruction seems to be quite contradictory:

When the execution condition of the shift input bit (bit 14 of C) changes to ON, all the data from ST to E is moved in the designated shift direction (designated by bit 12 of C) by 1 bit, and the ON/OFF status of the data input is placed in the rightmost or leftmost bit. The bit data shifted out of the shift register is placed in the Carry Flag (CY).

The data in the shift register will be shifted one bit in the direction indicated by bit 12, shifting one bit out to CY and the status of bit 13 into the other end whenever SFTR(084) is executed with an ON execution condition as long as the reset bit is OFF and as long as bit 14 is ON. If SFTR(084) is executed with an OFF execution condition or if SFTR(084) is executed with bit 14 OFF, the shift register will remain unchanged. If SFTR(084) is executed with an ON execution condition and the reset bit (bit 15) is OFF, the entire shift register and CY will be set to zero.

So...am I meant to be pulsing bit 14 or just leaving it on all the time? I've tried both but haven't gotten any bit-shifting to occur, perhaps I'm doing the pulsing incorrectly...

 

[scrambled]

I'm realizing I'm running the SFTR instruction multiple times in one scan using a FOR loop. This may mean the instruction probably isn't picking up the pulse input, since I'm manually pulsing it between FOR loops instead of between scans. So it looks like SFTR may not be what I need. Does anyone know any alternatives for bit-shifting across word boundaries in Omron?

 

[Doug-P]

I'm realizing I'm running the SFTR instruction multiple times in one scan using a FOR loop. This may mean the instruction probably isn't picking up the pulse input, since I'm manually pulsing it between FOR loops instead of between scans.

Is it possible to add an identical shift instruction with the shift command permanently disabled? What about multiplying by two?

 

[Sergei Troizky]

I need to bit-shift a block of words in an Omron PLC by a certain amount...

How many bits? Always the same quantity? If no, what are the minimum and maximum numbers? Is it always multiple of 16 or 32 bits?
By how many bits? Is this always the same quantity? If no, what are the minimum and maximum numbers?
Shifting always in the same direction? Which direction?
What controller?
Do you really need to loop within a single scan? (Doing this with no real need is a typical mistake, forgetting that the PLC program execution is cyclic by definition).

 

[osmanmom]

i don't understand your question,

what type of project you what to design

 

[scrambled]

I need to shift a contiguous block of words by a variable amount of bits. The reason for this is that I am trying to write a Modbus TCP coil read function block for the CJ1W-ETN21 module as part of a project I'm working on. Omron has a function block for Modbus but it only implements register reads and can only perform single coil writes. As part of the project requirements, we need the ability to read individual coils.

The reason for the bit shift is that I need to copy a block of CIO data to the TCP data area and then bit-shift it based on the target coil and coil length of the modbus request. I was hoping to use SFTR to shift the entire block of words at once, but it seems it may not be as suitable as I thought it would be. I think I'll probably have to look at shifting each word individually since most of the data shift instructions don't seem to work across word boundaries.

 

[gclshortt]

http://www.proenergo.ru/doc_pdf/plc-doc/w394e1-3.pdf

Why not use a block transfer to move the data into the TCP data area? (XFER)

Why not just use the register that you read and break down into the individual bits you require?

Garry
http://www.accautomation.ca

 

[scrambled]

Hi Garry,

I am already using XFER to move the block of data, but I still need to bit-shift the entire copied data block such that first bit of a certain byte in the TCP data area starts with the value of the first coil requested by the Modbus master. This is to keep in line with the Modbus standard. The amount I need to shift by may not always be neatly divisible by hex digit or word boundaries since the master may request any coil number. Hence why I was trying work with SFTR as a possible solution. Unfortunately, it does not seem to be as simple as I thought. I've since moved on to using a buffer to bit shift each word individually and then copy to the TCP data area, and have been having better luck with that method.

 

[lostcontrol]

Indirection with IR/DR should achieve it, if I understand what your trying to achieve.

Your master requests x values from y location.
You then need to get those values & copy them to the byte index that is being read by your master.

 

[scrambled]

I managed to get it working by using a buffer to copy two words at a time, bit-shifting them in opposite directions, and then OR'ing the two results together to combine them. A bit more convoluted than I would've liked but I'll deal with it.

 

[Sergei Troizky]

The following code will transfer a block of bits of arbitrary length, with source and destination areas starting from arbitrary bits.
Set the Transfer bit after specifying the transfer source, destination and length.
The bit address offsets for initial writing to DRs are (16dec*Channel+bit), e.g. CIO300.05 must be specified as 300*16+5=4805dec
Be aware, that the source and destination areas may overlap only if the destination is lower than source. Otherwise, the code must be rewritten for descending addressing starting from calculated end.

 

[scrambled]

Hi Sergei,

Thank you for your example, your method is quite elegant. I wish I'd thought of using IR/DR sooner as it's certainly more intuitive than the method I ended up going with. If time permits, I may try re-implementing my solution that way.