Ignition 7.3.3 stops to work with error

Hi,

Yes, that would be caused by the problem I mentioned, that we discovered and fixed for 7.3.5. Please try installing the beta, it should take care of the issue.

Also, a problem like this could lead to the other errors. After updating, let me know if you still get any of the “not enough quota” errors.

Regards,

Hi Colby!

I upgrade to 7.3.5 and after 3 hours have the error “not enough quota”. People wale up me and i need to restart gateway :frowning: . Thread dump attached.
thread-dump.txt (53.5 KB)

Ah, I’m really sorry. It looks like the fix was not included in beta 1. I tried to verify it this morning, and saw that the build was uploaded on the 21st, which was after the update. However, I just checked with the build engineer, and it appears that beta 1 really went up on the 16th, and on the 21st there was just an update to the OEE module. The fix was put in on the 17th. :blush:

So, we’re uploading a beta 2 now. It might take a few hours to become available. I’m sorry for the confusion.

Regards,

Hi Colby!

We update the Ignition to 7.3.5 beta 2 on 6 boxes and main server. Third day - normal flight :slight_smile:
Thanks :slight_smile:

Hi Colby,

As you know we have several external tag providers configured on th main server. We began to notice that some tags with the leased scan class go to stale. The tags which configured with the direct scan class never went to stale, only leased. For this tags (leased) we try to modify scan class to direct and it comes to good quality after several seconds, after we change it back to leased and it begin to work. We have not any errors in console on both tags driven machine and on the main server.

Also we have the second problem. In one of external tags provider we have a tags with the good quality but the tags values does not match the real values (which is on tags driven machine). On tags driven machine we have errors in console which i attached, but the errors stops to come in 19:20, but the tags still have not actual values.



logs[1].bin.gz (252 KB)

Hi,

From that log, it looks like the system is in a state where some tags that have been deleted are still in memory, which caused a problem when the scan class was modified, causing the “lastExec” to stop being updated (while the tags keep working on the driving machine).

Restarting the gateway on each of the driving machines (floor4, for example) should fix the problem for now. I’ve committed a fix for the next 7.3.5 beta that should prevent that problem from happening again, though there may also be something else happening that I missed (I’m not sure the problem with the values is related).

Regards,

Hi Colby!

We reboot the tags driving machines but some tags still comes to stale. I try to modify the scan class for this tags from leased to direct and the tags comes to good quality, and then i change it back to leased and it stay works. Is some ideas to fix it?

This problem only occurs with the tags configured with leased scan classes and only on the main server. I have not seen this problem for direct scan class…

Hi,

I’ll take another look at the logs and see if I can figure out what is happening to the leased scan classes as opposed to the direct ones. If it helps as a workaround for right now, I wanted to point out that you can rapidly change the scan class mode by updating the sqlt_sc table. For example, to set everything to direct:

update sqlt_sc set mode=0, configchange=now()

This will set the scan classes to direct and reload them. For mode, 0=direct, 2=leased.

I’ll see what I can find.

Regards,

Hi Colby!

Today I went to Tetrapak Plant. It is our first Igtition project. We used Ignition 7.2.6. I make some scan class optimization on this plant (changes some direct scan classes to leased) and the system begin comes to deadlock. I upgrade to 7.2.11 and try this version and have the same result. I cant upgrade to 7.3.5 beta becouse the license is for 7.2. What we can do in this case?
thread-dump.txt (36.5 KB)

I tried the 7.3.5 beta 4 and get the deadlock… :frowning:
thread-dump_1.txt (40.2 KB)