Unflatten from XML doesn't handle DAQmx tasks inside an object

[BertMcMahan]

So I'm scratching my head on this one. I'm a noob to XML files so I'm guessing it's user error, but I've been able to make a very simple reproduction (project attached).

I'm trying to use an XML file to save a custom class with some configuration parameters in it, one of which is a DAQmx physical terminal. Creating the XML file results in a good XML file with the right channel, but the Unflatten from XML doesn't seem to process the MyAIChannel value correctly and it just displays a blank.

The weird thing is if I make a typedef'd cluster with the same internal data as the object, the XML parsing works just fine.

Open the project and run Test.vi; it'll create a couple temporary XML files then read them back in.

Any thoughts? It seems like this may be a bug in the XML parsing VI (which I can't access).

I generally just need human-readable config files from an object, and as far as I know only the core LV XML handles objects. LV's JSON doesn't do objects and all of the Simple/Easy/etc. XML files didn't handle objects.

[Kevin_Price · Accepted solution]

I can't speak to the XML specifically, but have found that some of the special DAQmx datatypes (physical channels, terminals) get handled more reliably when the cluster or object contains them as strings.  There's a coercion dot when extracting the string to feed into a DAQmx config function, but it's a benign one that converts correctly.

I think I first encountered this many years ago with the otherwise pretty stupendous "Read/Write Anything" freeware package from MGI (Moore Good Ideas).  Maybe DAQmx datatype support has been added to the package, but I've changed my habit in the meantime to simply store as a string and have not had reason to find out if it's still necessary.

-Kevin P

[BertMcMahan]

Good point Kevin, I hadn't considered that. I just switched my example to use a string and it works fine.

As a side benefit, I can do my conversions in my accessor VI's, which contains the coercion dots pretty well. Anything that needs to use that data still thinks it's an actual DAQmx datatype 🙂

[BertMcMahan]

As an update for everyone, I contacted NI support and they confirmed this was indeed a bug that was already filed (they didn't tell me the CAR for it though).

In addition to the workaround Kevin posted, they offered the following:

"The other workaround listed is if you place the class cluster inside an additional cluster then the DAQmx Physical Channel control saves and loads as expected."

Just wanted to help future Googler's.