Tracing input value

[Mephiengineer]

Dear all,

I work on debugging the software was written on LabView. I have a deal with big project that consists of approx. 1500 VIs. This software operates the physical installation and has a lot of bugs. A lot of them linked with passing the data through the VIs. Based on it, let me explain what I am looking for.

Just an characteristic example. Let`s take a VI with control that is TypeDef in TypeDef implemented in a big TypeDef. I need to trace the data that I manually put in this control. Not only find the input point, but also trace how the whole program use this data or single value. Which VIs take this data, where are connections that they use to transfer it between VIS, etc. It would be really nice to possess a possibility to find all places when new value appears.

When I put in some value, it is automatically processed by whole program. Program writes it down in several places, it would be really cool to get to know, where it happens exactly.

Could you tell me please if there are any tools or any other possibilities to trace the input data through the whole program? I am already familiar with Desktop Execution Trace Toolkit. That is quiet useful tool to trace running VIs but not the data transferring.

Thank you in advice!

[cbutcher · Accepted solution]

You can find all the places a typedef is used by right clicking on it in the Project Explorer and choosing Find > Callers.

To try and find only places that modify the values, consider changing (emptying, perhaps) the contents of the typedef (after ensuring your code is suitably backed up in SCC like Git, or via copied directory, or whatever).

You can then look for errors that might indicate places where the typedef is bundled or unbundled. Unfortunately, such a method will include the places that read the value too...

[Bob_Schor]

---

@cbutcher wrote:

You can find all the places a typedef is used by right clicking on it in the Project Explorer and choosing Find > Callers.

---

This will give you a list of all the places your TypeDef is used.  You can use ^G to "Go to" them one at a time in Project Explorer (the name will be highlighted).  However, if you click on the highlighted name, you "break" the "Go to" chain and have to start over.

I use a slightly different method that also has "mixed features".  I create a "Tree" VI, a VI that has a copy of every VI and TypeDef in my Project (this can get big with 1500-VI Projects, but you can create sub-Trees and build a "hierarchical Tree").  I then use the "Find" command (^F), or right-click on the VI in the Tree (or on its Icon if it is open in front of me) and say "Find All Instances".  This brings up another list that you can traverse with ^G.

I surely hope that most of your VIs are documented, at least to the extent of having their inputs and outputs described, and maybe a brief sentence on what they do.  I "inherited" a (little-p) project once (in LabVIEW 7, before the LabVIEW Project was invented) and no VI was documented.  Needless to say, I spent a year or so in "patch mode" before I realized I needed to "Start Over from Scratch" (the result was a considerable improvement, I'm pleased to say ...).

Bob Schor

[cbutcher]

You may have some luck with the attached demo project.

I've quickly scripted (and so probably failed to consider some corners) a project that contains a typedef, several VIs which interact with the typedef in various ways, and a "Search-VI.vi" which looks for VIs which use the Bundle or Bundle by Name nodes with the typedef as one of their terminal types.

This will catch both the block being written as an input to a larger cluster, or as the output of a bundle, but ignores reads of the value (which seems to be the desired behaviour?)

It's backsaved to 2016, but I can provide an older version if required.

With regards to tracing specific write locations, you could consider (again, with an appropriate backup, since you wouldn't want to keep these changes) modifying the typedef to add a string value with a name like "source-vi-location" or similar, and then extending the scripting VI I uploaded here to add a value to each write, with the current VI's name, or the call chain, or similar. It's not exactly trivial but might allow better "tracing".

[Alexander_Sobolev]

If it is accessed by unbundle/bundle by name nodes (and in place element structures), you can search its name in cluster as text and look only at these nodes. It also helps to remove everything except visible object's data and parts in More options in search settings. Searching just for typedef callers will show all callers of the higher typedef.