How can I print out a VI's Logic so I can look at it easier

[FlybyWire]

I am looking for away to print out a VI's logic so I can write on it as I figure out how it works because it is really confusing.  Is it possible to do this?  Otherwise I am thinking of taping screen shots together.

[GerdW · Accepted solution]

There's a print menu item, probably in the file menu. Have you tried that?

[FlybyWire]

I tried but it just printed the operators view not the VI Logic. OH Wait there's a selection option that's what I need Thanks 🙂 

[wiebe@CARYA]

---

@FlybyWire wrote:

I tried but it just printed the operators view not the VI Logic.

---

The operators, structures and wires are the logic.

What 'logic' do you expect to get?

If you really want to, you can get DIFR or LLVM code. I doubt it will help you with understanding things...

[cstorey]

Open the block diagram and select File - Print..

Screen shots are also a solution.  But if you have to tape them together than you probably need to do some work leaning up and simplifying your block diagram; use subvis, clean up overlapping wires and generally following the style guidelines.

Style guideline resources:

- https://labviewwiki.org/wiki/LabVIEW_style_guide

- https://www.physik.uzh.ch/local/teaching/SPI301/LV-2015-Help/lvdevconcepts.chm/checklist.html

Hope that helps.

Craig

[wiebe@CARYA · Accepted solution]

---

@cstorey wrote:

Open the block diagram and select File - Print..

---

Actually, File>Print...

And than select Icon, description, panel and diagram, or VI Documentation: 

If you select VI Documentation, tag 'Diagram'.

I'd print to PDF, and than either print only a selection, or print multiple pages on one sheet, or reprint with a better selection. Save a tree...

[altenbach]

---

@FlybyWire wrote:

I am looking for away to print out a VI's logic so I can write on it as I figure out how it works because it is really confusing.  Is it possible to do this?  Otherwise I am thinking of taping screen shots together.

---

If your VI is confusing when looking at the diagram, it will be even more confusing if you look at an image of the diagram because you'll be missing all the nice editor options such as double-clicking a wire to see where it comes from and where it goes, the context help to tell datatype, functions names, and so on.

Once you have express VIs and dynamic data, a picture is completely useless because all important information is invisible.

Printing a way oversized diagram on a huge poster board, then using a marker pen and highlighter to study it is definitely not the way to go. 😄

I guess the secret would be to write code that is clear in any form, well laid out and modular and of reasonable code size. If you are confused about a diagram, the programmer did not do a good job annotating, using wire labels, and naming terminals logically. Wasting paper worth an acre or old growth rainforest will not help. 😄

Feel free to attach your diagram and we might be able to explain it to you.

[wiebe@CARYA]

---

@altenbach wrote:

I guess the secret would be to write code that is clear in any form, well laid out and modular and of reasonable code size. If you are confused about a diagram, the programmer did not do a good job annotating, using wire labels, and naming terminals logically. Wasting paper worth an acre or old growth rainforest will not help. 

---

I'd say spending (a significant amount) of time simplifying is a good 'trick'. You did cover that with "write code that is clear", but I just want to stipulate it.

Making code simple is what I spend most of my time on, either by making thinking things through so I can make it simple straight away, or by refactoring (other people's) code so it becomes simpler. It is of course where experience comes in handy.

If there is a bug you can't find (easily), it is always because the code is too complex (for you). Sometimes you need to level up (e.g. learn the used techniques), but most of the time it's the code that is too complex.

If simplifying the code, bringing it to it's very essence, doesn't do the job (completely), clarifying it wit annotations and comments is a resort.

Good naming is indeed crucial in any programming languages, some go as far as to say 90% of programming is making up good names.