09-28-2016 07:40 AM
The answer for ques 8 does not make sense. It says it should be C but I think it should be B instead. I even tried the code and B makes more sense. Not sure if anyone from NI has noticed yet.
Solved! Go to Solution.
09-28-2016 01:48 PM
The question is quite clear that neither event is set to lock the front panel. Therefore C is the correct answer.
09-28-2016 02:31 PM
Thanks for your response.
Here is the VI I created in LV 2014. When I change Two's value, VI stops responding. Am I doing something wrong?
09-28-2016 02:36 PM
@User911 wrote:Thanks for your response.
Here is the VI I created in LV 2014. When I change Two's value, VI stops responding. Am I doing something wrong?
I don't have LabVIEW on this computer, so I cannot check. But did you turn off the "Lock front panel until this event case completes" for the event case in the second event structure?
09-29-2016 06:47 AM
OK I see your point. I have never used that feature before. Thanks for your help. It all makes sense now.
09-29-2016 06:39 PM
You know what? I've allways hated the phrasing of that distractor. "...operates as expected...." is rather subjective and depends on if your expectations of the vi's operation are properly aligned with reality. In Fact, C is incorrect if you expect the the VI to exit with error or crash LabVIEW under those conditions.
09-30-2016 10:11 AM
@JÞB wrote:You know what? I've allways hated the phrasing of that distractor. "...operates as expected...." is rather subjective and depends on if your expectations of the vi's operation are properly aligned with reality. In Fact, C is incorrect if you expect the the VI to exit with error or crash LabVIEW under those conditions.
I expect it to initially do nothing if "two" is changed first, then pop the two dialogs in one-two sequence if "one" is changed afterwards. It also will operate "as expected" if the controls are operated in any order because I know what to expect. Singling out one order of operations might give the impression that it does not operate as expected depending on use, while it always does.
We also need to assume that there are no other event cases.
10-18-2022 01:55 PM
Anybody knows how this code actually functions under the hood?
I'd always assumed there's one event queue under the hood and events are processed FIFO in this event queue.
However, based on how this code works in reality, if lock front panel is disabled for both event structures, when you change Two first, event Two gets queued up first, then when you press One, somehow the first event structure managed to process event One even though event Two is in the event queue already. So does that mean each event structure manages its own queue? Or does the "pop" request from event structures do a search in the event queue and processes whatever is available? Can somebody help me solve this mystery in an episode of "How Things Work"?
Also, is it just me or is this implementation BS, and that you'd never actually implement your code this way IRL? 😂
10-19-2022 06:38 AM
@yanyi wrote:
Anybody knows how this code actually functions under the hood?
I'd always assumed there's one event queue under the hood and events are processed FIFO in this event queue.
However, based on how this code works in reality, if lock front panel is disabled for both event structures, when you change Two first, event Two gets queued up first, then when you press One, somehow the first event structure managed to process event One even though event Two is in the event queue already. So does that mean each event structure manages its own queue? Or does the "pop" request from event structures do a search in the event queue and processes whatever is available? Can somebody help me solve this mystery in an episode of "How Things Work"?
Also, is it just me or is this implementation BS, and that you'd never actually implement your code this way IRL? 😂
Each Event Structure has its own event queue based on what they are registered for. In this case, Event Case 1 will not see the "Two: Value Changed" event, but will see the "One: Value Changed" event. Event Structure 1 is performed first because it is the first in the flow to be able to dequeue from its event queue and perform the event case.
And, yes, this setup is pure BS. A single loop should only ever have 1 Event Structure. Generally speaking (there are rare exceptions), a VI should only have 1 Event Structure. But this exam is about seeing if you know how things work and will therefore have a lot of BS scenarios. Also keep in mind that the practice exam is filled with questions that were rejected for the actual exam. They are representative of the actual exam, but often worded wrong is a weird setup.