In contrast to the area scan mode, the block scan mode enables round or rotating bodies or long or endless materials to be inspected at high speed (similar to line scan cameras). For this purpose, the block scan mode records an area of interest (AOI) block consisting of several lines. An adjustable number of AOI blocks are then transmitted together as an overall image. This minimizes the overhead that would otherwise occur when transferring the AOI blocks as individual images using the USB3 or GigE Vision transfer protocol. This document shows how to work with the block scan mode in conjunction with BVS CA-SF2 industrial cameras with IMX global shutter sensors from Sony. Here, the industrial camera is triggered in block scan mode by an incremental encoder to capture objects on a rotating drum.

Of course, other hardware triggers (for example next to a conveyor belt) or software triggers also work as a source. In this case, "EncoderControl" is not required and "TriggerSource" must be adapted. In this document, however, an incremental encoder is used as the trigger source.

The following points are covered in this document:

1. How is the block scan mode configured in conjunction with an incremental encoder in ImpactControlCenter?

2. How is an endless image captured on a rotating object?

3. What happens if a rotating object stops and there are still image blocks in the image memory?

4. What happens if a rotating object changes direction and then rotates back in the original direction?

5. What are the line rates for

   1. BVS CA-SF2-0032ZG/C

   2. BVS CA-SF2-0051ZG/C

   3. BVS CA-SF2-0089ZG/C

6. What are the advantages of the block scan mode compared to a line scan camera?

7. What are the disadvantages of block scan mode compared to a line scan camera?

Materials:

• 1 x rotating drum with motor

• 1 x measuring tape

• 1 x incremental encoder (1000ppr)

• 1 x camera (BVS CA-SF2-0032ZC)

• 1 x light source; 1 x trigger box

The rotating drum is connected to a motor and an incremental encoder. A measuring tape is attached to the surface so that the distances can be read off (see picture above left). The incremental encoder and the light source are connected to a trigger box via the camera's I/Os. (Encoder) Source A → (Camera) Line 4; (Encoder) Source B → (Camera) Line 5.

Figure1: Mechanical structure

Figure2: Wiring

Erforderliche Firmware-Version: > 2.35

Konfigurationsschritte in ImpactControlCenter:

1. Setting → Base → Camera → GenICam → DeviceControl → DeviceScanType: mvBlockScan.

2. Setting → Base → Camera → GenICam → ImageFormatControl: configure OffsetY, mvBlockscanLinesPerBlock(>= 16), mvBlockscanBlockCount(>= 2).

3. Setting → Base → Camera → GenICam → ImageFormatControl → PixelFormat: BayerRG8 (für Farbkameras).

4. Setting → Base → Camera → GenICam → EncoderControl → EncoderSourceA: Line4; EncoderSourceB: Line5; EncoderDivider: 1; EncoderOutputMode: PositionDown/DirectionDown.

5. Setting → Base → Camera → GenICam → AcquisitionControl → TriggerSelector: FrameStart; TriggerMode: On; TriggerSource: Encoder0.

6. Setting → Base → Camera → GenICam → AcquisitionControl → ExposureTime.

7. Setting → Base → Camera → GenICam → DigitalIOControl → LineSelector: der Ausgang, an welchem die Lichtquelle angeschlossen ist; LineSource: ExposureActive.

8. (optional) Setting → Base → Camera → GenICam → DigitalIOControl → debounce time für Line4 und Line5 setzen

After a certain distance has been traveled, the incremental encoder generates a pulse. Each pulse (if encoder divider = 1) triggers the recording of a number of image blocks, which are then combined to form an overall image. The following sketch shows the cross-section of the inspection system.

Figure 3: Cross-section of the inspection system

If a new trigger pulse is generated, the drum has rotated further by the angle α, which covers the circumference ΔC. Since r is the radius of the drum, n the encoder divider, which specifies the number of incremental pulses, and p the incremental pulses (ppr: pulse per revolution), ΔC can be determined from this:

ΔC = 2*π*r*n/p (eq-1)

In order for an endless image to be generated from the different blocks (y1', y2'......), the height of the field of view of each block must be identical to ΔC:

y1 = y2 = ΔC (eq-2)

Figure 4: Rotation until the next trigger pulse

Since a tape measure is used as the object in our example, the height of the object y(mm) and the corresponding image height y'(pixels) can be easily read off. This means that the image scale of the lens β (pixels/mm) can also be easily determined:

β = y'/y (eq-3)

If all three formulas eq-1, eq-2 and eq-3 are combined, the required lines per block (y1' or y2') value can be extracted for continuous images in this system:

