The Paper Chase

[Tom Bress]

QUOTE (TobyD @ Aug 28 2008, 03:54 PM)

Good exercise by the way - I learned some new things :thumbup:

Nice work. Your application fulfills the requirements and the spirit of the exercise. But I'm going to ask you to make one more attempt at it.

In your solution you use a functional global to communicate between the loops. That works, but it is not the way that it is demonstrated in the Advanced I materials or in the LabVIEW Style Book. There is a way to set up the architecture so that you don't need the functional global. That makes the app simpler and in better style.

You probably figured out that if the error occurs in the producer loop it is pretty straightforward to shut down both loops. That's because the whole point of the producer-consumer architecture is that the producer communicates with the consumer through the queue. The real problem occurs when the error occurs in the consumer loop. There is no built-in method (like the queue) for the consumer to communicate "up-stream" to the producer to shut the producer down. In your app you used a functional global to do this. Instead, try to take advantage of the event structure in the producer loop. Make the consumer loop do something that the producer loop event structure will recognize and respond to.

Here are two possible ways to do this. One way is to use the Value(Signaling) property of the Stop button. Another is to generate a user event in the consumer loop that the producer loop can respond to. My suggestion to you is to try the exercise once more and use one of these methods to shut down the loops on error instead of using the functional global.

Again, good work! I'm glad that you are finding this exercise helpful.

[JiMM]

QUOTE (TobyD @ Aug 26 2008, 12:24 PM)

Sure. Here is what I did (saved as 8.0 and with a pretty icon added). I think the most important thing with documentation is to make sure every control or indicator on the front panel has a description and Tip Strip filled in and that every significant wire has a label. It is also critical that every subVI has a description. In this case, I didn't use any subVIs, but my main vi should have a description.

As Tom mentioned, if this were for certification, it should also be done in a project and be well commented. One more piece of advice - fill in the descriptions and tip strips as you go. You probably won't have time at the end to go back and add them and documentation is the easiest 10 points on the exam.

http://lavag.org/old_files/post-8758-1219767455.vi'>Download File:post-8758-1219767455.vi

Thanks Toby, I am trying to improve my commenting skills (i.e. hammering it into my head to DO IT!). The project aspect is probably going to be the biggest challenge for me. I do 99% of my work in 7.1, so I have not really used projects. When I got 8.0 I was confused by them, and I need to learn more about them. Do you know of any resources with detailed information about them? The info included with LV is pretty crappy (as usual).

Tom, thanks for your input and analysis on this.

[Darren]

QUOTE (JiMM @ Aug 31 2008, 11:00 AM)

The info included with LV is pretty crappy (as usual).

Can you qualify that statement? I'm (obviously) biased, but I feel the LabVIEW documentation is some of the best I've ever encountered in the software world. I didn't immediately jump on the project bandwagon in 8.0, but when I eventually did, I found its use and documentation pretty straightforward. If you had problems, with the project documentation or anything else, please report it on the http://forums.ni.com' target="_blank">NI Forums so our Applications Engineers can file bug reports (CARs) so we can make the documentation as good as possible.

-D

[Michael Aivaliotis]

QUOTE (JiMM @ Aug 31 2008, 09:00 AM)

The info included with LV is pretty crappy (as usual).

QUOTE (Darren @ Aug 31 2008, 03:17 PM)

Can you qualify that statement? I'm (obviously) biased, but I feel the LabVIEW documentation is some of the best I've ever encountered in the software world.

Correct me if I'm wrong, but I think what JiMM is looking for is documentation on why the heck anyone should use the project (besides the obvious: "to build an exe").

Yes, it's a neat way to organize your VI's but an OS folder can do that too. One of the primary benefits for me has been the ability of a project to wrap your code in a project namespace. You can open two or more projects at the same time and VI's within those projects can have the same name but you won't have the problem of cross-linking. One word of caution on projects. If you decide to use projects, you MUST use projects all the way. What I mean is that the very first thing you open, to start your work, must be the project file, not the VI. It's the boss.

[Darren]

QUOTE (Michael_Aivaliotis @ Sep 1 2008, 02:16 AM)

