Error 1105: Unknown or unexpected XML tag

[dest2ko]

Is there a way to get more details onto which tag in the XML file is causing the issue? Surely there's more information. I am getting it coming out of the read XML file. This data was flattened using only LabVIEW-based XML flatten functions. The data that I flatten when I save the files is type defined, a custom blend of clusters, arrays and other typedefs that I've organized data into, and it is of course always unflattened in accordance with this type.  

Thanks, 

[ben64]

If your data contains special characters such as " you need to use the Escape XML and Unescape XML VIs before writing and reading to/from XML.

I can't think of direct way of identifiying which tag is causing the issue in LV. You can try writing/reading one element at a time. Maybe if you copy the XML string in XML Notepad it will point to the faulty tag.

Ben64

[Bob_Schor]

You know the data that went into the file, as well as the file that was produced (neither of which we can inspect).  If you want to find this "on your own", my advice would be to do a series of "Create/Read" experiments with your dataset.  You've already determined that the full data set results in an XML file that throws a 1105 error when you read it.  Either do a "Tear Down" or "Build Up" experiment -- either start with the full Data Set and create smaller subsets to do the Create/Read test until you get Success, or start with one element, do Create/Read, and continue adding elements until you get Failure.

Once you have isolated something that when added (or subtracted) changes the Error State, you know where to look in your XML file.  You can also see if writing just that element causes the failure.

In any case, when you figure it out, post your results here so other users of the LABView XML functions can learn from your experience.

Bob Schor

[dest2ko]

What's particularly bothering about my issue is that the code functions, just intermittently. Sometimes it successfully loads a configuration and sometimes it does not. I can't help but think this could more imply the error is based upon the values entered by the user and not the data / data structures themselves. I don't really have a lot of oddball data types in it; the worst I have are typedef enums and timestamps. Thus I think I may be black boxing unless there is more specific error information available. 

If JSON is relatively weakly typed compared to XML, maybe I ought to give that a shot? 

[Bob_Schor]

---

@dest2ko wrote:

I can't help but think this could more imply the error is based upon the values entered by the user and not the data / data structures themselves.

---

How does the User enter data?  How does the data go from User Entry to entity being saved as XML?  Ordinarily, XML's Strong Typing makes it (shall we say) "difficult" to get a bad value, though if you are saving Floats, you might end up with NaN.  There may be other data types where there are "mis-matches" (can't think of examples off the top of my head, but things that might give run-time errors if you tried to act on them, like "File Not Found") ...

When errors occur, have you noticed whether or not it is the same variable (or type of variable) that causes the Error?  What kind of variable is it?

Are you trying to save Variants?

Sorry to ask so many questions, but this puzzles me greatly.  I've done some work with XML in LabVIEW, but have not (yet) encountered the problems you are seeing (and want to avoid them, if possible).  Please help me help you (and, potentially, myself) by supplying more information.

Bob Schor

[Ben]

---

@dest2ko wrote:

What's particularly bothering about my issue is that the code functions, just intermittently. ...

---

That word is tightly coupled with the concept "Race Condition".

Now if you can come up with a sequence of steps or operations that can reproduce the error, then maybe not a race condtion and look at the data.

Ben

[dest2ko]

How does the User enter data?  How does the data go from User Entry to entity being saved as XML?  Ordinarily, XML's Strong Typing makes it (shall we say) "difficult" to get a bad value, though if you are saving Floats, you might end up with NaN.  There may be other data types where there are "mis-matches" (can't think of examples off the top of my head, but things that might give run-time errors if you tried to act on them, like "File Not Found") ...

The user interacts with a job setup screen with data fields for entry. When complete, user OKs and the information is sent via an asynchronous message from the host to the RT target, with the data then updated. I have a functional global variable I use to store the overall system data. I always convert data to a variant and then accompany the subVI call with a tag based input string similar to the CVT to tell me what to do with it once I'm inside; this way, I perform specific operations and always base my updates on the latest (full data set is on the shift register.) The contents of this FGV are periodically saved (every 10s) to file via the 'Flatten to XML' and  'Write to XML File' functions. 

When errors occur, have you noticed whether or not it is the same variable (or type of variable) that causes the Error?  What kind of variable is it?

That's what I'm still searching for at this point. I need to inquire the end users about whether or not this is happening always with the same data set, or intermittently with the same data set. I think that may shed some light. Inherently, though, it may prove complex to reuse the "same data set," at least from input coming from where this thing is deployed now. 

Are you trying to save Variants?

No variants. The control type is specifically a type defined control with a few (5-6) other typedefs and does contain a few arrays of clusters where an element in that cluster is also an array. 

Race conditions:

I've ensured the XML files are never triggered to read and write concurrently. All of my disk write operations are contained in series in their own thread due to my fears regarding the nondeterminism.

[dest2ko]

Would it be possible that if the unit is powered down in the middle of a disk write that the file would be corrupt? I just got it to error out again and the error was different this time: Error 1102, LabVIEW:  The string wired to the xml string input is empty. This may explain why any attempts following to re-load the configuration file, no matter how many, produce the same results. Are there any best practice recommendations to mitigate this issue? Power disconnection will always be an unanticipated event for this. 

[dest2ko]

Just as an update, I eventually traced this down to be linked to power disconnects during file write operations. I had been updating a single configuration file every 10 seconds to give the user the ability to resume a batch/job during an unexpected power failure. I had considered things such as software shutdowns/restarts since most of our disconnects are controlled, but it seemed like an easier approach (and better for true power failures) to alternate the file writes between two configuration files (config.xml and config_alt.xml) on the 10 second triggers. The downside to this is to have potentially older (1 more iteration / 20s) data which is tolerable for my particular application.

I have not explored the determinism behind this error in detail, i.e., where the specific tolerance window resides whereby the files are potentially corrupted, but I would assume it's generally during the write operation. What has confused me a bit is that the window seems to be larger than I would expect: I timed the file writes to take 30ms, meaning if the error resides only in that window, the user would have only a .03/10 (= 0.3% = over 1 in 300!) chance of striking out. This is inconsistent with the occurrence observed in the field (about 1 in 10 job reloads detected a corrupt file) so maybe it is something beyond just the write window. 

Thanks to those who contributed suggestions. 

[RavensFan]

What PC hardware are you using?

It is possible that the XML write is faster than the actual file writing time if the hardware is buffering the data before writing it out.

The more important question is why would you be having power interruptions while your program is writing out the data?  And how have you been recovering from them without having noticed it until now?