Historical file download timeout error

I have a tag that is consistently giving me timeout errors when I try to download or view the file contents. The error message reads:

flexyError

This happens to be the last tag I defined, and I am not having any other issues with other logged tags. I can delete the tag and then recreate it, and the issue is temporarily resolved, but then reappears later.

The tag is setup to log every second. Is this a memory/storage issue?
Below is the tag configuration.

eWON Type: Flexy (FLEXY20100_00)
Firmware Version: 12.3s1PR

Any help would be appreciated.

@Scott_McKinney

Any chance you could provide me a temporary login to this hardware?

Sure.

Unfortunately, I just deleted/recreated the tag, so it is working as expected currently.

CREDENTIALS MOVED TO STAFF NOTE

@Scott_McKinney

Would it be possible to keep an eye on it and let me know when it goes into that state? I need to check it when it is in an error state.

OK, I will send an email when it reoccurs.

Thanks for your help.

Sounds good.

I will keep my eyes open for an update.

OK, it’s throwing the error again. It’s been almost exactly 2 hours since I reset the tag.

Have you had a chance to login to the flexy to investigate?

Hi @Scott_McKinney

I was able to do some checking here and determined this is not an issue on your end. There is actually an issue in the firmware preventing the generation of this log file when it gets too large.

Development is aware of this issue and is actively working to find a resolution. Unfortunately however I cannot say exactly when this fix will be pushed to production. I can however say that emailing or exporting the file via an export block descriptor should continue to work. It is only the actions on the webpage that will pose an issue.

Essentially what happens is you have so many tags logging and so much data that the eWON is trying to go back in time to parse which records you need. However, before this action can be completed the unit times out.

I will continue to update this thread as soon as I have further information on a final resolution.

Your answer implies that reducing the number of tags being logged might help (by reducing the load on the processor). Is this correct? Many of the tags being logged are on by default and are not required to be logged by our process. If I reduce the logged tag count, will this result in a longer time window in the 1-second resolution tag?

@Scott_McKinney

This is possible. Reducing the number of tags could help however I cannot guarantee that it will fully alleviate the issue until it is patched in the firmware. By reducing the number of tags you are reducing the number of records that must be checked which could in turn reduce the processing time for a singular tag.