Ignition Versions: 7.2, 7.3, 7.5
Related Software: Windows Server 2008 R2, MS SQL 2008 R2
Let me start off by giving a little background on how we use Ignition’s SQL Bridge and OPC UA. My company designs and builds assembly and test lines. These lines are comprised of multiple stations. The parts that are being assembled or tested have serialized barcodes or RFID tags. These serial numbers are used to check the status of the part before performing its cycle and then updating the information in the database at the end of the cycle.
For the checking part of the procedure we used a read only trigger that is commonly shown in your training videos and demos and the read only serial number (string format). The database responds with the pass/fail, part type, and last station information stored in the database. In the PLC (AB) code we copy the serial number then set the trigger to a 1 (practically simultaneously) and wait for the transaction verification to set it back to a 0 after evaluation. This works great about 99% of the time. The problem is we are seeing transactions taking place before the serial number tag is updated. The workaround we found is to create a run-always expression that makes sure the data is present in the serial number along with the trigger tag and then trigger the transaction from that run-always expression. The updating is much more difficult to do because it is not easy or practical to make sure all the data is present before the transaction is triggered. This leaves us programming in timers into PLC logic after we move the data into the evaluation tags before setting the trigger tag. The timer usually is set to the same rate of the transaction update rate. This is not practical because in some instances the machine looks like it just pauses for a second or two then proceeds. Not good when each second the machine is not running customers see money lost.
We’ve seen this problem with all versions of Ignition and as of right now we have 5 systems in place with this problem. We use high end Dell servers with just the OS, SQL, and Ignition on them so I’m not worried about the PC side. Be aware though that everything is moving to Ethernet in the industrial controls world so the communications is usually heavy although the monitoring software shows the Ethernet communications are way below the max thresholds.
I’ve got a theory on the problem. Suppose sometimes the trigger tag is in one packet of Ethernet data and the other evaluation tags are in another. The OPC updates the tag so fast and that the transaction sees it and triggers while the other tags are still updating. Remember that this problem only happens less than 1% of the time. If this is the case I think buffering all the tag data read at a scheduled update rate, then update the OPC tags to use throughout Ignition.
By the way I tried using READ mode instead of SUBSCRIBED and I get all kinds of problems (v7.3). I also tried hours of continuous testing and found problems with various tags values missing at the point of triggering unless work-a-rounds were used. I havent had time to do extensive testing with 7.5.1 yet, but I have seen the problem with it.
I saw this problem pop up in a couple of other threads where timers and work-a-rounds were used. I know from experience RSLinx and RSSQL don’t exhibit these issues, but I think Ignition is much more superior product and this is something that needs to put to rest.