Scan time, anti-aliasing, and the Nyquist frequency

[Starbot1]

Hi all,

I currently have a rejection conveyor belt with 4 lanes and with 1 paddle per lane to sort the quality of a particular agricultural product. The quality is sorted by machine learning on a stereo Basler setup. Anyway, the vision system outputs an array of values into Modbus registers, one pair each for each rejected sample on the belt (in camera frame). About 20 objects max would be detected per frame.

The vision system is fast-- 15fps segmentation. I have a bit of Matlab on top that takes 300ms by design, including that original machine learning/vision analysis (takes a segmented image, evaluates it a bit, and writes the modbus registers).

The belt is moving at 140mm/s, with an encoder wheel traveling along top. Encoder is 100ppr, and so with the wheel it is producing a 70Hz signal (14.28ms pulse width I think) with a resolution of 2mm/pulse, which is about what is required. It is on a high speed counter on a CLICK plus PLC.

My scan times are 2ms on average, increasing to 8-9ms at a maximum when an image is captured, particularly if 20 rejects are in frame and the for loop must iterate 20 times through the registers. Performance now is excellent, versus moderately successful at a peak scan of 22ms before optimization.

My question is, am I aliasing the shift register output, causing missed or late rejections at the paddles. I'm thinking I need to get under the Nyquist frequency of 1/2 my encoder pulse width (thus the width or length of the shift register output bit). So, under 7.6ms. Am I aliasing data by having cycle times close to 9ms? Or am I missing something else, perhaps. Statistically, we are doing better since reducing scan times.

 

[V0N_hydro]

slow the conveyor down and you will get your answer?

 

[Starbot1]

slow the conveyor down and you will get your answer?

Sorry I should say in our facility we have very little fresh produce to test with unfortunately. So I need to figure out possible sources of errors and wondering if this is one. Our error rate is maybe 5% missed product. The paddles stay down for 450ms and the product takes about half that to pass, with a bit of buffer on each side.

 

[drbitboy]

what does the duty cycle of the pulses look like?

2mm/pulse ÷ 140mm/s is 0.0143s or 14.3ms/pulse as you thought, but I think that includes both rising and falling edges, and you need to see both, so ~7ms/edge at 50% duty cycle, and even less if not 50%.

 

[Starbot1]

You are right, Dr. I believe 50% it is a quadrature encoder and I am looking at just the A output. So do I need to get cycles under ~3.5ms to prevent aliasing?

what does the duty cycle of the pulses look like?

2mm/pulse ÷ 140mm/s is 0.0143s or 14.3ms/pulse as you thought, but I think that includes both rising and falling edges, and you need to see both, so ~7ms/edge at 50% duty cycle, and even less if not 50%.

 

[drbitboy]

I would think 5-6ms would do it; presumably it will pick up an edge on one scan.

Does it have to process all 20 iterations in one scan? Maybe it could do one iteration per scan when there are iterations to do.

 

[Starbot1]

Thanks again. There are some good answers and suggestions over on Reddit, too: https://www.reddit.com/r/PLC/comments/tdjeds/scan_time_antialiasing_and_the_nyquist_frequency/

I suppose no it may not have to process every scan but I'd need a way to offset the bits by the number of scans that have passed since the first calculation so that I am not introducing a timing error.

I would think 5-6ms would do it; presumably it will pick up an edge on one scan.

Does it have to process all 20 iterations in one scan? Maybe it could do one iteration per scan when there are iterations to do.

 

[drbitboy]

Are you pushing bits onto a bit shift register, and either reading them at the paddles or popping them off, using a Bit-Shift-Left or Bit-Shift-Right instruction or similar?

Assuming yes, to handle multiple counts in the PLC, you would need to have the code keep a shadow accumulator value of the counter accumulated value.

So say both counter accum and its shadow are both 0, and then a read on a later scan of the counter accum says it is now 1. So you push a 0 or 1 onto the bit shift register and increment the shadow accum by 1 to a value of 1.

Then on a later scan the counter accum jumps to 4 i.e. three pulses were counted since the previous scan. So you push a 0 or 1 onto the bits shift register and increment the shadow accum from 1 to 2, but since the shadow accum has not reached the counter accum, you push another bit and increment the shadow accum again i.e. to 3, then once more push a bit and increment shadow accum to 4, and finally stop there because the shadow accum has caught up to the counter accum.

You'll have to deal with rollover of course, but the real problem is the bit-shift-left/right instruction: it probably pushes the new bit on a rising edge of its input, and there is normally only one rising edge per scan. On Allen-Bradley BSR/BSL instructions you can clear the .EN bit to re-arm the edge detection.

It might be easier to do this with a circular bit register where the indices "shift" instead of the bits and the bits stay stationary, but then the code needs to handle the whole enchilada: edge detection; paddle index; rollover; etc. Although edge detection becomes simply counter_accum<>shadow_accum.