Please comment on my large program structure.

[SectorEffector]

Hello,

This is my current method for programming large programs:

These are parallel while loops with event structures, each with an user event for the error handling.

This error handling is done in a seperate while loop with event structure.

To the left of each while loop there is code to initiate hardware, etc. that is needed for the while loop next to it.

Every while loop is labeled with a description in huge font marked in yellow of what is does. Examples: Error handler or A312f Kamera

The upper and largest while loop is the main program structure. This can be a while loop event structure combo, or a state machine.

Every event in the other loops is called with an Property Note / Signal Value function (execution time is not an issue) by the main program structure.

I only use sub-VI's if I have large Algorithms or repeating code in the different events. Otherwise I program all needed code in the event structure itself.

This is a work in progress, the finished program will have 10+ parallel while loops.

Please write some constructive comments about my method. I want to learn and improve my programming skills.

Kudo's will be given! But please be patient.

Thank you! 

[JohnMc19]

Hi Heinen,

This is a large bit of code! It would cut down space if you incorporated some parts of into a sub.vi, but only if the application of your project doesn't rely on determinism.

Surely you could of resized some of the while loops as well as there is a lot of space left inside them.

To generally improve your programming skills on LabVIEW I would also recommend skimming through this links:

Design Pattern: Producer Consumer

Producer Consumer Loops: Queues vs. Local Variables

P.S: You can save more room by editing your VI to replace your front panel icons with terminals.

Do this by going to 'Tools>Options>> Block Diagram>> Untick - place front panel terminals with icons'

[Andrey_Dmitriev]

Hi, Heinen,

Doesn't matter how large your project, you shouldn't have Block Diagram bigger than one screen. Use SubVIs.

Andrey.

[Ben]

Could you please repost that large un-readable image as multiple smaller ones?

Thank you,

Ben

[altenbach]

The diagram is too big for my taste but it looks like you at least only need to scroll in one direction and each logical code block can be centered on the screen to work on a particular task. Personally, I don't like to scroll during coding and many companies have policies on acceptable diagram size. This means that if you ever look for a job and show then some existing code, you might be in trouble. Even if you get the job, you might have to re-learn a lot of things from scratch and quickly need to lose some ingrained poor habits. 😄

If you would ever need to make code changes in the field, e.g. using a netbook or small laptop, there would be no efficient way of coding and it would become extremely tedious.

---

Heinen wrote:

This is a work in progress, the finished program will have 10+ parallel while loops.

---

Do you really need 10 different tasks to operate in parallel or are you just using this to logically segment the code for easier navigation?

---

Heinen wrote:

These are parallel while loops with event structures, each with an user event for the error handling.

This error handling is done in a seperate while loop with event structure.

---

I don't understand. Does every event structure handle errors or do most only generate user events in case of errors, then handled by the separate while loop?

---

Heinen wrote:

The upper and largest while loop is the main program structure. This can be a while loop event structure combo, or a state machine.

---

You mean the code that handles the user interface?

---

Heinen wrote:

Every event in the other loops is called with an Property Note / Signal Value function (execution time is not an issue) by the main program structure.

---

Your words (execution time is not an issue) could be misunderstood in many ways and requires clarification. Do (1) all events finish quickly? Do (2) events take a long time but it is not an issue because other code can operate in parallel?

Firing event with signaling value properties is a bit dangerous, because the communication is strictly one way. How does the UI loop get notified that a certain action takes longer than expected, generates an error, etc. What prevents the UI loop for queue-ing up millions of events that then cannot he handled for some unexpected reason?

What does the UI loop in terms of preprocessing the actual UI events? Why can't the slave events be triggered directly?

---

Heinen wrote:

I only use sub-VI's if I have large Algorithms or repeating code in the different events. Otherwise I program all needed code in the event structure itself.

---

Modularizing codes into subVIs is a key skill to write modular and re-usable code. They also offer the great advantage that they can be independently run, tested and verified in a sandbox. Firing up a huge diagram to test and probe a small code segment is difficult and tedious.

---

Heinen wrote:

Please write some constructive comments about my method. I want to learn and improve my programming skills.

---

It is difficult to judge a diagram from a stamp-sized, unreadable picture, so feel free to post the actual VI. I am currently on a laptop, so I might not be able to look at it very well, though.

[F._Schubert]

As others said, a use of SubVIs will improve your code. But taking your statement

I only use sub-VI's if I have large Algorithms or repeating code in the different events. Otherwise I program all needed code in the event structure itself.

I think it'll need more efford to convince you.

Using SubVis isn't only about reusing them. It is a way to structure your code.

Philosophical, I think that all modern software engineering is about structuring the code in multiple dimensions to be able to navigate from 1 section to another in fewer steps. You mention the event structure as a way to structure your code, and that's right. But this is not an argument against using the other orthogonal vectors to structure your code in more than one plane. The beaty of LabVIEW lies in it's 2D layout. LVOOP adds more dimensions to this with inheritance and associations.

Practically, I try to describe with a real world example, how you benefit from SubVIs even if they are only a single instance in your code. I was rewriting an old app from mine to add some new features.

One section (parallel loop) was dealing with representing the data on a graph (all kind of property nodes; event structure). This was partitioned into several layers of SubVIs.

1. The lowest layer where highly reusable VIs that agregate some property nodes that were used over and over again without any specific information on the App, so they can be reused in other projects.

2. The middle layer were all the project specific combinations, several of them reused (like intialization of the graph to default values and changes to the graph in the event structure).

3. The top layer was the single instance I called 'Graph Manager'.

Now looking at the heirarchy window, I have all SubVIs that deal with the graph bundeled by my graph manager.

Now I had a second module that performed a very similar experiment which just had some more data to display in the graph. So I could use all the SubVIs from Level 1 and 2 and add some more. Because this made now the GraphManager2, the hierarchy window allowed my to differentiate which elements were unique to GraphManager1 and GraphManager2 and which were shared.

In addition a made a 'Tree.vi' that documents these layers.

Lesson 1: A subVI allows you to group related function together. This makes your code better documented and hence easier to maintain. Also it makes it easier to get a related set of functions packaged for reuse in other projects.

Well, the story don't end here. I have several setups spread around the world that serve the same purpose, but younger in age (with other new SW features as well as some severe changes in the hardware used). So these run on a different code branch. Now I might get the job of upgrading these setups as well. Hence I will need to merge these new functionality with the newer models of my setup.

Only as my code is partioned into SubVIs for different functionality, it will be easy to replace the GraphManagers on the newer code branch with the new GraphManager from the old code branch.

Lesson 2: Use SubVIs partion your code into modules as requested by different features. This allows you to upgrade single features. Again it's easier to maintain.

Felix

[Ben]

Sub-VIs are to LabVIEW as paragraphs are to the written word. They make it easier for readers to understand.

Sure, Herman Melville* got away with breaking those rules, but until we achieve Herman Melville status in LV, stick with breaking up the code into readable parts.

Ben

* Herman Melville (sp? Author of Moby Dick) included a sentance that ran on for multiple pages.

[ohiofudu israel]

---

Ben Wrote"Sub-VIs are to LabVIEW as paragraphs are to the written word. They make it easier for readers to understand."

---

Ben

Thanks for the wisdom.

Ohiofudu

CLD.

[SectorEffector]

Hello everyone and thank you for all your replies!

I'm back from a 3,5 week vacation to Egypt, but I will start replying to your comments in the coming days.

I'm a little bit bothered because I cannot find the kudos-buttons. Maybe because this topic is too old?

Sincerely, 

[JohnMc19]

The kudos button is found underneath the contributors name and icon.

Regards,