Searching VIs for particular object combinations

[Cunk]

I'm pretty sure I already know the answer to this but is there any way to search VIs for particular pairs or combinations of objects?  For example, say I want to find every place a certain global variable gets assigned a constant of 21.  As it now I can only search for instances of that global but if it appears in several hundred locations then it's not going to be easy to identify all the places where it gets set to some number of interest.

[Cunk]

Hmmm.  While searching for possible ways to do this I stumbled across Labview Scripting which is something I was not aware of before.  I wonder if I could accomplish this using that...I'll need to investigate.

[johnsold]

If you have a global with hundreds of instances and are writing to it in multiple places as it sounds, then you have problems much bigger than searching.

You are very likely to have serious problems with race conditions.  It also indicates that you do not understand LabVIEW's dataflow paradigm. This suggests that there may be many other examples of inefficient or poorly performing code examples in your program.

How many instances of "21" do you have which are not connected to your globals? Would searching those give you a shorter list?

Lynn 

[Cunk]

I wholeheartedly agree with your assessment of the core problem here.  Unfortunately I'm in the unenviable position of having to get up to speed on a pretty complicated (unneccesarily so, I'm certain) code base that has a 10+ year history of off-the-cuff and rushed design choices like this.  Over-reliance on globals is only the tip of the iceberg here.  Add to that the fact that I'm new to Labview (I do have other programming experience in more traditional languages) and you have what I personally consider an intimidating task to deal with.  Luckily it's not a situation where the previous programmer is gone so I've been able to rely on him for help with this.

It's probably not the best way to get introduced to Labview because I wind up getting more frustrated at the development environment than it probably deserves.  Any programming project, no matter the language, can devolve into an incomprehensible mess so I don't blame LV for that aspect.  However I don't like the fact that due to the closed nature of this platform I don't have the option to use any of the tools I've found to be essential.  Beyond Compare file diff for example.  I realize Labview has some sort of diff feature but you need to have the Professional version (which is more full of features than Full...) which we don't have and from what I've seen and heard it's not that good anyway.  Nor can I run any third party metrics tools on my code.  Look at any text-based language and you'll find a vibrant ecosystem of 3rd party tools available to support it.  Not so with LV.

After I've gotten comfortable with this project (years from now probably...) I might suggest redesigning this application in .NET or something that utilizes the relevant freely available libraries (DAQmx currently).  I haven't seen much so far that wouldn't be fairly trivial to re-implement (although I/O updating and proper interaction with the UI might be challenging).

Sorry, I've gone way off-topic in my own thread.  I guess I had to blow off some steam.

Anyway, unfortunately searching for specific numbers like "21" doesn't help in this case.  If I manage to accomplish anything using LV Scripting I'll be sure to update this thread.

[DougSiemon]

I think LabVIEW scripting is going to be the best way to do what you want. With the scripting you can open a VI's block diagram and traverse the objects that are contained. If you installed scripting on your machine you should find examples under ...\labview\examples\VIScripting. I think that the Using Travers.vi should be helpful in learning how to find the constants in your project. This link https://decibel.ni.com/content/docs/DOC-4973 should also be helpful in learning about scripting.

[Cunk]

Thanks.  I did a brief examination of LV Scripting and I'm pretty confident I'll be able to do what I have in mind.  In fact after seeing what you can do with scripting several ideas for tools have come to mind.  For example I'd like to make a tool that can generate a comprehensive summary of a VI and export it to a text file (or even just the clipboard) so I can use my favorite third party diff tool (Beyond Compare) for identifying changes to VIs.

[crossrulz]

---

@Cunk wrote:

For example I'd like to make a tool that can generate a comprehensive summary of a VI and export it to a text file (or even just the clipboard) so I can use my favorite third party diff tool (Beyond Compare) for identifying changes to VIs.

---

You do realize that NI already gives you a pretty good diff tool for LabVIEW (C:\Program Files (x86)\National Instruments\Shared\LabVIEW Compare\LVCompare.exe)

[LV_Pro]

He did mention diff, but it may only be available (as he implies) in the Professional Dev pacakge, and he only has the "Full". I can't confirm this, only have access to Pro installations.

[Mark_Yedinak]

First, I would request an upgrade to the Developer's Suite of LabVIEW. If you are going to be doing significant work and have to deal with the code base you inherited than it is well worth the cost to get the additional tools it has including the VI analyzer. If I were given this task I would definitely promote a rewrite of the system. If the changes you are making are significant enough or the bugs frequent enough the time would be well spent. Not to mention that it would probably be faster to rewrite good code than band-aid spaghetti code. This is true for any language.

While LabVIEW is proprietary it is an extremely powerful and capable language. Don't discount it quite yet. If you keep an open mind while learning it you may find that you actually prefer programming in it. Most people I know who give it a fair chance do.

[GregFreeman]

---

@Cunk wrote:

I wholeheartedly agree with your assessment of the core problem here.  Unfortunately I'm in the unenviable position of having to get up to speed on a pretty complicated (unneccesarily so, I'm certain) code base that has a 10+ year history of off-the-cuff and rushed design choices like this.  Over-reliance on globals is only the tip of the iceberg here.  Add to that the fact that I'm new to Labview (I do have other programming experience in more traditional languages) and you have what I personally consider an intimidating task to deal with.  Luckily it's not a situation where the previous programmer is gone so I've been able to rely on him for help with this.

It's probably not the best way to get introduced to Labview because I wind up getting more frustrated at the development environment than it probably deserves.  Any programming project, no matter the language, can devolve into an incomprehensible mess so I don't blame LV for that aspect.  However I don't like the fact that due to the closed nature of this platform I don't have the option to use any of the tools I've found to be essential.  Beyond Compare file diff for example.  I realize Labview has some sort of diff feature but you need to have the Professional version (which is more full of features than Full...) which we don't have and from what I've seen and heard it's not that good anyway.  Nor can I run any third party metrics tools on my code.  Look at any text-based language and you'll find a vibrant ecosystem of 3rd party tools available to support it.  Not so with LV.

After I've gotten comfortable with this project (years from now probably...) I might suggest redesigning this application in .NET or something that utilizes the relevant freely available libraries (DAQmx currently).  I haven't seen much so far that wouldn't be fairly trivial to re-implement (although I/O updating and proper interaction with the UI might be challenging).

Sorry, I've gone way off-topic in my own thread.  I guess I had to blow off some steam.

Anyway, unfortunately searching for specific numbers like "21" doesn't help in this case.  If I manage to accomplish anything using LV Scripting I'll be sure to update this thread.

---

I just want to applaud you for the most unbiased post that I have ever read from a text programmer who has come across a LabVIEW application like this (and to a certain extent we feel your pain. Almost everyone on these forums has come across this kind of thing before, and it's not easy for any of us to deal with, new or experienced). I understand the demands of the job and getting things done quickly, but I also encourage you to put some time into learning the "right way" and at that point, maybe you can convince your boss to let you refactor. I know that's not always the easiest thing to do, but I also think you'll be glad you did it.