Timing Triggers, Handshakes with barcodes stored on PLC

Can someone help me time the tags in this UDT?

Simple UDT:
• barcode: Char array on PLC. It is delivered to this UDT by an expression tag that calls a script to convert the char array into a string.(Does this because Siemens driver cannot serve an entire array in 1 tag...) It uses system.opc.read() to grab each of the characters in 1 function call and then concatenates them and returns it to the expression to display. This is to ensure all the characters are delivered at the same time.

• trigger: set High on PLC when barcode was filled in and is ready to be processed by ignition. Here there is a tag event script that works with the barcode. It eventually turns on the Ack bit.

• Ack: Set high by ignition when the trigger script has finished running and the PLC is safe to delete the data.

My question is, I want to minimize the required time to process from trigger to ack.

Currently I have my tag group for these set to 50 ms. This means each of these tags are being requested from the PLC every 50 ms which is required to ensure the barcode is there when the trigger bit finally comes on. However, every once in a while, it shows up empty. That being said, trig to ack time is 130ms which I am happy with. However, this obviously cannot scale when I add a lot of barcode readers since they will be bogging down the network.

Because the only thing I am really waiting for is that trigger and I am already using system.opc.read() to grab the barcode from an expression running a script, should I instead use system.opc.read() on the barcode tags after the trigger has turned on from within the event script to eliminate wastefully requesting for the barcode over and over?

In my opinion, this is kind of going too far as now everything is in a script, but if I want my trigger to ack time to be as low as possible I feel like this is what I have to do, especially if I don't want to waste network time calling empty barcodes.

LONG STORY SHORT: How are barcode readers typically set up? Are they constantly polling the barcode at twice the rate of the trigger to ensure the barcode is not blank at the time of the trigger or is there a better way to time this?

My application requires a barcode to be scanned, sent to ignition, query a ginormical database and then respond in under 2s. I think I can easily meet this time, but I am worried about network efficiency.

1 Like

Correct, you should never be using a tag event script for anything that polls a db or blocks for a long time. All tag event scripts run in a fixed sized thread pool with 3 threads, and as such should be executing and completing in <10ms at most. Change to using a gateway tag change script instead.

Yes, if you only need it for checking against the db, then there is no need to request the values from the PLC more than necessary. If you do need/want the display, then write the barcode value fetched when processing the trigger to a memory tag in the UDT.

2 Likes