Sample Exam Solutions for Review

[JÞB]

Helen. I'm mobile now. I will go through the code later.

I assume:

you ran VI analyzer yourself.

you have read cld tips on the cert board.

[JÞB]

Overall nice code.

You have some Functional reqs you missed.  Nothing major there some reqs might not get finished and your comments in a well chosen design pattern will provide the right info to the graders.

You did not add the vi's to the .lvproj.  Use that project explorer and work withing the project context.  This is Core I mod 2 material!  You probably learned bad habits developed before the .lvproj existed.  you have 4 days to unlearn that and master a basic LabVIEW skill. 

Error handling in sub-vis-  its not enough to run the error chain through your FGV!  start with the sub-vi with error handleing template.

PC-Events.  This is a bit trickier to understand.   As a rule of thumb: If the consuming Queued Message Handler also enqueues to self Use enqueue opposite end in the producer.  This ensures commands generated by user activity process immidiatly and are treated with the priority they deserve.

Good Luck on Friday

[HelenC]

Hi Jeff,

Thank you for the review.

I have mixed feeling about fully passing error in/out through case structures that don't have any error terminals in them, such as basic memory cell FGV, though take on board your points.

Cheers,

Helen

[JÞB]

---

@HelenC wrote:

Hi Jeff,

Thank you for the review.

I have mixed feeling about fully passing error in/out through case structures that don't have any error terminals in them, such as basic memory cell FGV, though take on board your points.

Cheers,

Helen

---

I have some mixed feelings about it as well,  But its your point that the grader will take off for style (they really want to see error/ no error cases in all sub-vis)

[HelenC]

Hi Jeff,

Re.

I have some mixed feelings about it as well,  But its your point that the grader will take off for style (they really want to see error/ no error cases in all sub-vis)

It might be nice for NI to give some advice about this, as during a CLD Prep class I attended in November 2013 it was suggested by the instructor that for memory cell FGV, where an error won't affect the data, thT putting in it in an error case is overkill and just passing the error wires through the VI is OK.

For the sake of a point I'll definately do as you suggest, but some clarification by NI would be helpful for others following this post in the future.

Helen

[Mark_Yedinak]

As a general rule of thumb I always include the error in/error out terminals in subVIs, even when the error is simply passed through. The two exceptions are simple string processing or simple calculations. The overall code style is more consistent when they are included.

[Daniel_H1]

We recomend using the error cases in subVIs, even for simple calculations in which an error won't affect the data. This is for several reasons:

1) To Mark's point, it makes for a consistent style

2) If you need to add to the code later, you'll already have the structures in place to properly pass the errors

3) By having the error/no-error cases in place, it helps skip through execution as fast as possible until it reaches your error-handling code (where you actually do something meaningful with the error information).

While I'll admit that the functional advantages of the error case may be minimal for extremely simple subVIs, it is a best practice that you should follow and we do check for it on the exams. Jeff makes a good point that if you start with the "SubVI with Error Handling" template, you shouldn't have to worry about it.

Cheers,
Daniel 

[billko]

---

@Daniel_H1 wrote:

We recomend using the error cases in subVIs, even for simple calculations in which an error won't affect the data. This is for several reasons:

1) To Mark's point, it makes for a consistent style

2) If you need to add to the code later, you'll already have the structures in place to properly pass the errors

3) By having the error/no-error cases in place, it helps skip through execution as fast as possible until it reaches your error-handling code (where you actually do something meaningful with the error information).

While I'll admit that the functional advantages of the error case may be minimal for extremely simple subVIs, it is a best practice that you should follow and we do check for it on the exams. Jeff makes a good point that if you start with the "SubVI with Error Handling" template, you shouldn't have to worry about it.

Cheers,
Daniel 

---

It kind of defeats the purpose of "Create SubVI" though, doesn't it?  It was so nice back when all you had to do was click the "Create SubVI" and then the cleanup button and there you go...

[HelenC]

---

Daniel_H1 wrote:

We recomend using the error cases in subVIs, even for simple calculations in which an error won't affect the data. This is for several reasons:

1) To Mark's point, it makes for a consistent style

2) If you need to add to the code later, you'll already have the structures in place to properly pass the errors

3) By having the error/no-error cases in place, it helps skip through execution as fast as possible until it reaches your error-handling code (where you actually do something meaningful with the error information).

While I'll admit that the functional advantages of the error case may be minimal for extremely simple subVIs, it is a best practice that you should follow and we do check for it on the exams. Jeff makes a good point that if you start with the "SubVI with Error Handling" template, you shouldn't have to worry about it.

Cheers,
Daniel

Thank you Daniel for affirming what Jeff said.

Helen

---

[JÞB]

Daniel,

Thanks for "The Word"  saves me a bit of typing. 

I'm starting a new discussion about possible updates of best practices for this board