Statechart on CLD

Is the new Statechart toolkit available when taking the CLD exam?
CLA, CLED, CTD,CPI, LabVIEW Champion
Platinum Alliance Partner
Senior Engineer
Using LV 2013, 2012
Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved.

I may be mistaken but I believe you are talking about the state diagram editor add on. I agree that using the statemachine template is as good as using the state diagram editor. The statechart toolkit is a new addon that creates Harell state machines, a very nice tool but at a very high price. I was curious because I find that they statechart tool makes certain aspects of programming much easier and better stylistically, not everyone is able to use it because it does not come with the standard package. So in a way it didnt seem fair to have it available for CLD exams since it could give an advantage to someone who is familiar with it. Thank you for the feedback.
Cheers!
CLA, CLED, CTD,CPI, LabVIEW Champion
Platinum Alliance Partner
Senior Engineer
Using LV 2013, 2012
Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved.

Similar Messages

Problem with combination of LabVIEW classes (dynamic dispatch), statechart module and FPGA module

SITUATION:
- I am developing a plug-in-based software with plug-ins based on LabVIEW classes which are instanced at run-time. The actual plug-in classes are derived from generic plug-in classes that define the interfaces to the instancing VI and may provide basic functionality. This means that many of the classes' methods are dynamic dispatch and methods of child classes may even call the parent method.
- Top-level plug-ins (those directly accessed by the main VI) each have a run method that drives a plug-in-specific statechart.
- The statechart of the data acquisition plug-in class (DAQ class) calls a method of the DAQ class that reads in data from a NI FPGA card and passes it on to another component via a queue.
PROBLEM:
- At higher sampling rates, an FPGA-to-host FIFO overflow occurs after some time. When I "burden" the system just by moving a Firefox browser window over the screen, the overflow is immediately triggered. I did not have this kind of problem in an older software, where I was also reading from an FPGA FIFO, but did not make use of LabVIEW classes or statecharts.
TRIED SOLUTIONS (WITHOUT SUCCESS):
- I put the statechart into a timed loop (instead of a simple while loop) which I assigned specifically to an own core (I have a quad-core processor), while I left all the other loops of my application (there are many of them) in simple while loops. The FIFO overflow still does occur, however.
QUESTION:
- Does anybody have a hint how I could tackle this problem? What could be the cause: the dynamic dispatch methods, the DAQ statechart or just the fact that I have a large number of loops? However, I can hardly change the fact that I have dynamic dispatch methods because that's the very core of my architecture...
Any hints are greatly appreciated!
Message Edited by dlanger on 06-25-2009 04:18 AM
Message Edited by dlanger on 06-25-2009 04:19 AM
Solved!
Go to Solution.

I now changed the execution priority of all the VIs involved in reading from the FPGA FIFO to "time critical priority (highest)". This seems to improve the situation very much: so far I did not get a FIFO overflow anymore, even when I move around windows on the screen. I hope it stays like this...

Statecharts built with debug disabled can no longer be edited?

Hi. I am using the Statechart module with LabVIEW 2009. If I set the statechart code generation settings to disable debugging and then rebuild the statechart, I can no longer place functions or edit the wiring of Transition, Entry or Exit Actions. The configure statechart area behaves as if I were trying to edit the block diagram of a running VI; for example, if I click on a wire, the system creates a probe. If I turn debug back on and rebuild the statechart, I can edit the states again. For destkotp VIs, this is no big deal because I always have debugging enabled. For VIs that I want to run on the ARM Microcontroller target, this is a pain because once a statechart is added to the project, I have to make the target LabVIEW Mobile/Touch Panel/Embedded; that execution target automatically disables debugging and you can't turn it back on again. I have to edit the statechart outside of the project and save it back.
Is there some other setting in LabVIEW or in the Statechart module that I am not getting correct?

