Building a data driven barcode display to be read with laser barcode reader

I need to create a tiny system that will take data and display it as a barcode so that a wired, bluetooth, or WiFi barcode reader can pick up my data.

I currently have 2 use cases:

  1. Query an older digital shipping scale using RS-232 and display the weight. (This will be in addition to the existing 3-digit LED display on the scale controller. The barcode will be scanned instead of the weight being typed into the scanner or screen manually.)
  2. Count mechanical steps from an old industrial fabric rolling/folding machine and display the length in yards and 1/8th of yards. (This will be replacing a mechanical counter currently on the machines. The user will scan the display instead of manually writing the length on a label and later recording it in the ERP system. As soon as we can scan the length, we will start printing labels for packages with the length on them, eliminating the 2 manual steps of writing on the label and entering into the system.)

Both of these use cases are because the ERP software that wants the data is getting information from portable WiFi scanners, a custom interface program on a PC, or a web page, all of which connect to the ERP system via network. None of these methods has the ability to poll devices for data. Barcodes, on the other hand, present their data to the applications as if the operator typed it in and therefore require no special interfaces while still guarantying that data captured is accurate.

Use case 1 is a turn on and forget (endless loop requesting weight from the scale controller).
Use case 2 requires a counter reset button. Not a problem to implement.

I’m thinking that I can do this with an E-paper display and one of the small Arduino boards. I have already found a free barcode 39 true type font and there seems to be software to display true type fonts using the Arduinos. I already have a Mega 2560 that I'm planing on using for prototyping. Should I be able to get the final version of the software into one of the smaller format, less expensive Arduino boards?

I’m thinking the e-paper display (2.7”) as it should be readable with a laser barcode scanner. Since the display requires an external light source (the scanner laser) and not being an actively refreshed display there should not be any problems scanning it. Has anyone already done something like this? Has anyone tried a laser scanner with e-paper or other displays?

In use, the operator will scan the barcode instead of manually typing in the weight/length.

I’d appreciate any suggestions on actually implementing this and feedback on what I’m planning. When all is said and done, I’ll probably need 3-4 scale interfaces and around 30 rolling machine interfaces.

Thanks for taking the time to read this and any comments you leave.

Sounds good but you should check that before further steps.

After all I don't understand where the barcode comes from. Why can't you transfer the data via BT or other means instead producing a temporary barcode? If the barcode is required further why not print it on a label?

Probably.

Seems like there’s somethings to be found on the internets about that.

I am envious that this is what you are supposed to be doing. Sounds like fun.

a7

I would expect an LCD display to be much cheaper than an e-paper display. You don't need a fancy TrueType font since it's just vertical bars. Each character takes up 12 to 16 pixels (the three 'wide' bars can be 2x to 3x the width of narrow bars).

How many characters do you need to display? Add two for the start and stop symbols. Multiply by 16 to get the display width in pixels.

Scale -> RS232 LS -> UART Rx -> 32u4 or SAMD -> USB -> PC

Instead of using a display and barcode reader, put a Leonardo, Micro, Pro Micro, or MKR (all have 32u4 or SAMD CPUs) between the scale and PC. All these boards have UART Rx/Tx and hardware USB. Add a RS232 level shifter. If the barcode readers are emulating USB keyboards, some Arduino boards can also do the same.

The barcode will be generated either by reading an RS-232 port on an old digital scale, then converting the weight read, or from counting the steps on an existing conversion machine, converting the steps to a length, then the length to a barcode.

The barcodes are to provide input to the ERP system for billing and inventory tracking. These weights and measures are being tied to shipping documents that are paper documents with barcodes already. The documents are being scanned at various points in the picking/packing/shipping process and this is to acquire data that is otherwise manually entered after being written down. Becuase of the mix of devices being used, barcodes are the easiest, most reliable way to capture the information as at every point we want this data, a barcode reader of some type is already being used.

It's a proof of concept at the moment. I've suggested it to management as we implement more accurate tracking of time to perform operations that are involved in our conversion processes and to more accurately capture the data for shipping product. The number of mistakes made in getting weight data into our ERP is surprisingly high. And hand writring the length of material on each unit after conversion looks unprofessional and takes more time.

I'll be working on this with my son and if we can make it work, then my employeer will probaly pay us to make the units we need in-house. If we can't make it work, we then my son and I got to spend some time on an interesting prioject. I love messing with hardware and have been doing so since just after the original Altair 8800 kits came out in the 70s.

+1

The onl;y reason for the true type font is to save having to figure out the font characteristics (I'm lazy...).
The weight will be limited to 3 digits, no fractions. (UPS, FedEx, and LTL shippers always round up to the nearrest pound.)
The length will be a fixed 6 digits with an implied 3 decimal places. Allowing for a maximum of 999.999 yards. The maximum starting length is actually under 200 yards, but they measure and bill in 1/8 yard increments, so I need .125, .250, .375, ... in the barcode. The application side of the ERP system will put in the decimal point so it keeps the display shorter.

I've got 2 displays to try, and with the information you supplied, I'll need a maximum width of 128 pixels (6 digits + 2 guard characters in code 3 of 9). This should fit in either of the displays I've got for testing (250x122 & 256x128).

Sadly, I do not have a PC at most of the locations where I need the devices. In some cases there are small, portable tablets with wired or wireless barcode readers, and in other cases they are using intelligent WiFi based barcode scanners (such as Symbol MC3000 or MC9000 family devices).

I'd like to keep it simple and not have to create multiple versions based on where the unit is and what happens to be there today to read the data. The one constant is that, no matter what they are doing, they will have some form of barcode reader that can pass the data to the server based applications system.

I didn't say it yet, but thank you all for responding! I appreciate the feedback and ideas so far and I'll probably look into a LCD display as well depending on how things go.

I will continue to look forward to the invaluable insites that forum members have and I'll update as the project progresses.

Here are some pictures of the counters I am attempting to replace. The first gotcha is that the counters actually will go backwards, so I have to allow for direction as well as pulses with counting. I am going to find out if we could just hookup to the steel roller with rubber pressure roller, then I could probably use a rotary encoder. More research is needed on these old pieces of equipment.





Here is an actual look at the workspace and very poor access to the counter reset lever.

If a rotary encoder is too hard, you could look at a reflective sensor on almost any moving part of the rolling mechanism.

Just spitballin',

Possibly some OCR software could read and decode the numerals directly into your application.  Just take a picture with a smartphone and - bada bing!

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.