Bug in Datafinder Queries?

[labmaster]

I worked with datafinder and multi-queries functions in LabVIEW 2009 sp1. No problem.

By some reasons, I changed the data format of TDMS.

Each channel (ch0... chN) of a group has the time information of acquisition marked with the same name of DateTime.

DateTime was changed to group level and others from file level.

I just tried to query (time AND string) with the almost same code which worked before.

But, I found trying of only time OR only string query is successful but the combination of time "AND" string is not working.

I have no idea about the troubleshooting but guess the kind of bugs in Merge Queries.vi.

Enclosed is the code and two TDMS files you can try.

labmaster 

[labmaster]

Does anybody try to this bug in LV 2010 or 2011?

I need to check this before upgrading.

labmaster.

[StefanR]

When DataFinder performs a query, it will be analyzed if all query condition applied to a specific level (root, group or channel) are met.

If there is no channel which conforms to all query conditions combined by AND on that specific level, no results are returned.

From looking at the provided screenshots it seems that the time property is added to one channel whereas the string property exists at a different channel. Meaning there is no single channel conforming to the applied query condition - which leads to the empty query result.

[labmaster]

Thanks for the reply.

As I mentioned " I found trying of only time OR only string query is successful ".

That means True (codition1) AND True (condition2) should be True.

In AND and OR operator in Merge Queries.vi in 3rd code, I can't get the result.

For your understanding, I am attaching the screen shots.

[labmaster]

Cancelled posting.

[StefanR]

Ok, here comes the next step in query execution of DataFinder:

If the query spans multiple levels (e.g. groups and channels), it will be analyzed whether there is an object on the first level which conforms to all condition on the first level. Afterwards the objects of the child level will be analyzed if there is at least one object conforming to the conditions of this level and so on...

In your specific case there has to be at least one group within the time interval defined by your query together with at least one channel of that specific group which conforms to the text query.

Unfortunately this does not apply to your data sets and by this the query returns no results.

[labmaster]

Maybe, that's what I mean.

In last example shot, the query result file is the one. (I put only one file in the datafinder.)

For example, the file includes several data groups with each datetime (actually all conformed in the example) and the string in the channel (still conformed with the query in "the" file).

My code had no problem before moving the paramenters a little bit (inside the same TDMS file but different level)

That's the reason why I called this problem as a bug.

Am I right?

However, I need to know the result in higher version (2010 and 2011) than LV 2009.

labmaster.

[StefanR]

From looking at how the information is stored, I would recommend to attach the global information to the root/file level. This will allow to include this information in the query.

Please note that DIAdem 2011 allows to copy information stored on the root/file level to the next (group or channel) level in case root/file information is already contained in the DIAdem Data Portal (see Settings>>Options>>NAVIGATOR Loading behavior).

The DataFinder (incl. Toolkit) for LabVIEW 2011 is backward compatible to 2010 and 2009; 2010 is also backward compatible to 2009.

The index of My DataFinder (2009) will be updated autommatically to the respective newer version (2010, 2011).

[labmaster]

I think the TDMS format should not be limited in the file.

So, don't you agree this problem is a bug?

I'd like to hear from NI.

labmaster.

[labmaster]

Let's assume we have two sensors for testing.
Each sensor has several identification properties (_manufacturer, _serial).

In this case, the TDMS structure of DAQ acquisition should be..

- Root
  Very common Test Parameters

- SensorInfo (Group)
  - ch0: _manufacturer, _serial
  - ch1: _manufacturer, _serial

- TestedData at the first condition (Group)
  - _TestTime
  - ch0: _prop.value1, _prop.value2
  - ch1: _prop.value1, _prop.value2

- TestedData at the second condition (Group)
  - _TestTime
  - ch0: _prop.value1, _prop.value2
  - ch1: _prop.value1, _prop.value2

...

This is my structure of TDMS, for example.
I mean there should be allowed the queries for common properties.
I didn't agree your recommendation of root/file level position.
Can you give me a good idea for my case?

labmaster.