Correct me if I'm wrong, but I think what JiMM is looking for is documentation on why the heck anyone should use the project (besides the obvious: "to build an exe").

I was primarily responding to the "as usual" comment. Anyway, my favorite use of the project is the built-in SCC. Being prompted to check out a file that I don't have checked out whenever I start trying to edit it is really handy.

-D

[crelf]

QUOTE (Michael_Aivaliotis @ Sep 1 2008, 03:16 AM)

...I think what JiMM is looking for is documentation on why the heck anyone should use the project (besides the obvious: "to build an exe").

I like that the project space doesn't have to mimmick the disk space. Most of us (pre-project) specifically design a disk-based layout that's intuitavely traversable by humans, but that doesn't necessarily mean that programming objects are logically arranged. The project gives me a layer of abstraction from the disk space, so I can arrange things however I like. I think this is one of the least-talked-about features of the project environment, but I love it. I also suggest that this is where the overall computing world is going...

[LAVA 1.0 Content]

QUOTE (JiMM @ Aug 31 2008, 06:00 PM)

... When I got 8.0 I was confused by them, and I need to learn more about them. ....

QUOTE (Michael_Aivaliotis @ Sep 1 2008, 09:16 AM)

Yes, it's a neat way to organize your VI's but an OS folder can do that too. One of the primary benefits for me has been the ability of a project to wrap your code in a project namespace. You can open two or more projects at the same time and VI's within those projects can have the same name but you won't have the problem of cross-linking. One word of caution on projects. If you decide to use projects, you MUST use projects all the way. What I mean is that the very first thing you open, to start your work, must be the project file, not the VI. It's the boss.

QUOTE (Darren @ Sep 1 2008, 10:03 AM)

I was primarily responding to the "as usual" comment. Anyway, my favorite use of the project is the built-in SCC. Being prompted to check out a file that I don't have checked out whenever I start trying to edit it is really handy.

QUOTE (crelf @ Sep 1 2008, 06:02 PM)

....The project gives me a

layer of abstraction from the disk space

, so I can arrange things however I like. I think this is one of the least-talked-about features of the project environment, but I love it. I also suggest that this is where the overall computing world is going...

I've started a seperate thread on (needed) project enhancements in the LabVIEW wish list.

Ton

[TobyD]

QUOTE (Tom Bress @ Aug 30 2008, 12:27 PM)

Nice work. Your application fulfills the requirements and the spirit of the exercise. But I'm going to ask you to make one more attempt at it.

In your solution you use a functional global to communicate between the loops. That works, but it is not the way that it is demonstrated in the Advanced I materials or in the LabVIEW Style Book. There is a way to set up the architecture so that you don't need the functional global. That makes the app simpler and in better style.

Thanks again for the feedback Tom. I finally had a bit of time today to go back and look through my LabVIEW advanced course material and the Chapter in the LabVIEW Style Guide on error handling. I read up on the methods you recommend in the LabVIEW Style Guide, but I was also pleasantly surprised to find that the method I used with a functional global variable is actually very similar to the method used in the Advanced course material. Although their implementation is somewhat cleaner than mine, they recommend using a FGV that gets called in every iteration of the producer and consumer loop to handle any errors (either shut down the loops or fix the errors).

Based on http://www.copyright.gov/fls/fl102.html' rel='nofollow' target="_blank">this information, I think it's OK for me to post a brief excerpt of the manual for commentary purposes. This is on page 6-13 of the LabVIEW Advanced 1 Architectures Course Manual, May 2006 Edition (Part #324385A-01)

QUOTE (LabVIEW Advanced I Course Manual)

A powerful way to create an error handling mechanism is to use the capabilities of the functional global variable. The FGV stores the errors that it has received...You can create code inside the FGV that sends shutdown messages to the rest of the architecture if an error is received. You only need to send a shutdown message for the first error that is received. You could also create code that implements a routine to fix the error...When you create a shutdown routine, your error handling VI needs to clear the errors that the system detects in order for the common shutdown VIs to execute.

After creating the FGV, call it at the end of every state in the architecture to appropriately handle any error that might have occured.

There are some small things I would change in version 2.1 of my code, but I like the ease of the FGV and it seems to be a method that is encouraged by NI.