Jump to content

The Paper Chase


Recommended Posts

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.

Link to comment
  • Replies 57
  • Created
  • Last Reply

Top Posters In This Topic

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

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.

Link to comment

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

Link to comment

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...

Link to comment

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

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)

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

Link to comment
  • 2 weeks later...

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

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.