LinesPerBlock = (2*π*r*β/p)*n (eq-4)

The calculation has been confirmed. In the setup, a correct endless image is generated with EncoderDivider in ImpactControlCenter = 3 and LinesPerBlock = 20. The test result looks as follows.

Figure 5: Correct endless image

If LinesPerBlock is set too low, the generated image will have gaps (see image below left). If LinesPerBlock is set too high, there will be overlaps in the image (see image below right).

Figure 6: Gaps and overlaps in the image

If a lower lines per block (e.g. 16) is required in other applications, then β and n must be adjusted in order to obtain a suitable continuous image:

β= (LinesPerBlock*p/(2*π*r))*(1/n) (eq-5) (derived from eq-4)

Since β can be roughly calculated using the Gaussian formula β = |f'/(f'-S)|, β can in turn be varied by adjusting the focal length f' and the working distance S.

In this example, the object is moving upwards as seen from the camera. If the camera were mounted on the other side of the drum, the object would move downwards, although the direction of rotation of the drum would not have changed. The incremental encoder would continue to count downwards and the following image would result.

Figure 7: Incorrect sequence of the joined blocks

The blocks are clearly joined in the wrong order. This can be corrected by mirroring the individual blocks.

• Setting → Base → Camera → GenICam → ImageFormatControl → ReverseX

• Setting → Base → Camera → GenICam → ImageFormatControl → ReverseY

The resulting image is inverted and does not correspond to reality, which could be problematic for some applications. For this reason, we recommend that the camera is positioned so that the object moves upwards in relation to the sensor.

Figure 8: Inverted order of the merged blocks

During acquisition, the sensor continuously sends image blocks to the FPGA, which combines the blocks into a frame/image until the specified block count is reached. The complete frame/image is then stored in the driver's image memory. If the rotation is stopped, image blocks remain in the FPGA. If these blocks are not deleted, further blocks are added to them until the frame/image is complete. This results in an image consisting of two different objects, which is not desirable. For this reason, Abort in ImpactControlCenter or imageRequestReset should be called by our SDK before starting an inspection with a new object to discard the incomplete frame in the FPGA.

The Abort call requires approx. 200 µs if the host is not overloaded.

Our firmware supports 3 encoder output modes: position up/down, direction up/down, motion.

-> Documentation: Encoder Output Modes

A graphical explanation looks like this:

Figure 9: Encoder output modes

As soon as position up/down is selected, the image is stopped as soon as the direction of rotation changes. If the drum rotates in the original direction again, the next blocks are correctly appended to the position of the stop. This means that the recording is not affected by a change of direction. Our test has confirmed this.

Figure 10: Correct image even after a change of direction

• [1] Max. Exposure time (µs) @ 16 lines/block (kHz) can be observed as soon as mvAcquisitionFrameRateLimitMode is set to mvDeviceMaxSensorThroughput.

• [2] Max. Exposure time (µs) @ 16 lines/block (kHz) can also be calculated using 1/BlockRate - tp, where tp is the time between two adjacent exposure times where no trigger may occur. tp for BVS CA-SF2-0032Z, BVS CA-SF2-0051Z and BVS CA-SF2-0089Z is 86.5 µs, 102 µs and 229.5 µs respectively.

• [3] Block rate (kHz) @ n lines/block (kHz) = 1s / (readout time for n lines + readout time for vertical blank lines). For BVS CA-SF2-0032Z, BVS CA-SF2-0051Z and BVS CA-SF2-0089Z, the readout time for vertical blank lines is 190 µs, 220 µs and 509 µs.

1. Standard interface: USB3 Vision and GigE Vision in contrast to CoaXPress and CameraLink.

2. Simplified system setup: Since the camera can also be used as an area scan camera, it is much easier to adjust the focus to get a sharp image.

3. Less block losses due to the FPGA in the camera.

4. Less load on the host: Blocks are collected in the camera.

5. Cheaper than line scan cameras (at the same line rate).

1. Endless images require an exact calculation for each new application.

2. The aspect ratio (height to width ratio) must always be 1:1 in order to avoid periodic distortions in the Y-direction of the resulting image (in contrast to line scan cameras, where any aspect ratio is possible).

3. For this reason, optics and timings must be carefully adjusted for each application.

4. Min. lines/block = 16.

5. The smallest increase/decrease increment of the block count is 4. The block count can therefore only be 16, 20, 24, 28, 32 etc.

6. Both input lines of the camera are occupied by the incremental encoder. Therefore, no other hardware trigger (e.g. a light barrier) can be connected.