Understanding a predesigned LabVIEW project/Examples

[hare_krishna]

Hi, I am very new here in community, please help me 

can anyone please tell me what are the right steps to understand a pre-designed LabVIEW project consists of many SubVIs, TypeDefs, Global variables.

Please share the important links

Thanks

[RavensFan]

I would recommend you learn more about LabVIEW from here. How to Learn LV

[altenbach]

---

@hare_krishna wrote:

can anyone please tell me what are the right steps to understand a pre-designed LabVIEW project consists of many SubVIs, TypeDefs, Global variables.

---

Even for a LabVIEW expert, fully understanding a large project can be difficult, so don't expect miracles, even after going through the learning resources. Was the project written by a skilled programmer (well structured and documented in detail, etc.) or some hack (gigantic diagrams without comments, deeply stacked sequences, local variable over-use, Rube Goldberg code everywhere, etc.).

What is the purpose of your questions? Are you planning to do your own small modifications? What does the program do?

Who wrote the code? Can you contact the original programmers(s)?

[Ben]

Well to start...

Find the top level VI

Do a Show VI Hierarchy

Shut-off VI.lib

Make sure the type defs are included in the hierachy

go the bottom of the hierarchy and find the bottom most type def.

Right click that type def and do a "show VI hierarchy on it.

That will show what other type defs depend on that data structure as well ahs the VIs that use it.

Repeat that with more of the type defs. (until you get board)

Next got to the top level VI and click the button at the bottom of that VI to hide everything.

Click that button again just to see which VIS are called by the top level VI.

Read the documentation if it is there.

Do a Show VI hierarchy on one of the VIs called by the top level VI.

Repeat that until you get board.

After that I would start looking into the sub-VI. Read the documentation if they have any. If they do not start putting in your own documentation.

Be aware that if the code was not written well the above may not get you very far.

If it was written well it should give a general idea of what is being done by who when and under what conditions.

just my 2 cents,

Ben

[Ben]

adding to my last...

If the hierarchy is wide and shallow the code most likely sucks.

If it is narrow and deep, you may actually be looking a decent code.

Ben