Search for a call to the STOP function?

[MarkBowles]

Good morning, all,

I have taken over a relatively large LabVIEW 14.1 program, consisting of around 1000 separate VIs.  The program runs on a cRIO 9067, communicating to a PC-based HMI through the network. It includes a custom-programmed FPGA.

It's been working fine for years, and I have been making incremental improvements to it for about 18 months. I don't have access to the programmers who preceded me in managing this system.

My problem is that randomly, 1x or 2x/day, only on a few of our many lab instruments, the cRIO side simply stops running. None of the linux or NI log files, nor any of my application-level logs seem to provide a clue as to what happened.

It occurs to me that perhaps somewhere in the 1000 VIs, one of them is calling the STOP function.  Is there a way I can get the LabVIEW project explorer to search the code for an instance of the STOP vi?  If the program were written in Java, I could just "grep for it" through the source tree.  What's the LabVIEW equivalent?

More generally, any suggestions as to why a system would suddenly just stop running would also be appreciated.  I can't prove it, but I suspect this happens when the lab LAN is very busy.

Thanks,

-- Mark

[Bob_Schor · Accepted solution]

LabVIEW has a very nice "Find" tool (invoked by Ctrl-F) that will find VIs, functions, and even text that are currently in memory.  Unlike JAVA, LabVIEW is compiled (and therefore quite fast), but does have this "in memory" requirement for finding stuff.

So how do you get all of your code into memory?  Well, if all of your code is in one humongous VI (like some we've seen on the Forum), it's easy.  Otherwise, you can do the following:

•  Open the LabVIEW Project that contains all of the VIs in your (lower-case) project.
• Create a new VI, call it something like "All VIs".
• From the Project Explorer, drag all of the VIs in your Project (except All VIs) into the block diagram of All VIs.  Don't worry about any broken arrows in All VIs.
• Open All VIs.  Type Ctrl-F and search for Objects.  In the middle (where you specify what to look for), you can find all the functions on the Block Diagram Palette.  You can also find all sub-VIs loaded in memory.
• Once you start the search, it will find any/all instances of what you search for.  It will also try to look "inside" NI's functions that are password-protected, but you can tell it to skip all of those.
• Once it finds (or doesn't find) matches, you can use Ctrl-g to "Go" from match to match, seeing them in the VIs where they appear.

Bob Schor

[MarkBowles]

The cRIO side of the app is indeed, "one humongous VI" and its subs, so doing the search was easy.  Thanks hugely for this pointer.  I am a multi-decade software engineer, mostly C and Java, but new to LabVIEW -- never needed a global search before.

This quickly confirmed that the hard-stop function mentioned in https://zone.ni.com/reference/en-XX/help/371361R-01/glang/stop/ is not used anywhere in the cRIO app.

I know the app is stopping or crashing because I have a tight loop in one of the modules that open-append-closes a file once a minute with a timestamped heartbeat message. When the app stops working, I log in to the cRIO and can tell when the last heartbeat was. 

I've also done a "ps -ax" on the cRIO while the app is running, and after it's stopped, and found no (significant) differences in the processes.

Any suggestions for next steps to track down this problem?

Thanks,

-- Mark

[MarkBowles]

Found a clue in a LabVIEW error message after all. Same problem as https://forums.ni.com/t5/LabVIEW/DWarn-0xC1EAEA9C-Internal-error-2-occurred/td-p/3762274 .

[Bob_Schor]

Well, if you are using the Error Line properly, you will get an Error Message that tells you at least something about what caused the Error.  A well-written LabVIEW program will have a design that includes few VIs with a Block Diagram larger than a laptop screen, but will have hundreds (or thousands) of sub-VIs.  When an Error occurs, the Error message usually shows the Call Chain (as well as "what went wrong", e.g. Divide by 0), enable you to narrow down on a smaller section of your code.

Sounds like to you need to get some colleagues to sit down with you (and a large Monitor) and "walk them through the code".  Doing such a code walkthrough, even if to people who don't know LabVIEW (but do know something about programming) can ask "How do you know that it works that way?", and sometimes, the answer is "Well, oops, there's a missing wire …".

Bob Schor

[billko]

---

@Bob_Schor wrote:

LabVIEW has a very nice "Find" tool (invoked by Ctrl-F) that will find VIs, functions, and even text that are currently in memory.  Unlike JAVA, LabVIEW is compiled (and therefore quite fast), but does have this "in memory" requirement for finding stuff.

So how do you get all of your code into memory?  Well, if all of your code is in one humongous VI (like some we've seen on the Forum), it's easy.  Otherwise, you can do the following:

•  Open the LabVIEW Project that contains all of the VIs in your (lower-case) project.
• Create a new VI, call it something like "All VIs".
• From the Project Explorer, drag all of the VIs in your Project (except All VIs) into the block diagram of All VIs.  Don't worry about any broken arrows in All VIs.
• Open All VIs.  Type Ctrl-F and search for Objects.  In the middle (where you specify what to look for), you can find all the functions on the Block Diagram Palette.  You can also find all sub-VIs loaded in memory.
• Once you start the search, it will find any/all instances of what you search for.  It will also try to look "inside" NI's functions that are password-protected, but you can tell it to skip all of those.
• Once it finds (or doesn't find) matches, you can use Ctrl-g to "Go" from match to match, seeing them in the VIs where they appear.

Bob Schor

---

In the old days, we called that the "Tree.vi".

[Bob_Schor]

---

@billko wrote:

In the old days, we called that the "Tree.vi".

---

… and I still do.  I even have a VI Icon made for it.  

Bob Schor