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.
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)