reasons for usage of different boolean mechanical actions

[maat]

This question is mostly in regards to some questions on the sample LV Associate Developers Exam.  The questions ask which boolean mechanical actions would be most appropriate for a stop button for a Windows dialog screen and for a machine control application.  I couldn't find a good concrete answer in the LV manual, the CBT disks, application notes or in the formus; maybe someone can critique my ideas below:

Windows Dialog Stop button:  In the CBT disks (Basics I) it mentions using "Latch when Pressed" for windows dialogs.  When you click on the stop icon in a while loop and 'create control' it makes a "Latch when Released" boolean.  I have always used latch when released for my VIs.  It allows you to click on the stop button and scroll the mouse off of it if you change your mind.  Other than that I can't see which would be better.

Machine Control Application:  I couldn't find any ideas here.  Personally I think "Switch when Pressed", then change the value back in a local variable somewhere at the end of a loop iteration.  This would allow good timing if you had to do something at a critical moment?  It seems like "Latch when Pressed" would work just as well.  I don't use the Switch actions very much.

I appreciate everyones' input.  These questions seem too simple to get wrong on the test, but now that I've thought about them they seem too difficult to have one right answer!

Matt

[tbob]

I agree with using Latch when Released for the same reason, you can change your mind and get off of the button before releasing.  For machine control, it depends.  Do you want to run something as long as the switch is on, like Start/Stop?  Then use switch when released.  If you want to initiate some action then get ready for the next action (like clicking a button to take a reading), latch when released is better.  This question should not be on the test because there are too many circumstances which could dictate setting the button differently, and there is not enough information in the question to determine the answer.  In general, I would go with the latch for dialogs and switch for machine control.  The "when pressed" or "when released" would generally be when released in order to allow a user to back off before the release.

[mikeporter]

I don't know what kind response they are looking for, but in general I would have a real hard time coming up with good reasons for most of them--if for no other reason than you typically want you user interface to look like a standard PC application. If I have a dialog button I use "latch when released". If I don't I use the default.

Personally I view the others "mechanical actions" as anacronisms that the GUI design advances in more recent versions have made obsolete.

Mike...

[altenbach]

Most of the time you want to go with one of the latch buttons, preferably latch when released.

However, as you probably know, you cannot use local variables with latch action booleans, so a complex machine control application with multiple parallel loops (UI, control, services, etc.) might force you to a switch action boolean just to be able read or set it in multiple places.

(In newer versions of LabVIEW, you can keep using latch action and have multiple event structures listen to the same control. Having multiple event structures can be a bit tricky though, as discussed elsewhere. ;))

[maat]

Thanks for the ideas so far.  I agree the questions are pretty vague.  I'd like to get a good idea of what NI is looking for though, I'd hate to go into the exam with two questions wrong already...

I forgot to put a link to the exam in the first post.  It is the first 2 questions.

http://www.ni.com/pdf/custed/us/sample_clad_exam.pdf

Thanks again for everyones' ideas

Matt


(link didn't take the first time, must be firefox)

Message Edited by maat on 07-18-2005 09:58 PM

[mikeporter]

This example test is a wonderful example of why certification is so pointless. It's an amazing mishmash of incredibly easy questions in combination with questions that are absurdly meaningless.

Like question 1. What is the "most approriate" choice? Who knows!?! What is the structure of the code? What are the constraints that it's having to meet? You haven't given me nearly enough information to give an intelligent answer.

Ditto on Question 5. Any of those choices might be "most appropriate" depending on your situation.

Or question 12 -- the only correct answer is E. Don't use the Global in the first place.

Mike...

[altenbach]

---

@mikeporter wrote:

This example test is a wonderful example of why certification is so pointless. It's an amazing mishmash of incredibly easy questions in combination with questions that are absurdly meaningless.

---

Agreed. I just looked at a few of these questions, and with some I would have probably answered "z: none of the above" 😮

[maat]

I totally agree with you all, but I still need to take the test.

There was another question (On the free online sample quiz I think) which asked what level of commenting was acceptable when creating a vi.  It seems like the questions would be very situation-dependent.  It's hard to guess what answer they were looking for. 

I was hoping someone from NI would have a comment or provide some insight...

[mikeporter]

The rule of thumb I use is that if I can't understand the logic by simply looking at the screen and reading it, I put in some sort of note as a free-standing text object. Another thing to look at is how much effort did it take you to figure out how to make the code work. For example, if a driver has some bizzare setting (like it only understands 5-bit teletype characters) that is something that you will want to document very well. Ditto for bugs that you have to workaround in LV or instrument firmware. Obviously this is all highly subjective and situation dependent but you do it enough and you develop an approach that works for you.

(I have also noticed that I tend to put more detail in lower-level VIs than in higher-level ones. I'm not sure but I think that might have to do with the fact that lower-level VIs don't get revisited as often. Recently I was writing some documentation and revisited some error handling VIs I had written a long time ago (one goes back to V2!) and realized that though I use them on a daily basis I hadn't looked in side of some of them in 4 or 5 years.)

When putting notes on a diagram (or front panel) I will color it a pastel green color to help it standout a bit but not be so bright that its distracting.

Mike...