# Best practices for capturing Barcode scanner data? **URL:** \ **Category:** Ignition\ **Created:** [January 12, 2016, 7:48pm UTC](https://forum.inductiveautomation.com/t/best-practices-for-capturing-barcode-scanner-data/11033 "2016-01-12T19:48:40Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![karnick](https://avatars.discourse-cdn.com/v4/letter/k/c37758/32.png) [@karnick](https://forum.inductiveautomation.com/u/karnick)\ **Post date:** [January 12, 2016, 7:48pm UTC](https://forum.inductiveautomation.com/t/best-practices-for-capturing-barcode-scanner-data/11033/1 "2016-01-12T19:48:40Z")
My question is more about how to handle a bunch of streaming data on an ethernet network that may be coming into my PLC at an unknown rate. The fact that it is coming from a barcode scanner is somewhat irrelevant. I have PLC logic that is taking string data from a Barcode scanner and placing it into a string called RAW\_INPUT. When this RAW\_INPUT string changes, I push the value into a FIFO (array of Strings) named SCANNER\_FIFO via PLC logic since this signifies a new barcode being scanned. When the array isn’t empty, I turn the DATA\_WAITING bit on in the PLC. I then have a timed Client script that checks the value of the DATA\_WAITING bit every 1000ms. If the DATA\_WAITING bit is on, I write a 1 to the HMI\_DATA\_REQUEST bit in the PLC, which reads the latest barcode string from SCANNER\_FIFO and moves it into BARCODE\_DATA. I then have a tag change script in Ignition monitoring BARCODE\_DATA to perform all the HMI-related operations whenever I see the value change to anything other than an empty string. This is where the storing of the value in a database, updating some counters on the HMI, etc, occur. Basically, my goal of this SCANNER\_FIFO and PLC logic is to queue up the input data (which can be coming at an unknown rate) to present it to my Ignition application in a consistent and controlled manner. When I setup simulation logic in the PLC (for stress-testing) to push a new simulated Barcode value to RAW\_INPUT, I find that out of every 1000 codes being simulated, the HMI tends to “miss” a few. It is definitely better than when I was attempting to monitor the RAW\_INPUT tag for changes directly. I have a special scan class for the trigger and string tags. (Method:direct, slow rate:250ms). My client script is running every 1000ms as mentioned previously, and I have a 500ms dwell built in to the PLC logic that will turn the DATA\_WAITING bit on (it will stay off for 500ms in between “data requests” if there is more than one barcode value available in the FIFO.) I can always increase all my delays and intervals to play it safe, but I want to make sure I am not masking any design flaws in the process of doing that. Please let me know if there is anything I can do to explain this better. Thanks! Some other info: I did not use a Tag Change script on DATA\_WAITING because I was concerned about triggers being missed. If one trigger gets missed (if I don’t see the bit go low in between barcodes), I’ll never be able to trigger the HMI\_DATA\_REQUEST bit, which causes the PLC logic to copy the latest data into BARCODE\_DATA and turn off DATA\_WAITING (until the dwell timer expires) ---
**Author:** ![Tim](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tim/32/3361_2.png) [@Tim](https://forum.inductiveautomation.com/u/Tim)\ **Post date:** [January 13, 2016, 8:15pm UTC](https://forum.inductiveautomation.com/t/best-practices-for-capturing-barcode-scanner-data/11033/2 "2016-01-13T20:15:09Z")
I’m not sure it needs to be as complicated as you’ve described. It may work to run your script as a gateway event script which is triggered off of the change of the RAW\_INPUT tag. If you have your the RAW\_INPUT tag being scanned at a fast rate (\<500ms) then this should work to catch all scans provided they are at least 1 second apart to give your script time to run. See the ‘Tag Event Scripts’ section in the manual for info relating to how five changes can be queued while the script is running. How is the barcode data being transmitted to the PLC from the scanner? ---
**Author:** ![karnick](https://avatars.discourse-cdn.com/v4/letter/k/c37758/32.png) [@karnick](https://forum.inductiveautomation.com/u/karnick)\ **Post date:** [January 14, 2016, 6:48pm UTC](https://forum.inductiveautomation.com/t/best-practices-for-capturing-barcode-scanner-data/11033/3 "2016-01-14T18:48:47Z")
The scanner communicates with the PLC over ethernet. The problem with simply monitoring the RAW\_INPUT tag is that if that tag changes twice before Ignition reads it we will miss barcodes. ---
**Author:** ![Tim](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tim/32/3361_2.png) [@Tim](https://forum.inductiveautomation.com/u/Tim)\ **Post date:** [January 17, 2016, 3:10am UTC](https://forum.inductiveautomation.com/t/best-practices-for-capturing-barcode-scanner-data/11033/4 "2016-01-17T03:10:21Z")
If the scans are coming in less than 1 second intervals I might try moving the scanned data into alternating buffer tags and triggering the tag change script off of each of these tags. ---
**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\ **Post date:** [January 18, 2016, 1:35pm UTC](https://forum.inductiveautomation.com/t/best-practices-for-capturing-barcode-scanner-data/11033/5 "2016-01-18T13:35:53Z")
I like the FIFO idea, but I might have done the flow a bit differently. Incoming Data: –Scan Barcode –Append a 0-9 digit. The first one gets a zero, next next a one, etc, rolling over after 9. This ensures that at least one character is different between scans. –Stick the result into the FIFO. Outgoing Data: – Read from FIFO into whatever location for Ignition to rad it. – After Ignition processes it, send the same string back. When the strings are equal , you know the process is complete. – Rinse, repeat.