Certification
CLED – Sample solution & strategy
Im am practising for the CLED exam and are in the midst of my second practise run.
I have a first idea of strategy for the first half of the practise exam. I want to share these thoughts and if you have feedback, I would appreciate it:
1. Give GUI-development low priority in the first half
Reason: in the exam sheet, we find "The system is intended to be used in a headless fashion, running autonomously with a user interface connected only occasionally..."
-> As the main focus of system is „running without UI“ (and as one can see without UI that RT system works correct when files are generated), I would implement nothing for the UI in the first half, besides thinking about possible communication mechanisms for making proper design decisions.
-> If it happens that I do not have enough time in the second half, I would hope that generally, parts of solution which haven't much in common with RealTime (which in my opinion the GUI is) would not be marked too high.
[ok, it will be marked, but how much? - own example:
in my first try, implementing the FTP mechanism took too much time – I would rather prefer making the RT/FPGA module complete than doing something at FTP (whose implementation i.m.o. woldn't prove RT skill)]
2. FPGA-Code: keep it simple and put as few functionality there as possible/necessary
As it costs time (compiler!) if I have to make changes there, I agree with sample solution and would put in the FPGA code only the things which are really necessary. Even more, I would only make ONE FPGA Main.vi and avoid sub-viing there (sample solution has two non-complex FPGA sub-vis).
Normally, I would prefer to finish the FPGA code at first, but I cannot exclude to make errors there (or for certain functionality, have to add code later). But if I put as few functionality there as possible/necessary, I minimize my risk to loose too much time, if I have to correct errors later. [maybe a psychological issue that I want to have finished FPGA code althogh I could work in parallel when FPGA code compiles]
3. RT-Code: architecture and simple RT features first, then complex RT features, then GUI communication
Structure of sample solution is good: You have do define FIFOs, an error queue and to init the FPGA. Also, the Watchdog loop and the error evaluation loop is not too complex.
→ If I could implement these features in the first half, I won't have to think about this for the rest of exam and will at next implement the acquisition loop. In parallel, I will decide which data with what mechanism should be exchanged with GUI...
Last question:
Until now, some people published their CLD and CLA solutions for review. Is it also allowed to publish an own CLED sample solution?
In the moment, I have an incomplete solution, which only includes the „after-two-hours“-features mentioned above and is similar to given sample solution but in some points different.
ok, here I am again. As I requested to post an own PARTIAL solution to the CLED sample exam, I do it now:
* FPGA code is quite similar to sample solution (besides that I did not use sub-VIs),
-> so there will be nothing interesting to see
* UI code is NOT implemented (I worked bottom-up and will do that later),
-> so nothing interesting there either
If you want to look at my solution, I recommend to focus on the RT part,
especially the "Settings-Change-Reset-mechanism", which is not covered by NI sample solution:
* RT code:
-RT Main.vi: -> initializes everything and calls the loops
-SP-SVs in RTinternals.lvlib: -> see "Init Shared Vars.vi" for usage
-NP-SVs in UI Comm Library.lvlib: -> for propagating State and Error texts to UI
(done as in sample solution, will be extended later)
-Loops:
*Watch+Error loop: -> similar to sample solution
*Message Loop: until now, we have a UserTrigger and a SettingsChange message from UI
(Settings Change -> update settings variable and signal to "Evaluate External Events.vi")
*Acquire Loop: will have similar structure as sample solution,
until now, only Init state implemented which is reached when user settings change.
If you want to give feedback, I would appreciate it! -
especially on whether my "Settings-Change-Reset-mechanism" would work
or whether there are any other serious bugs.
(only few comments in code as that only worth 5 points, style was in that try not my main focus,
and only partial solution as UI and acquire states not implemented)
Honestly said, thinking and implementing this reset-mechanism (which was not in NI sample solution)
consumed more time than expected (here I still have to do something with my time management) -
but in my opinion it is a feature required by the exam text - so I could not avoid to implement this.
-> If someone has arguments that this mechanism is NOT so important (or not graded high),
feel free to tell it - such arguments may help to decide what is important in real exam.