Hi pkovitz,
You are right that this is a completely separate (and unrelated) issue, so a separate post is good.
This is a bug that was introduced in the LV 2009 Statechart Module. The workaround is exactly as you described. You are right that this is cumbersome to do when using statechart on embedded because you must generate code outside of the project.
I think you can minimize the amount of editing you must do outside of the project by doing the following when you encounter the problem:
Close your project and save whatever you need to save.
Open the statechart outside of project. Change target to desktop and enable debugging.
Generate code for statechart. Now change target to windows mobile/touchpanel/embedded and save your statechart. Close your statechart
Reopen your project. You should now be able to edit your guard/action VIs until the next time you generate code.
I realize this isn't the best solution/workaround, and I apologize for the issue and inconvenience. If you find this impedes your workflow too much, let us know and we can see if there are perhaps some better workarounds. We realize this can be a big inconvenience for our users so I assure you the bug is getting appropriate attention.
Thanks,
Nick

Will I lose points on the CLD Exam if I use a Launcher vi in addition to the provided Front Panel?

Hi!
In this thread: https://decibel.ni.com/content/message/50512#50512, MattP directed me to this Certification Board.
If I use the Actor Framework in a CLD exam, will I lose points for launching the Front Panel? For two specific examples of what I mean, please refer to the solutions submitted here:
ATM: http://forums.ni.com/t5/Certification/Sample-Exam-Solutions-for-Review/m-p/2380868#M728
Boiler: http://forums.ni.com/t5/Certification/Sample-Exam-Solutions-for-Review/m-p/2385580#M738
Thanks!
Solved!
Go to Solution.

Hi,
You will not loose points for using the launcher, and not documenting the message classes. The folder structure is also fine.
Do document the other VI's, actors,and SubVI's. Remember be brief with documentation.
Mark Ramsdale
Project Manager and CLD
Customer Certification and Training at National Instruments

New LabHSM Toolkit - Agile development of complex event-driven maintainable LabVIEW applications with active objects / actors based on a universal Hierarchical State Machine / statechart template.

