4.6 C
New York
Friday, February 28, 2025

Barcode capture in an automated production line


Capturing the barcodes on a device under test (DUT) is easy when you are scanning it manually with a handheld scanner. You decide where to point the barcode reader and when to trigger the scan. There is no problem at all to capture multiple barcodes on a multi-DUT panel since you are scanning each one manually. However, in an automated production line, the systems or test handlers on the line will be the ones doing the barcode captures. You lose the flexibility to move the barcode reader wherever you like and the judgement of when to trigger the capture. Automated production lines set up barcode readers at specific positions and have them controlled by the systems to perform the capture. This restricts each barcode reader’s field of view to a particular area on the DUT, and it is not possible to capture all barcodes on a multi-DUT panel. My earlier post on Creating barcodes for panelized boards in PTEM shares a barcode generation feature that is available with Pathwave Test Executive for Manufacturing (PTEM) software that automatically generates the barcodes on multi-DUT panel using the first captured barcode.

Automated inline handlers like those for the Keysight i7090 have a programmable logic controller (PLC) that manages the handling of the DUT in and out of the system. The PLC does not take care of any barcode capture but allows you to insert your own test steps in between its handling sequences to capture the barcodes on the incoming DUT. In certain cases, you may capture the DUT’s barcode before it begins its transfer into the handler and in other cases, you may need to capture it only when the DUT is in the handler. PTEM provides the test steps to control the handler operations and barcode readers. Using PTEM, you can develop a testplan that incorporates barcode capture sequences as part of the handler operation sequence.

Link conveyors connect the manufacturing systems to form the automated production line. DUTs flowing along the production line can stop momentarily at the link conveyor before entering the systems. This momentarily stationary status is an ideal position for the system to trigger a capture of the barcode of the DUT. This is known as upstream barcode scanning. In this setup, the link conveyor upstream of the test handler holds the barcode reader and the testplan on the handler controls the barcode reader to capture the barcode before the transfer begins. However, a typical transfer operation does not wait for the testplan to complete the barcode capture. Once the upstream conveyor detects the DUT, it signals to the handler that it is ready for the transfer. If the handler is not busy, it responds by signaling that it is ready to receive, and the transfer takes place at once. To allow time for the testplan to perform the capture, the handling sequence must wait for the testplan before responding to the upstream conveyor to start the transfer.

In another scenario, a production line may not have link conveyors in between the machines to reduce the overall footprint of the production line and save operational costs. In this case, there is no upstream conveyor to install the barcode reader, so instead, we install them inside the handler and do the capture only after the DUT arrives in the handler. This is in-system scanning. The handler receives the DUT and moves it to the stopper position in the handler. At this point, the handler pauses and waits for the testplan to perform the capture before engaging the DUT down to the test fixture.

The Keysight i7090 automated inline handler system supports both upstream and in-system scanning methods with two test steps to check the status of the DUT before instructing the handler to go ahead with the transfer sequence.

Upstream scanning

When the DUT arrives at the upstream conveyor, the conveyor signals to the handler that the DUT is available for transfer. Upon detection of the DUT availability, the i7090 handler sets a register bit in its PLC and waits for the testplan to respond. The testplan queries the register bit from the handler using the Handler_IsBarcodeReadytoScan command as shown in Figure1. The test step returns a Boolean value to the repeat loop. When the DUT is in position upstream, Handler_IsBarcodeReadyToScan returns a true value which satisfies the condition of the repeat loop and testplan exits the loop to make the capture of the barcode.

A screenshot of a computer Description automatically generated

Figure1: Testplan waits for DUT to be ready before capturing barcode.

In-system scanning

For a barcode capture to take place in the system, the i7090 handler allows the upstream conveyor to transfer the DUT once it is available. The handler moves the DUT to the stopper position and pauses to wait for testplan. Like the upstream scanning, the PLC sets the register bit once the DUT is in position at the stopper. The testplan uses the same set of test steps to query Handler_IsBarcodeReadyToScan. The same test sequence in the testplan works for both upstream and in-system scan. The only difference is the point of time in which the testplan triggers the barcode reader to make the capture.

Capturing the barcode

Barcode readers usually come in serial communication (COM) or local area network (LAN) interfaces. These are supported by the PTEM test steps as Serial Port or Socket instruments respectively as in Figure2.

A screenshot of a computer Description automatically generated

Figure2: PTEM supports Serial port and Socket protocols for barcode readers.

In Figure 3, the testplan sends the trigger command to the barcode reader and reads back the captured value accordingly. A verification then occurs to ensure that the captured value is of the expected format and the DUT is legitimate for testing in this station. In case of any irregularities, the testplan can stop and report an error. If everything is in order, the testplan proceeds to assign the value to the DUT and sends the Handler_SetBarcodeResult test step to the handler with a checked result box. This shows that testplan successfully captures, verifies, and assigns the barcode for the DUT and the test cycle can continue.

A screenshot of a computer Description automatically generated

Figure3: Testplan sends Handler_SetBarcodeResult to handler after successful capture.

The testplan proceeds to send the commands to engage the DUT into the test fixture and continue with the tests. Upon completion of all test operations, the handler releases and transfers the DUT downstream and waits for the next DUT to be available. In the testplan, the test flow loops back to the capture barcode step with the testplan querying the Handler_IsBarcodeReadyToScan to get ready for the next capture.

For more details on the commands and sequences for the control of the i7090 handler, you can refer to my earlier posts on Keysight i7090 with PTEM-Auto Mode. Also check out the series of posts on test automation with Keysight i7090 using PTEM to find out more.

You are welcome to contact me if you have any questions or comments.

Stay safe and happy.

[email protected]



Source link

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles