"Optimizing imports" error

Ignition
1

Hello!

We recently upgraded to 8.0.5.
And now we observe a strange import error.
When we try to import tags from XML, we get the message “Optimizing imports”, which spins about a minute. After that, the import process fails.

It does not depend on the number of tags imported. The error also occurs for the folder that we just exported from the current project.

What could be the reason for this behavior?

Thank you in advance

1 Like
2

I also see this. I have gotten the same error for different customers, as well as in my own environment.

Even when using notepad.exe for editing simple things like changes in tag path.

Moreover, the ignition server always goes into 100% cpu, and crashes, resulting in a full ignition reboot. This is true for both remote tags providers, as with local ones

Hope this gets solved soon. Difficult to work efficiently when we cant search replace the tag database

3

There was no respond in this thread, so im trying to keep this alive:
http://forum.inductiveautomation.com/t/optimizing-imports-error/28865

I am not sure how many is affected by this.
“tag export” -> “search/replace” -> “tag import” is not working. We have to add all/change all tags manually in ignition 8.0.5rc1.

4

I moved this new post back to the original thread. I have a few questions about the export:

  • Is the export JSON or XML?
  • Is it an export that has a large number of tags?
  • When importing, which collision policy are you using?

Also, if you still have the export that is exhibiting this behavior, can you upload it? Thanks.

5

It is a JSON, and there are in this export it is currently around 30 tags.

I have the same problems with UDTs. Not sure if this specific export has that problem. I have tried both abort and overwrite, samme issue…

I suspect it might be a regional/language setting problem…

.tags.json (41.9 KB)
UDT.json (1.9 KB)

Thanks in advance!

6

I also want to add that the problem does not occur while importing tags into the root folder.
So we are still out of the situation through import to the root and drag and drop.

7

I’m still having issues reproducing, which program were you using to make edits to the export? Also, are the exports you attached from before making edits, or after?

8

The import problem also appears when I import the exported file into the non-root folder without editing

9

Turns out this issue was introduced in 8.0.5-rc1, but fixed for the 8.0.5 stable release. I was testing with the stable release, which is why I wasn’t able to reproduce.

10

Great that it has been fixed. Actually had to hold development for that customer for the time beeing.

Going to upgrade to stable now.

Thanks!

11

I’m seeing a similar issue, where I created a large udt based on a control logix tag, then I substituted the first member’s path motor number with a parameter {MotorNumber} with the UDT editor, then created a tag for this udt and the first member works perfectly with the parameter substitution. But when I export the udt and search/replace the rest of the members path’s motor number with {MotorNumber} and then import, the updated members show bad data, so they don’t seem to like the import. If I opc browse the UDT member’s path, then edit the path, highlight the motor number and select the {} button and select the parameter {MotorNumber} it works perfectly, but I have alot of members and would prefer to do this text substitution with a search/replace in the exported file, then import.

UDT’s Opc item path after opc browse:
nsu=http://www.rockwellautomation.com/OpcUa;s=Slurry#[Slurry]BRKR_401051_0003_SC.Cfg_AlmDriveFaultDelay

Path after using the {} button to sub in Parameter {MotorNumber}: nsu=http://www.rockwellautomation.com/OpcUa;s=Slurry#[Slurry]{MotorNumber}.Cfg_AlmDriveFaultDelay (works perfectly)

Path of next member that I exported/imported and search/replaced BRKR_401051_0003_SC with {MotorNumber}:
nsu=http://www.rockwellautomation.com/OpcUa;s=Slurry#[Slurry]{MotorNumber}.Cfg_AlmDriveFaultEnable (shows bad data, but will work if I do an opc browse, then select the {} key and the parameter {MotorNumber}

Same member after doing an opc browse, then substituting the actual motor number with the parameter button {} :
nsu=http://www.rockwellautomation.com/OpcUa;s=Slurry#[Slurry]{MotorNumber}.Cfg_AlmDriveFaultEnable (shows good data, text looks exactly the same, but works perfectly)

version 8.1.15
windows server 2016
export edited with the Visual Studio Editor ver 1.66.0