Dear Fellow LabVIEW programmers:
Most of the systems you deal with are reactive. It means that their
primary function is constant interaction with their environment by
sending and receiving events. But most likely, they can have something
happening inside them too, even when they are not processing messages
received from outside. So, such systems have to continuosly react to
external and internal stimuli. Right? Moreover, most likely, they
consist of subsystems that are reactive too and, in turn, can have
their own "life", to an extent independent from other parts (with
which they still communicate, of course). Reactive (event-driven)
systems are more naturally modeled with active objects. So, why then
should we try to model and code them with GOOP and its passive
("dead"!) objects?
"Flat" State Machines have been known for decades to have severe
limitations. It's been more than 20 years since Dr. Harel invented
Hierarchical State Machines (statecharts) to fight those limitations.
Then why does NI still tout the same old good Moore FSM as the
ultimate tool for event-driven programming in LabVIEW in its $995
State Diagram KIt?
The LabHSM toolkit we are happy to present, makes it possible to
easily create and then maintain complex event-driven applications in
LabVIEW as a collection of HSM-driven active object VIs using a higher
level of abstraction and agile software development methodologies.
These active object VIs are created based on a universal Hierarchical
State Machine ( HSM or statechart ) template. So. all your code looks
similar regardless of its functionality!
We all love just jump to code, right? However, to be good boys, we
need to do design first. Then implement it in code. If the logic is
modified we need to redo the design first and then redo the code. When
using LabHSM where behavior information is abstracted into a separate
HSM data file editable with a supplied editor, there is no need for
coding separate from design any more. The modified behavior becomes
code automatically as soon as the HSM file is saved. Design is code!
The implementation basically follows Dr. Samek's Quantum Programming
paradigm. (see http://www.quantum-leaps.com). However, as already
mentioned, LabHSM stores the behavior information in a file separate
from the code itself. It also adds state dependent priorities to
events, a separate queue for public events/messages, and, of course,
some LabVIEW specific code like capturing front panel user events and
putting them into the private Events queue. Communication and
instantiation functions are also rather specific for LabVIEW.
It is available for UNLIMITED PERIOD trial. Please visit
http://www.labhsm.com for details and download. The site also contains
references which you may want to check to learn more about
hierarchical state machines and active object computing.
Since this is our debut we will appreciate any comments and
suggestions. Our contact information is available on our site, of
course.
Have a G'day!

Symtx is currently hiring the following position. Please contact me if interested.
Amy Cable
Symtx, HR
[email protected]
Symtx, the leading supplier of functional test equipment, hires the brightest & most talented engineering professionals to design & manufacture complex custom electronic systems for advanced technology leaders in the defense, aerospace, communications, medical, transportation & semiconductor industries. Symtx’ challenging & dynamic work environment seeks to fill openings with highly qualified electronic engineering design professionals.The ideal candidate will be responsible for defining the requirements, software design and code development, and integration of test control software for custom functional test systems. Candidate should be familiar with data acquisition concepts, instrument control, complex test, measurement and calibration algorithm development and definition and implementation of control interfaces to hardware. Prefer familiarity with instrument control via GPIB, VXI, MXI, RS-232 desirable. Requires BS/MSEE and 3 -7+ yrs of experience in one or several of the following test applications in a Windows NT/2000/XP environment using Labwindows CVI, TestStand, Labview, Visual Basic, C++ and knowledge of RF systems is a plus. Job responsibilities will include software design, development, integration, team leadership, and interfacing with customers( includes PDR’s & CDR’s).

Finished taking Sprinkler CLD Practice Exam

I am planning on taking my CLD this coming week, and just finished taking this practice exam. Since I studied the car wash and ATM solutions I decided to go for the Sprinkler practie exam. The "Sprinkler CLD.zip" file is the results of 4 dedicated hours of my Saturday.
I ran the VI analyzer on all VIs and CTLs and I'm not impressed with myself. Could somebody tell me how they think I would score?
I looked at the solution for the Sprinkler.vi and it's clear that my approach is nothing like the solution from NI. This could be a good or a very bad thing.
It appears quick comments could mean alot if the graders depend heavily on the VI Analyzer. It appears that I should have at least two comments in each VI, and not only have the documentation section filled in the VI but the same for controls.
It's clear that I missed some wires when I resized my case select boxes.
After finishing the exam and then looking back i see there is a possible lock out condition on initialization that would prevent the VI from reading the CSV file. I shouldn't have created a "READ CSV" State. If i would have placed the "READ CSV FILE" inside the "Power Up Configuration" state there would be no issues. I should have restarted labview in my last hour. If the VI starts up with the Water Pressure above 50% and No Rain then the CSV file is read and there is no problem. This would have been an obvious mistake had I restarted labview.
I realize that I missed some of the specifications. For example if it starts raining during a sequence it is suppose to restart the sequence, not pause it.
There are few comments in the code. I usually add many comments to my code, but this is my first time using a simple state engine.
At work I have a large infrastructure already in place complete with error handling and task management. I am also use to working on multiple monitors. During the test I only used one. Even if I didn’t pass this practice exam at least having a dry run outside my normal work condition was very good practice.
I spent time practicing earlier and can build the Timer.VI in about 8 minutes. A functional global timer seems to be a common theme in the practice exams.
Does anybody have any ideas or suggestions?
Do you think I would have passed the CLD exam with this test?
Comments?
Regards,
Attachments:
VI Analyzer Results.zip ‏4 KB
Sprinkler CLD.zip ‏377 KB

There are a lot of good things in your code, you are nearly there. I haven't run your code, so this is more style and documentation comments.
If I were you, I would concentrate on the following:
Wire Error through all your subVI's put your subvi code in an error/no error case structure. If you had done that, you didn't need the flat sequence structure in your code.
You haven't even wired error to the subvi's with error terminals, this will cost you points.
Label any constants on the block diagram.
Brief description of Algorithm on each VI block diagram.
You could have avoided using local variables, for example Run Selector as this control is available in the cluster. So just a unbundle by name would have given you the value of that control. If you do use them, then make sure you state why (for example efficiency etc.) in a block diagram comment.
Some subVis are missing VI documentation, this wont be taken lightly.
Using default value when unwired (for your while loop stop) is not recommended. This was specifically discussed during a CLD preparation class I attended not so long ago.
While icons are pretty, I wouldn't waste time trying to find glyphs for your subvi's just consistent text based icon scheme is perfectly acceptable. You can do this if you do have extra time, it wont fetch your extra points though.
LabVIEW 2012 has sub diagram labels, you can enable this by default in Tools>>Options, adding comments in each of the cases is recommended.
The main thing is time management and make sure you read other posts/blogs on CLD. I would also recommend quick drop, if you haven't started using this it may not be a good idea to do so now for your exam next week. But in general it is very useful and saves time.
Hope this helps.
Beginner? Try LabVIEW Basics
Sharing bits of code? Try Snippets or LAVA Code Capture Tool
Have you tried Quick Drop?, Visit QD Community.

MY LVOOP solution to CLD- Security System

Hi All,
Today , I gave a shot at the security system example from CLD. I did it using LVOOP. Do leave your comments on the code. (I havent done much documentation. Also, I have given the flexibility to the program to log file in any format, as per extension entered by user. The code has been written in a hurry, so pls ignore any cleanups of BD remaining ).
Thanks in advance!
-FraggerFox!
Certified LabVIEW Architect, Certified TestStand Developer
"What you think today is what you live tomorrow"
Attachments:
Test_Security.zip ‏100 KB

Pretty good all in all, some comments though.
They like comments and descriptions in controls and indicators, points are deducted for not having this.
They also like block diagram constants to be labelled (again points off for not doing this).
Your error cluster is not handled too well, if there is an error in any of the states it will just propogate through continuously, probably not what you want. I think the app is supposed to stop on error (cant remember exactly).
The Array local variable in the "get status" state is unnecessary, you could just move the control outside, into the while loop. Locals are generally discouraged.
In the "get status" I would not recommend hiding the index display of the string array you are passing on. At first glance it seems the same state is being queued regardless!
You are not closing the file reference.
One thing to note, my CLD was a lot longer than the pratice examples (a lot!, and I code quite quickly).
Good effort though!
nrp
CLA

Statechart intstances in for loop

Is it possible to use a FOR loop to create multiple instances of an asynchronous statechart?
See attached code, it works fine with only one instance in the array, but as soon as one expands the array to two instances, error 1100 occurs.
Thanks in advance...
Attachments:
statechart in for loop.zip ‏293 KB
statechart in for loop.jpg ‏102 KB

Here is a quick and dirty example.
For this example, I chose to use a synchronous statechart because it actually translates much more naturally to the idea of spawning several instances of a statechart and then talking to the instances. You can use an asynchronous statechart as well, but it makes the spawning and talking processes significantly more complicated/involved (I can talk more about that in another post if anyone is really interested). Anyways,
In the attached files, spawner.vi is the top-level VI. It begins by creating a number of instances of a simple statechart. The statechart doesn't do much. It just throws up a one button dialog with a particular string when a certain transition is taken.
With the instances spawned, we then enter into a while loop with event structure, which waits for user input to cause us to talk to one of the statecharts. You can pick which statechart to talk to (numbers 0,1,... n-1, if you spawned n statechart instances). When you press the talk button, we will send a "SayHi" trigger to that statechart. It will take one step and throw a dialog telling you hi and what statechart number you are talking to (to prove you are actually talking to different statecharts).
Hope that helps. Let me know if any of it isn't clear.
Attachments:
spawn_example.zip ‏240 KB

Do i need 2010 to practice for CLD? I currently have 2009.

Hi All,
Well i finally got round to doing my CLAD yesterday and passed, Yipeee! Also by coincidence became an 'Active Participant' on this forum, Like all my christmas's coming at once.
I had to do the CLAD as i am planning on doing the CLD exam in a couple of weeks. My question is this: I have LabVIEW 2009 but the test im sure will be in 2010. Are there that many differences that i should download an evaluation version of 2010 to practice or will i be ok using what i have?
Im just worried that i turn up and waste an hour navigating 2010. If the layout and pallets are similar to 2009 then i think i will be ok.
Thanks in advance for your help.
Lucither
"Everything should be made as simple as possible but no simpler"
Solved!
Go to Solution.

Thanks everybody for your input. Am now more confused then before!
My main concern was to do with the layout of 2010. I was worried it would be like going from word 2003 to word 2010, i still struggle to use the latest version of word as i have always stuck with 2003 on my computer. From what i hear this is not going to be a problem. I am reluctant to get 2010 just for the CLD as i have no intention of buying 2010. Im sure if i downloaded the eval version i would like it and knowing my level of will-power i will be forced to part with a lot of cash.
Thanks again for your advice.
Regards,
Lucither.
"Everything should be made as simple as possible but no simpler"

Design practices from the CLD Exam Prep Guide

    I have a question about design practices as stated in the CLD Exam Prep Guide found at   http://ftp.ni.com/evaluation/certification/cld/cld_exam_prep_guide_english.pdf
   Please refer to statements
2.e.1. Set the value or attributes of a control, statically using the property dialog box of an object, or dynamically using Property Nodes.
2.e.2. Initialize or set control values at application, load, start, and stop.
4.a.4. Use local variables to update controls.
   Because the words initialize and set and update all mean to change the value and two different methods are suggested to do so, I first saw this as contradictory. Assuming there is no contradiction, it should be very clear when, where, and why each method is used.
   From section 2.e I understand this to mean you should change (set) a control value at application, load, start, and stop by using Property Nodes. Thus, application, load, start, and stop shall be clearly identified within your block diagram to avoid misunderstanding.
   From section 4.a I understand this to mean you should change (update - as you might do repeatedly within a while loop) a control value by using local variables everywhere else in your block diagram. If I understand this correctly, there is no contradiction. Otherwise....
Please advise! Scott Pierskalla
Certified LabVIEW Associate Developer

spiersk wrote:
    I have a question about design practices as stated in the CLD Exam Prep Guide found at   http://ftp.ni.com/evaluation/certification/cld/cld_exam_prep_guide_english.pdf
   Please refer to statements
2.e.1. Set the value or attributes of a control, statically using the property dialog box of an object, or dynamically using Property Nodes.
2.e.2. Initialize or set control values at application, load, start, and stop.
4.a.4. Use local variables to update controls.
   Because the words initialize and set and update all mean to change the value and two different methods are suggested to do so, I first saw this as contradictory. Assuming there is no contradiction, it should be very clear when, where, and why each method is used.
   From section 2.e I understand this to mean you should change (set) a control value at application, load, start, and stop by using Property Nodes. Thus, application, load, start, and stop shall be clearly identified within your block diagram to avoid misunderstanding.
   From section 4.a I understand this to mean you should change (update - as you might do repeatedly within a while loop) a control value by using local variables everywhere else in your block diagram. If I understand this correctly, there is no contradiction. Otherwise....
Please advise! Scott Pierskalla
Certified LabVIEW Associate Developer
Scott,
Thank you for drawing my attention to this thread. I understand your confussion but, there is no contradiction. I will attempt to clairify the statements.
Section 2 addresses design of the GUI or, how to set up the user experience. Several questions any developer needs to ask are:
Is the data represented correctly? (what data type is needed?)
How will the user change this data? (Enum / Ring / Combo box pull-down, maybe the increment / decrement buttons, Perhaps direct text entry from the keyboard? If so do we wish to update value while typing or end text entry with "Enter"?)
How can I make it "Pretty?" (What colors are approachable, how can I present logical groupings of the data the user needs....?)
Section 2 is all about the user. Your application will be used by users and, they need to interact with your product. Design the interface correctly and they will never notice, design it poorly and they will wish to break you nose because the software just does not "FEEL" right.
Section 4 addresses Programing practices.
Avoid Localitis
Avoid sequenceitis
don't ABUSE Globals
use common design patterns
Basically "Write Software" not "Functional spaghetti code"
Writting "Good Software" in LabVIEW is one of the things that CAN BE DONE with LabVIEW. Unfortunatly, because LabVIEW is often approached by people with no understanding of Software Engineering principals, many LabVIEW applications fall into the "Functional Code" bucket and are poor "Software".
The CLD exam will require you to domenstrate that you can apply software engineering principals in the LabVIEW IDE.
Good Luck- Sling some wires!
Jeff

Passing data to a StateChart

I wanted to have a delay in a statechart that could be interrupted by the user,
but it seemed that I could only pass data with a trigger or in a transition, but
this wouldn't work if the statechart was idling in a timer state.
So here's what I found:
"Interval" and "Delay" control a timing loop inside the statechart.
You can change the values here and watch the "Time" and "Count"
parameters speed up and slow down as "Interval" and "Delay"
are changed. The data is passed back and forth between this vi
and the statechart through Data.vi, ReadData.vi, and WriteData.vi.
The idea comes from "A Software Engineering Approach to LabVIEW"
where they show how a loop with a shift register with a uninitialized
input stores its value in memory. Using this idea, I put a cluster in
a case structure (Data.vi) and this allows me to pass data between
this vi and the statechart. This gets around the problem of needing a
trigger or transition to send info to or from a statechart. The "Timeout"
case of the event structure in Top.vi sends and receives the data
through Data.vi at the timeout rate wired to it.
This structure uses a synchronous statechart and a queue to pass
triggers to it (an idea I got off the Labview forum), but you could
probably replace the synchronous statechart with an asynchronous
one, but I haven't tried it yet.
I'm new to Labview and statecharts so any feedback is appreciated.

Thanks,
I tried to attach a zip file of the project but it doesn't seem to take the attachment.
Is there something I need to do to have the post accept the attachment?
Tim.
Attachments:
StateChartTimer5.zip ‏552 KB

CLD Complete Study Material

First I would like to thank NI and all the community members for sharing their knowledge about LabVIEW CLD Certification since it helps me to complete my CLD Certification and also to get 92.43%...
In this post I would like to share all the link and document which made me succeed...
1. NI Exam Preperation Video
http://www.ni.com/tutorial/14554/en/
2. Preperation E Kit (contains 17 Lessons and 4 sample exams)
https://lumen.ni.com/nicif/us/ekitcldexmprp/content.xhtml
3. Free NI Core 3 Lesson 1 to 10 from NI UK (one of the great resourse)
https://www.youtube.com/user/nestorceron/videos
4. SIX Clear Videos (Really makes learner Clear in LabVIEW)
https://www.youtube.com/user/Sixclear/videos
5. Tips from LabVIEW Artisan
http://labviewartisan.blogspot.in/2009/01/labview-certification-preparing-for-cld.html
6. Tips from NI Community
http://forums.ni.com/t5/Certification/CLD-Tips-you-can-t-have-too-many/td-p/2145314
https://decibel.ni.com/content/blogs/labview-news-english/2013/01/25/how-to-prepare-for-the-cld
Books Available in Market
LabVIEW for Everyone Jeffrey Travis, Jim Kring
LabVIEW style guide Peter A. Blume
LabVIEW advanced programming techniques Rick Bitter, Taqi Mohiuddin, Matthew Nawrocki
LabVIEW Graphical Programming Gary W. Johnson, Richard Jennings
NI CORE 1,2,3 Manuals
The list goes on... I would like to say many techniques can be learned from the sample exam code which are posted for the review... It is also great to see how some one is making a different solution for the same problem we have solved...
My Linkedin id - http://www.linkedin.com/pub/varaprasath-m/51/679/1b9
Thanks & Regards
Varaprasath M
Certified LabVIEW Developer
Certified TestStand Developer

Hi,
One more link, for CLD preparation webcast.
CLD Prep webcast
Also, the first link you have posted, the videos, goes with the CLD success Package exercises.
Congratulations on the CLD.
Mark Ramsdale
Project Manager and CLD
Customer Certification and Training at National Instruments

Controlling front panel properties from within a statechart

I have a user interface that I am trying to put into a statechart. On the user interface I have a bunch of buttons (controls) and indicators. To populate the indicators I am getting data back from 2 sources (USB and RS 232). For this, I have made shared variables for the data returning from the sources but this only works for indicators as far as I can see. Anyway, I have the software working and now that I am trying to go back and place the code into the statechart format to clean it up I am running into issues. Since the statechart does not run inside the labview panel I can not access the front panel properties of controls. Basically, I am using the statechart to control which buttons are active on the front panel (this is dependent on the state the user is in). Also I am using the states to control a LabVIEW “tab control” to determine which tab to display. For instance, I have an operate screen and a calibrate screen. Depending on which state the operator is in, different controls are active (I don’t want the user to accidently change an item on the operate screen while in calibrate). Is there a way to do this inside the statechart structure?

You don't actually copy the reference itself. Rather, you want to add a control of the same type as the reference to your statechart Inputs.ctl. You can get such a control by right clicking on the reference you created and choosing "create control".
Then you pass in the reference to your specific control into the statechart via the inputs terminal. You can then talk to this reference via VI server and manipulate the original control.
If this isn't clear probably the best thing to do is to look in the LV help index for the keyword "control references" and read about "passing to subVIs". Passing a reference to a subVI is very much like passing one to a statechart so most of this is relevant.
Hope that helps.

CLD: timer expressi VI or my own functional global VI?

Hi all,
I'm preparing for CLD exam. I had a look to preparation kit exercises and a couple of exam samples.
It seems that exam often requires the use of a Timer (a simple timer or a "pausable" timer).
In order to save time during CLD exam,may I use the Timer Express VI without a point deduction?
Thanks all

You can use the Timer express VI, if you feel you will run out of time. Else create your own according to the requirement in an Action Engine. In case you have to pause the timer, then you have to build a logic outside the Timer express VI which is again a double work.
The best solution is the one you find it by yourself

Timing CLD practice exams

Hi,
I wanted to bring up this topic for those who are preparing for taking the CLD.
As you know there is a four hour limit for taking the exam. While preparing for the exam, using all the materials, webcast, and the certification discussion board, it is important ... , no critical, to clear your schedule and time yourself for a four hour exam. Twice.
Many developers get caught in the time crunch, both in their daily activities and in the test. Putting yourself in the position of having to face a hard deadline for completing the exam is a great wake up call. You don't want that call to be during the actual exam.
Timing your practice exams is a great way to experience the psychological pressures you will face during the four hours.
There is a wide spectrum of programmers that take the CLD, experienced pros, those who use it once or twice a week at work, advanced beginners, and all other experience levels. Preparing with a strict time limit gives all the broad spectrum of candidates the opportunity to see where their personal methods support or hinder the effort to complete in four hours.
In general, take no more than thirty minutes to read the specification, understand the specification, and plan your design.
Again, generally speaking, the last thirty minutes should not be used as a "last ditch" effort to start a new piece of functionality or race to a last minute addition. If a bug is introduced in this last half hour, the damage done to overall functionality could be much worse than the potential gain. One good use of the last thirty minutes is to continue testing integrated modules/SubVI's, to fix small discrepancies , to make one more verification that what you have already programmed is working correctly. One of my clients used to tell me "test, test, Test !"
Of course, it is impossible to give directions that will meet all individual methods. This is why taking a practice exam under strict time limits is a HUGE suggested best practice. You get to see first hand how your strategies and test taking methods fit the four hour time limit. You can plan and prepare your solution and methods, but until you time it firsthand, you are only measuring your knowledge of the methods. In most cases, nothing teaches faster than timing your sample exam and learning from your own mistakes.
If you are struggling with both implementation and timing, complete one practice exam without time, then take it again , timed, with just three and a half hours limit as you already know the specification.
One time saver is to document and label as you program. While you are in a section of code, document what that case, SubVI, or algorithm is doing. Right at the point of conception it is easy to jot down a one line description. Waiting until the end and then documenting all the work you have done is not as efficient as documenting "in the moment". You might be testing in the last thirty minutes and run out of time to document the complete application. Also, when you are working with already documented code, you are giving yourself a road map as you integrate modules or add functionality to the application. Try this while you are taking the practice exam.
I hope you find this advice helpful and something to think about, but more importantly I hope I have convinced you to take some practice exams with strict time limits. Although I have touched on a few topics, the focus here is to promote the timing your CLD practice exams in preparing for the CLD.
Mark Ramsdale
Project Manager and CLD
Customer Certification and Training at National Instruments

Jeff·Þ·Bohrer wrote:
RDarn the mobile interface.
Tim, I hear you. What do you consider to be a "normal project"?
PS My CLD-R is at 8:00am tomorrow.
"Normal" = project for actual work
Good luck starting in about 13 minutes!
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Statechart on CLD

Similar Messages

Maybe you are looking for