I am using Ignition 7.1.8 for a data logging application. Most of the data logs are time based (every 30 seconds or every 5 minutes, etc) and are working just fine. However, three of them are event based and for them I am using polled reads as set up by checking “OPC data mode: Read” on the advanced options window. Unfortunately, these three are storing data from the previous event each time they run. It is like the trigger causes the write of the stored values on the Ignition screen and then it goes ahead and updates the stored values. Whereas it should update the stored values first and then write the data to the database.
I can fix this problem by changing the data mode back to “subscribe” but I thought for an event triggered data log “read” would be better. In the meantime, I am a little leery of the “read” mode.
Any ideas?
Hello,
Are you using Ignition OPC-UA (and if so, which driver), or OPC-COM (with which OPC server)? This does sound very strange- the read mode should be very reliable and should update the values before storing them. If I had to guess I would say that the driver is probably returning the last cached values before then updating the cache, which would be incorrect.
Regards,
I have had the exact same issues with polled. It will bring in the values that are cached and then will update them after it has wrote them to the database. When in subscribe the information is sporadic, sometimes the values are correct sometimes they are from the previous trigger, sometimes part of them update correct and part of them are old data. I seem to have solved this by reading the values directly from the processor with one scan rate and then using a sql tag for the trigger at a different scan rate. This seems to get my data correct when I ask for it. By the way I am getting batch information with this so when the operator releases a batch the values are moved to a holding location in the processor and a trigger is turned on to capture those values. Sorry if I hijacked your thread. This is something that i fought with for some time.
Hi Winspa1-
No problem, you’re not hijacking when it’s the same problem. What does your system look like below the tag level- OPC server and/or driver?
I’ll look into this in depth tomorrow, but more information about your setup might give me a better place to start. The “read” mode is definitely intended for these batch setups, so this is definitely a big bug that we’ll get fixed quickly.
Regards,
We’ve tracked this down and will have it fixed for 7.1.9. We will likely get a dev build up later today. It was indeed a problem in the groups, not the drivers, and was exactly as described- the read value was being latched in after the evaluation, so it would come through with the next evaluation.
Regards,
The 7.1.9-beta2 development build it up and should fix this. I would encourage both of you to try and it out and confirm that everything works as expected. You can download it by going to “Downloads”, getting past the form, and then selecting “Development” from the left hand column.
Regards,
Sorry, I was away for a while. In the meantime, it seems you have nailed it. Thank you.
I am having a similar issue with my polled (read mode) transaction groups using Ignition 7.2.2. My OPC items that are OPC->DB tags, do update after the trigger condition becomes true before the group is written to the database. However, I have some expression items that will write the previous values from the last trigger to the database. The expression items are based on some read-only OPC items. You can actually see this in the designer. After changing the trigger I can see the trigger and the OPC->DB items update their values. Then after my 2-second update rate I see the Read-Only OPC items and their expressions update. I have tried putting the expressions in both the Run-Always section and in the triggered section with the same result.
Thanks.
Jake
When you’re testing, are you starting and stopping the group? I tried to mock up what you described, but I could only get it to happen on the first execution cycle (the first time the trigger went active). After that, everything seemed fine.
At any rate, at least being able to replicate the behavior for one cycle means we should be able to fix it, which will hopefully fix what you’re running into.
Regards,
I am not restarting the group each time. It continues on every trigger, the expression tags are always one cycle behind.
I have an expression tied to a DB field, that is converting a timer.acc value to minutes.
The timer.acc is setup as a read only OPC tag. This timer.acc value and it’s corresponding expression do not update until after the information has been written to the DB.
The regular OPC-DB tags in the group are not one cycle behind. They update when the trigger is active before sending to the database.
Ok. I’ll do some more testing and see what I can find. If you can get away with it, running in subscription mode should avoid the problem for now. I’ll post back when I know something more.
Regards,
Upgrading to 7.2.3 fixed the problem. 
Great, thanks for the update. It must have been something with the opc layer, because after I looked into it further, I couldn’t replicate the case I thought I saw earlier.
Regards,