Tree Data Structures In LabVIEW

[JamesMc86]

Hi,

I am working on something that I was looking to see if anyone had any experience on.

I am working on an application which has a need for a heirarchal data structure in a couple of places. The main one being a representation of a file structure (not one that actually exists on disk) but also a couple of others that will end up being generated XML files. I am torn between two key options:

1. Impelent in a pure LabVIEW method (there is an example I would start from on the NI Community). I would be tempted to have a couple of options, one that is a pure linked list style implementation. One that also uses an variant dictionary to track the URLs of nodes to make a URL based lookup a constant time function (but will slow modifications to the existing tree).

2. Use the Microsoft DOM interface (.net based I think in LabVIEW but could be activeX). Whilst this is designed to used for files you I think you can modify it purely in memory and would mean my file writing routines are done). I am not fussed about portability (this will only run on windows) but I am concerned about the performance. While my trees will be quite small it may not perform well in memory. Or is the performance good and not worth the effort of the first implementation?

Has anyone come accross a similar problem and have any advice on these approaches or have alternative approaches?

[drjdpowell]

You could consider a hierarchal structure of nested LVOOP objects similar to the one we used in the JSON package.

Another thought would be SQLite, though I have never done a hierarchal structure in it so it might be more complicated. But you would have the advantage of fast lookup on URLs and just about anything else you wanted fast lookup of.

[Tim_S]

I built up a treeview class some time ago that uses attributes in a variant to keep track of the UIDs, their parent, etc. This gave me better performance and much simpler code than parsing through the tree. I've reused that code a fair amount, though it's always been for small data sets.

[crelf]

Maybe I'm not quite understanding what you're after, but have you considered using EasyXML? THen you can define your heirachical datastructure as a cluster of ..., and it makes reading from/writing to actual XML files straight forward. I use it on a few projects and it's sweet.

PS: The example on the webpage is trivial - it works very well with complex and large schemas too.

[Ryan Podsim]

I would recommend a LVOOP solution. You could build a menu item class that include a list of Menu Items. The Class would contain a Menu string Functions and a Menu Action Function. The parent class would contain a build menu function that builds a string array from the Menu String Child classes.The Menu string would return a String with the name of the menu item and the Menu Function would perform, what ever, action would be required by that item, whether if be a new menu or an action. This would require generating the tree structure either prior to the menu becoming active or dynamically as the items are selected. How you generate the menu is a personal preference, and the above methods are valid for that.The exact implementation would depend on the program architecture as the menu could be independent or integral.

Note: I believe (haven't tested) but the the above method could be used with the built-in Right-Click-Menu functionality. You would need to carry the Tree structure through to handle each case, but with pre-pended strings your could easily traverse the tree to access the item selected.

-Root

--Chlid 1

---GC11

----GGC1

---GC12

-Child 2

---GC21

--Chlid..

---GC...

This would allow for the top level menu to be independent of the grand-children, but would require that each child know of it's grand-child and so on. Each child would a child of Menu, and the parent contain an array of Children. The Menu String would return a cluster of (string, array of strings)

Edited December 11, 2012 by Ryan Podsim

[JamesMc86]

Thanks for all your suggestions.

I think I will probably go with the OOP mechanism for the challenge as much as anything! It does look like the DOM parser could be used in this way (I like the idea of SQLite as well, I'm going to be playing with this in another part of the project anyway, I think this can just operate in memory though) but I think doing it in OOP will keep it more reusable and portable for the future.

EasyXML is one I have heard of but in this case XML is only a small part of what I need, I also just want an easy way to deal with a tree structure within the application.

[drjdpowell]

I like the idea of SQLite as well, ..., I think this can just operate in memory though

You can use SQLite entirely in memory by using “:memory:” as the filename. Also note that SQLite uses a caching mechanism that makes it effectively in-memory as far as reading goes, as long as the database is smaller than the cache size (2 MB by default).

[Aristos Queue]

I recommend the tree data structure Damien implemented to underlie his priority queue:

http://forums.ni.com/t5/LabVIEW/Dr-Damien-s-Development-Priority-Queue/td-p/837194

[MisterXX]

The last post was from 2012, I was wondering if people have updated ideas on this now (2018)?

Common scenario's for potentially wanting tree data structures are for example:

-- receiving and storing time series of sensor values (raw and filtered),

-- reading/writing program settings,

-- sending and storing time series of actuator values (PID control, binary control),

-- generating and storing fake time series sensor values and actuator simulation for testing

 

 

[infinitenothing]

Many people use variant attributes for trees.

I'm a little curious about your time sensitive use cases, it almost sounds like you want a sorted list instead of a tree which, I think there are some examples of using maleables in 2018. 

I think being able to use variants in the in place structure may have opened some doors:

This is pre 2012 but it's a implementation of some data structures using DVRs and OOP

[smithd]

18 hours ago, MisterXX said:

-- receiving and storing time series of sensor values (raw and filtered),

 

-- sending and storing time series of actuator values (PID control, binary control),

-- generating and storing fake time series sensor values and actuator simulation for testing

I dont understand why these need a tree structure? Just for groupings and the like? 

In any case, sounds like TDMS could do the job, and it even has an in-memory version: http://zone.ni.com/reference/en-XX/help/371361M-01/glang/tdms_inmem_open/

You can also use sqlite in-memory although sadly it has no array support

 

for the configuration use case the lava json library as I recall unflattens json into an object tree.

Edited August 15, 2018 by smithd

[drjdpowell]

I now use JSON for tree-like program settings, and things like test results and test scripts.  I left objects and variant attributes behind and just handle text directly (JSONtext).  Like others, your "time series" examples don't seem very tree-like to me (although my JSON test-result files do contain several serieses).

Edited August 15, 2018 by drjdpowell