Critical UDT Issues, History Issues

Ignition Early Access
1

Hi everyone,

I’d like to report several issues that we have encountered on our projects, just to have a place to know where to look for updates before and after 8.0 is released.

Feel free to ask for clarification on any of these if needed.

  1. Instances of UDT’s sometimes do not contain all tags that exist in the UDT definition. The UDT instances are sometimes missing random tags, but not all of them. Re-starting the UDT instance does not fix the problem, but deleting and remaking the instance does work.
    We could script out a function to store all the attributes, parameters, and overrides present and have it go through each UDT and re-make each, but this is not a great long-term solution.

  2. In some cases, expression tags have to be restarted so that the expression actually takes effect. Restarting the gateway does not help. The tag itself has to be restarted.

  3. The tag() expression function does not seem to work as expected some times.

  4. Storage of tag history is intermittent. I have found that all tags do end up in the sqlth_te database table, but most somehow do not get triggered to enter the partitioned database history tables. This is preventing trending. We are seeing issues in the Ignition gateway logger that is essentially telling us that these tags, which are supposedly being historized, are in fact not found. This is related to bug #13267 and #13040 (the latter may have been marked fixed, but doesn’t seem to be.)

  5. Dataset tags don’t always save cell updates in the tag editor. Some times, when editing a dataset tag cell, that cell just won’t update. It might be a failure to hit enter/confirm/apply, but I feel like this is too much, forgetting to do only one of these causes any changes to be lost. More irritating than critical.

Are there any associated open case #'s with any of these bugs?

Cheers,
Roger

2

Hi,

I’ll have to look into these to see what tickets currently exist.

Questions:

  1. What type of actions seem to lead to this? Is it after an edit to the parent type? Does it persist across restarts of the gateway? I doubt, but if so, it might be useful for us to look at your internal db.

  2. It sounds like these are expressions that are not generating new values on their own? That is, many expressions have poll rates that drive when they generate values. Executing based on this is the new default. I’m trying to figure out if somehow the first value isn’t getting published correctly.

  3. Where is the tag() function being used? In another tag expression, or in a client? Does it just seem to fail with bad quality?

  4. 13267 is related to remote history storage- in your case, is that what you’re using, or is this problem happening with a local db connection?

  5. So you’re saying you click, edit, and then do whatever, and the value is lost… OR, you edit, and it seems to be in there, but somehow doesn’t make it to gateway? (I’m asking because we’ve had a category of editing issue where the editor just doesn’t think there have been any changes to save)

Thanks.

3

Hi Colby, good to hear from you!

It happens in two ways in my experience:

  1. As you mention, editing a UDT data type (parent of the instances) does not always propagate through all of the instances, so some end up with missing tags.
  2. I've found that some UDT instances are simply missing about 60-70% of the tags that should exist for them. Other instances of the same UDT are perfectly fine, and still some others are missing more/fewer tags. It seems inconsistent and doesn't seem to be triggered by anything in particular, so I have no way of knowing what possible actions cause it.

We've restarted the gateway service a few times, but not to solve this specifically. However, it seems to have survived the gateway restart as some of these UDTs have not been touched. I could be wrong about that as it's been awhile since we did a gateway restart.

I think you may have nailed it, it doesn't seem like certain expressions evaluate properly the first time, or even get triggered to evaluate.

It tends to fail with an expression error. We had these expressions working in 7.9.10 before we ported our project over to 8.0. I'm not familiar with the exact circumstances, but I'll get my associate to detail this more for us.

This is happening with our local db connection. We have a SQL Server 2016 hooked up and 4 database connections, in addition to a 5th Oracle db connection. All of our tag groups are pointed at "Default" so I don't know if it has a limit (I assume no, but I assume there is a suggested threshold to swap to different tag groups), but only a few items are being historized. I can't identify what is stopping the historization, in the tag editor, everything seems to be in order, unless I'm missing a critical new step that was not in Ignition 7. We're about to move over to remote tag providers, so I assume this will be an even bigger issue then.

The former - the value is completely lost. I have to hit enter, hit confirm, hit apply, then ok. Even then, I feel like sometimes it failed to save, but that generally works. Missing one or more of these actions potentially causes loss of the saved data. Generally i've only been editing one cell at a time, so not a huge deal right now, but those editing requirements seem a little stringent. Maybe a confirmation box letting us know we aren't actually saving it?

The latter, when the editor accepts the value but doesn't update it, I have only encountered in the client, specifically when navigation templates deal with dataset tags. Restarting the client fixes that issue though. The gateway seems to have accepted most if not all of our changes, once pushed through!

Thanks for the reply, if you need more info feel free to post here and request it!

4

The issues we had with the tag() function were generally on expression bindings that were referencing tag properties within the tag() function. All of the instances where the tag() function was causing an issue had been replaced with workarounds. Today, in a VM with a recent (within the last week) nightly build of the 8.0 beta installed, I tested some of the common expressions that had stopped working when we initially updated this project from 7.9.10 to 8.0. I was not able to recreate any of the errors I had gotten previously. It could be possible that whatever was causing this issue was resolved in a nightly build since we converted to 8.0?

1 Like
5

Hard to say precisely, but it's definitely possible. We've made many small fixes in the last few weeks.