Search the Community

Hello, Recently I'm trying to get my CLA and this is my third time practicing this example. I took about 3 hour and 20 minutes to finish it. (Actually I planned spent 3 hour to finish it , it's already the third time, I barely analyzed it , just coding) The first hour I took was for establishing ancestor classes, set up public data, sharing mechanism / VI (open/close queue references, access data base, main running VI framework.....etc) The second hour I spent on modules (error handler, user console, display console and sensor ) The third hour is implementation of the main module : Controller and I took another 20 minutes because some requirement tags I have no idea where to put. I know lots of people suggest do not use OOP in CLA, because it takes too much time. But I've been used to OOP style and not very familiar with tradition QMH programming. Something Still Confusing me , it's appreciated if leave some comments or suggestions to me. 1. I still think it's not fast enough, did I put too much code or redundant comments in it? (when I took my CLD, lots things slowed me down, like nervous,misunderstanding questions, strong AC, noise...etc , I think those will happen again in the CLA, ) 2. Did I comment in the proper way ? Did I comment clear enough for developers? (which is the NI examiner), if I don't build any child message class (for saving time), just leave the comments to tell how to build them, is that OK? I'm not sure whether I leave enough comments for understanding 3. I didn't build the timer FGV module, instead, I encapsulate a "local timer" in to controller.lvclass and directly manipulate it in the loop, is that an acceptable method in CLA? (I use this method in real world a lot, since I just need a local timer in one loop, I do not need set up another timer FGV to confuse me in the project) 4.Also the example has a data base module, I do not either. It's more flexible to me let the ancestor class handle the data base then share it to every child class. Elevator.zip

Hi all, I wonder if anyone could review my CLD Sample Exams codes, giving me a few tips. I plan to take the CLD exam soon. Best regards, CLD1 ATM.zip CLD2 Boiler.zip CLD3 Car Wash.zip CLD4 Sprinkler.zip

While upgrading the OpenG LabVIEW Data Tools to LabVIEW 2009, we noticed that the unit test for Remove Typedefs from Variant was't passing. Currently, the (buggy in LabVIEW 2009) code looks like this: The comment references a bug in LabVIEW 6.1 related to Variant to Flattened String. Basically, the old (LabVIEW 6.0) method we used was to call Variant to Flattened String and then to Flattened String To Variant as shown here: In 6.1, we changed the Flatten/Unflatten method with a call to Variant to Data and this did the trick (removed Type Defs from the variant). However, it appears that somewhere along the way, this stopped working (perhaps this "feature" was really a "bug" that got fixed by NI). Now, can anyone think of a reason that we wouldn't want to go back to using Variant to Flattened String and Flattened String To Variant? Can anyone think of a better way to remove typdefs from a variant?