technique

Using a 504 processor, can I shift words, kinda like a UDT in 5000, in 500?

I have a vision system inspecting bottles. I can get a bottle present trigger and a reject signal to the processor. When I get a reject signal, I reset the encoder and begin counting pulses until I reach the reject station. Problem is, the reject is x distance away but there may be more rejects before I kick-off the first bad bottle. I can use a bitshift, but I haven't been able to tie the encoder counts to the bitshift thus far. Is it possible? I was thinking... If I get a reject, then reset the encoder counts and move it into an integer and shift it as each bottle passes through the bottle present trigger, alas! It has elluded me for several days. Is there an easier solution other than to just use an extra sensor at the reject and tie it to the bitshift?

Use bit shift register for bottles to be rejected. Shift the register every certain length of the conveyor displacement, for which purpose use the encoder reading.

Sergei Troizky said:

Use bit shift register for bottles to be rejected. Shift the register every certain length of the conveyor displacement, for which purpose use the encoder reading.

Click to expand...

Good idea! What about when the encoder counts reset to zero when it reaches maximum 32767 counts?

O.K. so every 500 counts, I enegize BSL and reset the encoder....

Zephyr said:

O.K. so every 500 counts, I enegize BSL and reset the encoder....

Click to expand...

Why reset the high speed counter for the encoder? Just calculate the distance traveled. Crossing zero is easy to detect too especially if the mechanism driving the encoder isn't bidirectional.

So if the encoder counter is at 378 counts when you detect a product that must be rejected 1200 counts later...the reject position for that product will be when the encoder reaches 1578...

If the encoder counter rolls over after 32767, and it's at 32700 when it detects a defect, then your reject position will be (the rising edge of) count > (33900 - 32768).

There are very few good reasons to reset a high speed counter on the fly. Don't do it if you don't have to.

Zephyr said:

Good idea! What about when the encoder counts reset to zero when it reaches maximum 32767 counts?

Click to expand...

Why should it be limited to 32767?
High-speed counters are 32-bit.
Do you use this encoder for anything else?

OkiePC said:

Why reset the high speed counter for the encoder? Just calculate the distance traveled. Crossing zero is easy to detect too especially if the mechanism driving the encoder isn't bidirectional.

So if the encoder counter is at 378 counts when you detect a product that must be rejected 1200 counts later...the reject position for that product will be when the encoder reaches 1578...

If the encoder counter rolls over after 32767, and it's at 32700 when it detects a defect, then your reject position will be (the rising edge of) count > (33900 - 32768).

There are very few good reasons to reset a high speed counter on the fly. Don't do it if you don't have to.

Click to expand...

Nice....Thanks!
I was trying to figure out how to put into logic, the calculation for rollover.

I reset because I am bit shifting every 1000 counts. If I don't reset, how would I detect (and bit shift) every 1000 counts?

Sergei Troizky said:

Why should it be limited to 32767?
High-speed counters are 32-bit.
Do you use this encoder for anything else?

Click to expand...

I have the card set to ring type, it rolls over at 32767. In linear, if you pass 32767, the card faults (I think) from what the manual says...

Zephyr said:

Nice....Thanks!
I was trying to figure out how to put into logic, the calculation for rollover.

Click to expand...

psudeocode:
DD = NowCount - OldCount //Where DD is the Delta of Distance in counts

If DD < -5000 Then DD = DD + RP /*-5000 is a constant to be set so that it will prove that the encoder rolled over backward or moved further than is mechanically possible during this logic scan. RP is the rollover point (don't forget to include zero!) */

If DD > 5000 Then DD = DD - RP /*5000 is a constant to be set so that it will prove that the encoder rolled over forward or moved further than is mechanically possible during this logic scan. RP is the rollover point (don't forget to include zero!) */

For x=0 to CartonsIP //No. of Cartons in process ie/ being tracked
CartonPosition(x) = CartonPosition(x) + DD
//Add logic here inside the loop to set a flag to operate reject or sort mechanism(s) if desired. The loop may be overkill if there can only be a handful of items in process at a time.
Next x

MOV NowCount to OldCount

Zephyr said:

I reset because I am bit shifting every 1000 counts. If I don't reset, how would I detect (and bit shift) every 1000 counts?

Click to expand...

I would have to understand the application more in order to help you determine whether to keep the bitshift logic or perhaps switch to something more versatile, but you can do the math like above to find the delta of the distance travelled every scan and sum it with a separate user variable used for the bit shift logic. You can then reset this user variable without risking missing pulses from the raw HSC accumulator...