Would someone check my VI

[Robert_Schröder]

Hi,

i am currently building a VI to control a goniospectrometer. Since I am no professional programmer but a student in optical engineering and image processing, I have only basic knowledge of programming.

The "Manuell test alpha.vi" has no error, it is running without problems. What I would like to know is, is there something I could do better, streamlining the VI?

Thanks for replys,

robert 

[altenbach]

Looking at the code, it seems like you're an experienced programmer in text based languages (which sometimes is a bad thing when switching to LabVIEW ;)).

Variables

You have a huge number of hidden controls that are only used for data transfer via locals. They can all be eliminated and replaced with direct wires. (You can use probes for debugging if needed)

Dataflow (Too much and too little)

If there is data dependency, you don't need sequence structures. Things will execute automatically in order. Let's look at the case "Beschleunigung". You have a 2 frame sequence. First you read a few things from a VI, then you write them to other VIs. If you would for example wire the DMT130 output to the DMT 130 input and delete the two local vaiables you create a data dependency, the later VIs must wait until data from the firts VI is available. The sequence is no longer needed! At the same time, the DMT 130 control no longer servers a purpose and can be eliminated.

Repeat for all similar cases 😄

You have four code block in your main loop (Which is inside a "single frame" sequence that can be deleted without change in functionality). SInce there is no data dependency, there is no way to tell what executes first. You might expect that "Bewegung der Achsen" executes before "Positionsanzeige", but that is not guaranteed. Again, the sequence frame serves no purpose, It does not change anything. Use wires and possibly shift registers for all your data. Most variables can be eliminated.

Timing

Your main loop also probably needs a small wait statement, else your program will gobble up all CPU.

Coercion

You should avoid coercion. Keep your datatypes straight! You wire integers into subVIs that expect DBL. (e.g. on the very left of te diagram)

See also my earlier post on similar topics

🙂

[Robert_Schröder]

okay thanks so far, but I have two questions:

Timing

I do not understand why a single wait statement supports CPU

Dataflow

How exactly work those shift registers? How, other than sequence structure, can I guarantee, that some blocks are executed one after the other ("Menü" first), but some ("Not-Aus") can always interrupt and execute?

[Robert_Schröder]

Oh, and I have a question about variables:

I thought I use controls for starting values, which can be transfered to the executing subs, but easily changed through the use of variables. Is this possible with direct wire?

[Robert_Schröder]

• updated version of manuell test alpha

but the questions from above are still standing.

thanks

[altenbach]

---

@Robert_Schröder wrote:

I do not understand why a single wait statement supports CPU

---

A loop without a wait statement or other mechanism to slow it down will run as fast as it can, gobbling up all availalble CPU. It will typically spin many times for many milliseconds before releasing its hold so other processes such as front panel updates or parallel loops get their turn. You will notice that the FP controls and indicators might even get unresponsive for short periods of time. (In one of his blog entries, Joel Sumner explains that loops without a wait primitive will spin for 55ms before other loops that are ready to execute get a chance.)

Even a 0ms wait statement will allow everyhing to run smoother, because other processes can "interlace" after each iteration.

It really depends on how critical your loop speed is. It is probably sufficient to run e.g. 100x per second. If without wait it would execute10000x per second, a 10ms wait inside the loop will cause your application to consume only 1% of the CPU resources. This is a big difference!

Another reason is predictablility. Especially with instrument control, you don't want you application speed to be a function of computer hardware. It should run at a predictable speed on both a slow or a fast computer.

---

@Robert_Schröder wrote:

How exactly work those shift registers? How, other than sequence structure, can I guarantee, that some blocks are executed one after the other ("Menü" first), but some ("Not-Aus") can always interrupt and execute?

---

Dataflow dictates that

1.  A code element only produces output once it has finished.
2. A code element will start exeuting once ALL its input contain data.
   

This makes it easy to force execution order using wires. (See below)

---

@Robert_Schröder wrote:

I thought I use controls for starting values, which can be transfered to the executing subs, but easily changed through the use of variables. Is this possible with direct wire?

---

Many of your controls (e.g. the one mentioned above)  use fixed starting values. They get set from the output of the subVI and are then used as input somewhere else. Whatever you change on the FP has no effect, because it will get overwritten by the code anyway.

To illustrate some of the points, I made a few quick modifications:

• "LISTEP ID" Is a constant that never changes. It can be a diagram constant. It is used in several structures of the main loop, routing it across all the structures in the desired order will force a given execution order. (Use execution highlighting to verify :))
• I eliminated all local variables for the "DMT200" thread. The DIM and STEP can start out as diagram constant and then maintained in shift registers. They are changed by the corresponding menu item.
• The DMT2000 indicator can be wired outside the case structure from both cases.
• The "positionsanzeige" boolean can be treated similarly.

Of course it looks a bit messy at the moment. Yo should probably rearrange things for a more suitable layout. More comments are on the block diagram in yellow.

Local variables should be avoided if possible because:

1. they break dataflow and possibly introduce race conditions. Dataflow ensures proper execution order automatically.
2. They cause a data copy in memory (no big deal here, but inportant with big arrays).
3. They force a switch to the UI thread (I believe), lowering performance.

[altenbach]

Sorry, I was in meetings all day (including a LabVIEW user group meeting ;))

I just looked again at your latest effort and spend a few more minutes to clean up the code a little bit more.

Here are a few notes:

1. Actually, you don't need a delay, because the menu selection has a 200ms timeout by default, which provides pacing of the main loop.
2. You only need a single big case structure, both current case structures run off the same boolean so their content can be combined.
3. Most of your code in the main loop is in triplicate, one instance for each axis. To simplify, I would suggest using arrays for the various variables. Now you only need one instance of the code segments, all the parts can execute in little FOR loops. (Notice that your subVIs are not reentrant, so they will not be called simultaneously anyway.)
4. Notice that not a single local variable is left and none is needed! 🙂
5. You don't really need all these property writes. Once a control is hidden, it will stay hidden. (still I left them in place for now)
6. There are quite a few unused and hidden controls left. I guess you heve more plans for expansion, else delete them. ;).
7. I changed the info VI to controls (inputs) so it will display the current settings. It make s litlte sense to have them as indicators.
8. I intentionally created some data dependency by routing certain wires through structures so they execute in the order indicated with yellow numbers. The little FOR loop on the top left will execute some time after step [2], but its timing in relation to strp 3 and 4 is not determined. This is probably OK.
9. Yes, my version is much simpler. Compare the code size (VI properties..memory usage)!

Let me know if you have any questions! 😄

Good luck with your project. Modify as needed. (I cannot test, because I don't have your dlls and hardware. There are probably a few bugs left).

[Robert_Schröder]

Thanks, great help there.

I did some more, but I want to know if I have understand it correctly with dataflow 1-2-3-4-5 and those arrays.

[altenbach]

Yes! It looks very nice now! 🙂

One little thing. You could avoid the sequence structure [2] if you would wire the outputs from the two FOR loops through the two cases of case structure [3]. This creates a data dependency that naturally forces case [3] to wait until everything in the sequence structure has finished. Still, a single frame flat sequence is not bad and maybe helps in the diagram readbility because it provides some structuring. I would leave it as is. 🙂

Also remember the highlight execution debugging tool. Press the light-bulb button and run the VI while watching the diagram. You see exactly how things execute. Good luck!