Shift register help, Siemens s71200

Not familiar with S71200 but did a lot in S5/S7 (155 & 400) just took a quick look at the manual & there does nor seem to be a word shift register as such.
It will depend on how many registers you need for the length of the conveyor is it 100 or 1000, the more the better resolution but needs to be synced with the conveyor.
If I was doing it in S5/S7 I would have a DB of x words (or bytes if they are large enough).
I would create a FB that on a trigger (proximity on the drive shaft) that gave a pulse every x cm and using indirect addressing in a loop move byte x (last but one in the shift register to last byte decrement the pointers and loop until first byte is moved to second byte
The one thing you need is some way of putting say a number representing the divert conveyor number into the first register of the shift register array.
All you need then is a compare instruction to trigger the logic on that divert i.e.
[ CMP Shift_Reg_Word_10, Lane_Number]-------------{set Divert}
I do not have S7 but attached is a GXWorks one that shows a short version of lane diverters.
I'm sure others (LD) here who have S7/TIA could give you the code for a word shift register. I think you need to think about how many shifts you need for the conveyor length. I remember when I did this we ran a box along the conveyor and when it reached each of the divert stations we looked at the shift register array to find out which register tied up with the divert position. there was some slight differences of position so hence the delay timers to ensure it was in position.
 
parky said:
Not familiar with S71200 but did a lot in S5/S7 (155 & 400) just took a quick look at the manual & there does nor seem to be a word shift register as such.
It will depend on how many registers you need for the length of the conveyor is it 100 or 1000, the more the better resolution but needs to be synced with the conveyor.
If I was doing it in S5/S7 I would have a DB of x words (or bytes if they are large enough).
I would create a FB that on a trigger (proximity on the drive shaft) that gave a pulse every x cm and using indirect addressing in a loop move byte x (last but one in the shift register to last byte decrement the pointers and loop until first byte is moved to second byte
The one thing you need is some way of putting say a number representing the divert conveyor number into the first register of the shift register array.
All you need then is a compare instruction to trigger the logic on that divert i.e.
[ CMP Shift_Reg_Word_10, Lane_Number]-------------{set Divert}
I do not have S7 but attached is a GXWorks one that shows a short version of lane diverters.
I'm sure others (LD) here who have S7/TIA could give you the code for a word shift register. I think you need to think about how many shifts you need for the conveyor length. I remember when I did this we ran a box along the conveyor and when it reached each of the divert stations we looked at the shift register array to find out which register tied up with the divert position. there was some slight differences of position so hence the delay timers to ensure it was in position.
Click to expand...

Thanks for the sample, all the help is greatly appreciated! Would it be possible to create an array of ints as my register, when the operator selects a product destination, move the pitch set point of that line selected into the first place in the register, then shift that up with each pulse of the timing wheel until it equals the same of the array?
 
if multiple products for multiple valves may be present at the same time, this will require a separate model (shift register or other tool) for each line-valve.


The key word is model: every program is a model of something in the real world; the only real design choice is the level of fidelity. In this case, the level of fidelity is limited by pulses from the pitch prox.


Ladder or SCL does not matter; anything I do here will be in ladder because

  • Ladder is fun (IMNSHO ;))
  • I do SCL/ST-type stuff (Fortran, Python, C/C++, Javascript, Bash, blah blah blah) all day for my real job, and I don't need to waste neurons on syntax for yet another, especially one, though Turing-complete, otherwise as anemic as SCL/ST (again, IMNSHO ;)).
@LD provided the answer:


I was going to suggest a shift register per product on the line, when shift register = bit value for relevant pitch count then fire diverter + release shift register for next product.
Click to expand...
The trick is to understand how a shift register works. Basically, there is an array of bits:
Code: 
0000 0000 0000 0000 0000 0000 0000 0000
^                     ^               ^
|                     |               |
bit 31                bit 13          bit 0
That shows 32 bits i.e. an array of one DINT (or float, for that matter); creating an array of multiple DINTS increases the number of consecutive bits by 32 per DINT. Each bit models (represents) a position on the main line overhead conveyor; bit 0 models the start of the conveyor, and moving to the left, each bit position models a position offset by another 1 pitch downstream from the previous bit/position, so the array in toto models all pitch positions on the conveyor. OP mentioned a pitch position of 130, so five DINTS would allow for a conveyor length of 159 (5*32-1), or ten for 320 bits modeling 320 pitch position, which covers ISO's canonical (;)) engineering formula "double it and add 6" with room to spare. If one line's valve is at an offset of 13 pitches from the start, then that line-valve is interested in bits 13, 12 (modeling one pitch offset upstream toward the start of the conveyor), and 14 (modeling one pitch offset downstream toward the end of the conveyor); that line does not care about the remaining 306 bits or the pitch positions modeled by them, and neither do we care because memory is cheap.



For one line-valve, we have one or more DBs* with all of the information in the model for that line-valve:

  • dint_array: array of DINTs
  • bpooi: bit position offset(s) of interest
  • next_bit: a bit that represents the next bit, 0 or 1, to be shifted onto the DINT array at bit position 0
  • output_valve: output to operate valve for that line
  • pitch_prox: the pitch prox state; same for all line-valves.
Some of those data may be global, some may be local to an instance of an FB* that implements the behavior below. Those are the data, here is the behavior we want to see:

  • When a product shows up and the operator wants to direct it to this line-valve, they press the HMI button for this line-valve
  • the PLC responds to that HMI button press Setting (Latching) the next_bit (for that line valve) to 1
    • Normally next_bit is 0; we'll see why shortly
  • On the next pitch-prox pulse,
    • SHL-type instruction shifts all the bits in dint_array to the left one position, and places next_bit (1 or 0) into {dint_array, element 0, bit position 0}
      • Bit position 319 is thrown away (nobody cares because it represents a position beyond the end of the conveyor)
      • The bit in position 318 is moved to position 319
      • The bit in position 317 is moved to position 318
      • ...
      • The bit in position 0 is moved to position 1
      • next_bit is moved to position 0
    • next_bit is Reset (Unlatched) to 0
    • Bit positions {bpooi-1}, {bpooi}, and {bpooi+1} are examined,
      • Here's the beef: if any one of them is a 1, then the output_valve bit is given (probably Set/Latched to) a value of 1
        • Otherwise, the output_valve bit is given a value of 0
That is it.


Notes

  • I am pretty sure that can all be coded in a single Function Block (FB)*, which FB is then instanced once for each line-valve.
  • Instead of testing three bits inside the FB, an alternative is to not reset next_bit until three pitch prox. events have occurred, resulting in three consecutive 1 bits being pushed onto dint_array by the SHL, reduce the bpooi by 1, and only test that one bit i.e. at bpooi.


* I think that is the word, I am not fully up to date on Siemens/TIA jargon.
 
Here's a quick example project I did using SCL. I used 32bit dwords for the shift registers, so this will limit the pitch count to 32, and if I've interpreted the spec you will need more than 32 bits for your pitch count.
 
Last edited:
Yes it would be possible, however, there are some assumptions.
Firstly, the operator will need to put in the lane number (assume via an HMI) just before a photocell detects the pack at the start of the conveyor so when the photocell detects the pack it moves the data into the first location of the shift array, the PEC is is the trigger to do both.
For example
Operator enters lane number into HMI.
Pack covers PEC
Moves the lane no. from the HMI register to the first location of the shift register (perhaps you may also want to zero the operator field so they know it's gone).
The Pulses from the proximity on the conveyor shaft moves the data along the array (note the last register in the array gets its data overwritten by the previous but does not matter as there are no more lanes).
The code for each divert station then checks the shift register location for a fixed value i.e. on each station you have a fixed number 1-7 if there are 7 diverters for the 7 lanes
That's all you need to do.
This is an example of the layout
Shift register words array[0-25] (you will need more)
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26
0,0,0,5,0,0,2,0,0,4 , 7 , 1 ,1, 3 ,0 , 0, 0, 7 , 0 ,0 ,0 , 0 ,7
Above are the packs moving along the shift register
.................|..................|................|............|...........|........|...........|
.................D1................D2.............D3..........D4........D5......D6........D7

D1-7 are the divert stations so on each station you compare the register that aligns with the station with the lane number i.e.
At D1 CMP = 1 with array[7]
At D2 CMP = 2 with array[12]
At D3 CMP = 3 with array[16] and so on
As the data is shifted along the array the array aligned with the divert station is compared with a hard coded value at that station and if the same then diverts.
You will have to design the proximity sensor to give pulses slow enough so you do not need a high speed input card (unless the PLC has some inbuilt high speed inputs) but enough pulses and length of shift register so each pulse is a set length of the conveyor for example,
You have a conveyor 10mtrs long, the pack size is 0.5m and the 7 diverts are at 1m intervals, this means that you need at least an array size of perhaps 20 and a pulse every 0.5m (this would be the minimum but I suggest you at least double that so you get a pulse every 0.1m (100mm) and an array size of 100, This gives you plenty of array positions for the detection of pack number and time to divert.
You could drive the conveyor manually enter a pack number and watch the array, when the pack gets to the divert position see which register in the array has the pack number and use that in your code for the compare for that station, or you could calculate it.
 
L D[AR2 said:
Here's a quick example project I did using SCL. I used 32bit dwords for the shift registers, so this will limit the pitch count to 32, and if I've interpreted the spec you will need more than 32 bits for your pitch count.
Click to expand...

Just tested your logic out, that is exactly what i have been looking for! Thanks very much for your effort, much appreciated!
 
@Bcurry135:



Is there a prox to detect the entry of a product into the beginning of the main line overhead conveyor? could it stop the conveyor to wait for the HMI entry?
 
Thanks everyone for all your input, think I have finally got my head around thanks to all your input!

@drbitboy yes the product will hit a prox switch and that is when the operator will select which line it should go to.

@LD Yes a 64 bit register would be even better!
 
Project set for 64 bit but generalised to deal with any multiples (>1) of 32 bit registers.
 
Last edited:
update: never mind, I misread @LD's post.]



Btw, another way to do this with bits is to have a array of SINTs as a FIFO, and each bit in the SINT represents a line-valve destination, and each line-valve checks its bit at its target array address(es).
 
drbitboy said:
update: never mind, I misread @LD's post.]



Btw, another way to do this with bits is to have a array of SINTs as a FIFO, and each bit in the SINT represents a line-valve destination, and each line-valve checks its bit at its target array address(es).
Click to expand...

Would this work the same way as LD’s example?
 
If the operator enters a line number 1-7, 0 being no pack it makes sense to use a word or small int, that way there is no need to mess about in the PLC converting some bit pattern just type in the line number, Ideally the pack detection proximity/PEC should be located close to where the pack enters the shift register i.e. pack detected, data entered when pack covers PEC & conveyor pulse to put the value into the shift then the operator entry zeroed to let the operator know the pack has left the entry area. The last one I did on a sortation system the conveyor fed 17 cross lines, it continued in a loop so if a pack bar code was not read it would go around again up to 3 times, then discharge down a reject lane, I used a word shift but it was split into two bytes, the lower byte was the bar code, the upper byte split into two nibbles, the nibbles contained the number of mis-reads lower nibble & the reject required value in the upper nibble. There was talk about also using the upper nibble for over weight as well but it never was introduced.
 
Bcurry135 said:
Would this work the same way as LD’s example?
Click to expand...


Not sure, but if @LD's code has six separate shift registers moving in parallel, then yes and no: yes there will be six lines of flag bits moving in parallel; no there will not be six separate shift registers driven by six SHL or SHR instructions per pitch pulse, but each of the six bits representing each pitch position will be combined into a single integer in the FIFO, so moving integers through the FIFO moves the six bits in parallel with one instruction per pitch pulse.


Actually it's more like @parky's code, because each integer cannot have more than one bit set*, so the only possible valid "bar codes" are 1, 2, 4, 8, 16, and 32 (assuming the low 6 bits are used).


* because a product at any pitch position cannot be destined for more than one line-valve
 

Similar Topics

H
Codesys 3 shift register help
Hi I am fairly new to codesys 3 but I'm currently trying to make a little project using 4 cameras, a sensor and a conveyor belt each camera take...
Replies
7
Views
3,688
ndzied1
ndzied1
E
Help with SIMATIC TI335 shift register
Posted previously but had the wrong info, hoping to get new advice. Being a mechanical engineer, I'm not very experienced with PLCs, and what...
Replies
7
Views
2,454
eternalphoenix64
E
E
SIMATIC TI505 shift register help
I'd like to start by saying that my background in engineering is mostly mechanical, and I have a tiny bit of experience with AB and RSLogix (to...
Replies
10
Views
2,651
Dravik
D
S
Help on Shift register
Hello dear experts! just started learning STL and tried writing a program that writes the status of a particular bit M0.1 on 80 bits of...
Replies
2
Views
1,756
Super_unknown
S
J
HELP! why 253.14 with shift register?
hello people, im totally NEW in plc. i'v read reference of ladder diagram (OMRON PLC CPM1A-20CDR). why do people use 253.14 as data input of...
Replies
6
Views
4,569
sthompson
sthompson
Back
Top Bottom