Certification

cancel
Showing results for 
Search instead for 
Did you mean: 

Sample Exam Solutions for Review

Hi FireGiant,

 

It looks like that upload has only the .lvproj file in it. I meant that it would be easier if you zipped all of the project contents (.lvproj, .vi, etc.). 

0 Kudos
Message 511 of 623
(4,676 Views)

Sorry my brain must be a little fried after the early test HA. I can use zip files i promise. Let me try this agian here.

0 Kudos
Message 512 of 623
(4,668 Views)

It looks like the program functions as intended, good job! Here are a couple things to work on:

  • Block diagram is very large, try not to leave so much white space that you have to scroll to see the code.
  • Lower loop should have some kind of wait in it, otherwise it hogs resources and the timer is just a blur
  • I would put control references into a cluster rather than array.
  • Some unnecessary bends in the wires.
0 Kudos
Message 513 of 623
(4,657 Views)

Great advice thank you Gregory for taking the time to look it over and offer feedback. I'm doing the Sprinkler Controller tomorrow and will have to keep these is mind as I go. I do rely completely on auto cleanup due to the time contraints unfortunatly and I will have to figure out what settings I've got that are causing such janky wiring in places. The VI for sure just kept expanding and expanding every time I cleaned it up.

0 Kudos
Message 514 of 623
(4,646 Views)

Auto clean up works well enough on small VIs, but I would never touch it on a top-level VI!

0 Kudos
Message 515 of 623
(4,639 Views)

You'll loose a lot of points on the lack of documentation, and some on style.

 

The VIs don't have any meaningful documentation ("Use this template to build a VI to use as a subVI." isn't it). You only have two (which might not help in goodwill), better make them count.

 

The code has no comments whatsoever. At least use Subdiagram labels. This is a big one.

 

Wires have unneeded bends.

 

Errors are not wired on lots of nodes (Enqueue element, disable property node, SubVIs). Now, I'm not a fan of that if they are obviously redundant, but you will loose points.

 

Why on earth would you poll the stop in a time out, while the button has a value change event? Ah, you're setting the stop in the consumer... Why not simply ditch the producer loop altogether and poll the stop in the consumer loop? The producer doesn't really do anything too useful. If you'd use a value signaling property node instead of the local, the time out case wouldn't be needed.

 

You'd better be absolutely sure you'll get 100% on functionality, because you'll need those points.

 

IMHO, of course.

 

Here's some ideas to gain precious seconds:

Boiler.png

1) No need to unbundle the status.

2) No need for 'This VI' not the close. Do wire the error out of course.

3) Use a relative path to strip and build in one go.

Message 516 of 623
(4,620 Views)

Yes very true I need to leave myself more time to document or do it as I go. I also agree about the event structure and stop button polling. I mostly did that becuase my approach in general is to go for the event driven producer-consumer. It seems to me in general more robust and makes more sense to me while debugging then other design patterns I have learned so far.

 

Though in the case of the boiler specifically it seemed to be kind of overkill since I really only used it to stop the VI. Which then led to the awkward use of the timeout case. Since my stop button was responsible for a case in the producer I couldn't access the stop button value in the producer because of the nature of its mechanical action.

 

I ended up changing the mechanical action to get the VI to be able to be stopped by the consumer because variables and property nodes seem to struggle with latch actions. I assume because the variant is empty when they go to use it since they only retain value when they are first read. I'm not even sure you're allowed to change mechanical actions on the test. The general consensus seems to be that non-latching mechanical actions are kind of frowned on.

 

I thought about just linking property nodes instead of wiring references to them. I need to learn more about the topic I'm not sure what the benefits/drawbacks of explicit vs implicit referencing is.

 

As far as unbundling the error status that was actually just built into the template I used. It seems to pop up in a lot of their shipped examples in templates.

 

Great advice and thank you for taking the time to look through and help me improve my process. I'm grateful to have some time to get these wrinkles out now and the eye of experienced programmers is not a resource I take for granted. I wish I'd found this thread earlier.

 

0 Kudos
Message 517 of 623
(4,612 Views)

@FireGiant wrote:

Yes very true I need to leave myself more time to document or do it as I go. I also agree about the event structure and stop button polling. I mostly did that becuase my approach in general is to go for the event driven producer-consumer. It seems to me in general more robust and makes more sense to me while debugging then other design patterns I have learned so far.

 

Though in the case of the boiler specifically it seemed to be kind of overkill since I really only used it to stop the VI. Which then led to the awkward use of the timeout case. Since my stop button was responsible for a case in the producer I couldn't access the stop button value in the producer because of the nature of its mechanical action.

 

I ended up changing the mechanical action to get the VI to be able to be stopped by the consumer because variables and property nodes seem to struggle with latch actions. I assume because the variant is empty when they go to use it since they only retain value when they are first read. I'm not even sure you're allowed to change mechanical actions on the test. The general consensus seems to be that non-latching mechanical actions are kind of frowned on.

Good point about changing the mechanical action. Not sure if that is allowed.

 

Not sure who frowns on non-latching action. Non-"when released" is annoying though, but latch when released and switch when released would be fine in my book. Switch\latch when pressed is very annoying in typical use cases.

 


@FireGiant wrote:

I thought about just linking property nodes instead of wiring references to them. I need to learn more about the topic I'm not sure what the benefits/drawbacks of explicit vs implicit referencing is.

Not exactly sure what you mean with explicit\implicit referencing. You mean a reference wire vs no wire?

 

A reference wire (implicit?) has the benefit that you can put it in a sub VI. Or a loop, cluster, etc. The "no wire" (explicit?) property node only works in the same VI for one control. No wire would be the simple solution here (and thus preferred, IMO).

 


@FireGiant wrote:

As far as unbundling the error status that was actually just built into the template I used. It seems to pop up in a lot of their shipped examples in templates.


You will still loose points.

 

It's completely ridicules to require to wire the error our of a value or value signaling property node, unless you want\need to enforce flow. Or a Format Into String with a static format specifier. No arguing there. Some things will simply never output an error. And when they do, well, nothing will work properly anymore, including error handling... 

 

But you'll still loose points (even if you put a comment next to it)!

 

0 Kudos
Message 518 of 623
(4,601 Views)

Here was my timed attempt at the ATM Practice exam. Made a mistake early on where I was doing the withdraw comparisson with the User Input Value and the Current Balance while they were still strings so that cost me a bunch of time.

 

Still relying pretty heavily on 2014 auto cleanup and most of the Sub VI's were made at the end so sorry for a bloated and somewhat messily wired main.

0 Kudos
Message 519 of 623
(4,564 Views)

Here's the zip with everything in it. I'm posting this one from work so our firewall seems to be giving my zip file issues. Hopefully one of these works on the download end.

0 Kudos
Message 520 of 623
(4,547 Views)