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.
Can you explain what problems you saw when using READ mode in the transaction groups please? It sounds like READ mode is the mode you want to use in your situation so I’m wondering what the issues you’re seeing with it are.
7.5.1 Using Read Mode
With the DB to OPC Transactions, the first trigger for a serial number resulted in an error “Tried to write value with bad quality” This is using a where clause on the serial number string that is set to read only. The serial number was correct when I viewed the transaction after completion and the next trigger for that serial number worked. For the first trigger it seemed the transaction took place before the serial number (serial number = ’ ') was read even though it was correct and present when I viewed it in the transaction.
With the OPC to DB Transactions, certain tags were missing after the trigger over 50% of the time. Odd that these were the same tags missing each time. Once again this is with a where clause on the serial number string.
I wouldn’t worry too much about the warning on the first execution. This will sometimes happen when the group first starts up. The group will change to a healthy running state after the second execution if it is indeed an issue with getting tag values on initial startup. What is probably happening is on first execution the serial number is has not yet been read so there is no matching record in the DB to bring back. This will only happen on the first group execution.
The second issue is concerning though. You say that the same tags are missing each time the group has an issue running. Is there something special about those tags? What kind of AB PLC are you connected to? Can you also check the diagnostics page of the device in the gateway and post a screen shot so I can see the communication status between the Ignition gateway and the PLC?
Just so we are on the same page, this is with transaction mode set to READ.
This is actually a big problem for us because we don't have the cycle time to check again. Also remember the serial number is different part to part.
[quote="dave.fogle"]Is there something special about those tags?[/quote] Floating Point, and DInts. Same as the other tags that are working
[quote="dave.fogle"]What kind of AB PLC are you connected to?[/quote] CompactLogix L35E.(v20, v19.1, v17) I'll do some testing with a ControlLogix next week if I get some free time.
Here is the dataset for the four parts ran with the station set to read. As you can see the same tags are missing. Checking the update transaction after completion shows a null value was read at the time of trigger. It should at least see a 0.0 if the read actually took place.
29-222600021 123456 27:00.0 0.02 3.84 14.71 -0.06 0.06 0.6 10 14 15.5 0.01 3.61 12.63 -0.06 0.06 0.8 10 12 14
29-222600031 NULL 23:21.4 -0.02 3.88 14.74 NULL NULL NULL NULL NULL NULL -0.04 4.47 12.61 NULL NULL NULL NULL NULL NULL
29-222600041 123456 20:45.1 -0.03 5.18 14.75 -0.06 0.06 0.6 10 14 15.5 -0.03 6.41 12.84 -0.06 0.06 0.8 10 12 14
29-222600051 NULL 15:34.2 0.02 4.55 14.77 NULL NULL NULL NULL NULL NULL 0 6.13 12.58 NULL NULL NULL NULL NULL NULL
I think that it would be best if you called in to our tech support line. We will be able to set up a gotomeeting and take a look at your system first hand that way. Basically READ mode shouldn’t ever be missing any values so it’s a matter of figuring out where the issue really lies. I assume that since you posted a screen shot of our diagnostics page that you are running all these devices through Ignition’s OPC-UA server, yes?
I have the same problem that described here!!!
After copying data, I am delaying it with timer ( twice update rate) then trigger.
But I would prefer a better solution.
I had a chance to do more testing with some timers. On our DB to PLC (checking) transactions set to SUBSCRIBE where I have the 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 fix, I’m seeing a long lag on some triggers. With the transaction set to 500ms, it sometimes will take as high 2000ms to get a response. It appears to be missing data on the first particular scheduled update rate and taking multiple 500ms schedules to get all the data before triggering even though the data was all moved at the same time in the PLC.
This is worrisome because on our update transactions I only have a PLC timer set at the update rate +10% to allow 2 update cycles before the trigger is enabled. This probably explains why our customers are seeing the missing data. Unfortunately I cannot increase the timers without affecting machine cycle times.
I still think that you should be using READ mode. If you would like to call into our tech support line someone here can set up a online meeting so we can take a look at your system and see if we can get to the bottom of this.
We have spent some nice money on Ignition redundancy packages, but their OPC-UA is not reliable enough when compare to RSLINX Gateway.
There is no point of redundancy when I am not even reliably getting data. This is serious for us when using in enterprise level.
One thought just come to my mind, instead of using string and float, I will try it with UDT. UDT is more efficient when sending many packets over the networks. I use them with RSLINX.
BTW, dont bother with testing control logix, mine are all control logix. We dont use cheapo L35E, lol
For us to be able to assist any further with this issue you should call tech support so we can do a go to meeting. This is going to be the easiest way to resolve this problem. The only other alternative, for now, is to try Kepserver or RSLINX and see if this resolves the problem.
But again, I would suggest calling tech support so we can take a look at the system.
[color=#0000FF]Inductive Tech Support[/color]
[color=#FF8000]1-800-266-7798[/color]
[quote=“bachphi”]We have spent some nice money on Ignition redundancy packages, but their OPC-UA is not reliable enough when compare to RSLINX Gateway.
There is no point of redundancy when I am not even reliably getting data. This is serious for us when using in enterprise level.
One thought just come to my mind, instead of using string and float, I will try it with UDT. UDT is more efficient when sending many packets over the networks. I use them with RSLINX.
BTW, dont bother with testing control logix, mine are all control logix. We dont use cheapo L35E, lol[/quote]
How well does RSLINX work with Ignition? Easy to integrate? Anything to be aware of?
The system that I’m programming now has 4 “cheapo” L35E’s and 2 L74’s which I have now seen the problem with all 5 PLC’s without using workarounds or trying READ mode. With the workarounds in place, I have not seen any data loss yet. I have always used UDT’s in my transaction groups, seems to work the same with or without.
Hi James,
If I may ask, what cycle times (including transfer times, if they applies) are you running? An “extra workaround” would be in the use of a FIFO buffer in the plc. The process would put data into the buffer, whilst Ignition would pull it out.
Don’t know how well it would work if you’re checking status at each station before the next process, but may be worth a look.
Hi everyone,
We were able to take a look at the system yesterday. It appears that what is going on is a problem with the SQL Bridge more than device communications.
In short, he is using a dynamic Where Clause to update a row that was inserted by a different group. The where clause references a tag that has the “serial number” to write to. The row has all default null values.
The row update feature of the sql bridge works by reading the row, comparing values, and then updating the values that have changed. The problem is that the Where clause for the read was being generated before the tag values had been updated, meaning it would read the previous row. The Where Clause on the write was fine, but because it had read the old data, any data that was the same wouldn’t be logged.
I’ve emailed him an update to the SQL Bridge module, if it works out, it will be included in the next update (hopefully 7.5.3, but definitely 7.5.4).
Regards,
