# Oakromulo

Members

28

1. ## Programmatically check if VI is Desktop, Real-Time and FPGA compatible?

Nice question... I'll call NI Support team to check that. The ability to know programatically if the VI is compatible with VxWorks or Pharlap would be really useful for some generic LV classes/libraries.
2. ## Labview 2012 SP1?

Rule of thumb for both LV and MS Windows: never install before SP1 unless you really need it.
3. ## Determine day of week using Zeller's congruence

Fixed! Now with smaller datatypes as well... zeller2.vi
4. ## Determine day of week using Zeller's congruence

+1 -1 that's so funny... after I read your reply, I still needed some seconds to find this lame operation! +1 Kudo for the Coerce to Type operator. This situation seems to appear almost every state-machine-like VI! A little bit afraid to say... but... the c code looks so much more readable in your example! I mean it makes me afraid because this kind of comment lends itself very easily into love-hate posts...
5. ## Determine day of week using Zeller's congruence

I know the LV timestamp engine could easily be used to determine the day of the weak for a specific date. However, for those interested in a "behind the scenes" solution... the Zeller algorithm is really nice and possibly more optimized for certain applications. zeller.vi
6. ## 2D Line Permutation / 1D Shuffle

Thanks again Darin! I really wish my boss could hear it.
7. ## 2D Line Permutation / 1D Shuffle

Once LV lacks a primitive for this operation, I've written a quick & dirty VI to do random line permutations. I've tried to generate a random 1D array of I32 indexes, copy the 2D array and then do the line permutations one by one. Unfortunately, my code to generate the random I32 Array inside the VI seems to have an average O(n²) complexity. Do you know if there is a simple way to do O(n) or maybe O(n log(n) ) line permutations instead? Just out of curiosity, the randperm function from MATLAB has recently shifted from polynomial complexity to O(n log(n)), probably they've implemented some variation of the Fisher-Yates shuffle algorithm. randPerm1D.vi randPerm2D.vi evalRandPerm1D.vi
8. ## Some Questions regarding preparation for CLAD

LabVIEW for Everyone was an amazing tool for my first two months in my new job. Definitely worth the read, though a little bit boring after some time if you have a intermediate programming experience in textual languages. Don't forget to take a very comprehensive look at the NI CLAD material. Highlight every question you commit a mistake at the sample exams. This NI "Webcast" below is also very recommended. http://zone.ni.com/w...oc/p/id/wv-1950 It's a very straightforward exam. Hard to pass without commiting any single mistake but easy to reach the 70% mark. My manager, with very little LV experience besides demoing stuff, was able to pass in his first try. Please come back later to tell us how was your experience! P.S. It's not going to help with your exams, but if you want to know a little bit more about the RIO platform, you should spend some time with the NI CompactRIO Developers Guide: http://www.ni.com/pd...riodevguide.pdf
9. ## Formula nodes: code readability comes at a price

No free meal after all! At least there's Darin's Math Node to save development time... I've been through a simpler, yet very annoying bug at LV 2010 when NI released that feature that enabled us to directly wire error clusters to a boolean operator. In the first release, it would always return false at every FPGA VI, no matter the cluster value. At the same time, I had a C Series module with a clock problem and I couldn't track the underflow error. A very skilled NI Support guy found the bug after almost a week full of compiles and equivalent code replacements. After that, no more "new" LV before SP1, just like Windows releases...
10. ## Formula nodes: code readability comes at a price

Oh no... same thing with the next critical part of the neurofuzzy controller algorithm! The machine learning algorithm (performance bottleneck) with primitive array operators is again 4x faster (and uglier) than the formula node version. Formula Node Primitives
11. ## Size Matters

That's the main reason why most LV developers need an external monitor with a much lower pixel density when working with a laptop...
12. ## Formula nodes: code readability comes at a price

It makes total sense. RT FIFOs are probably implemented as standard fixed-size arrays.
13. ## Formula nodes: code readability comes at a price

That's very interesting. I've always tought the flush operation would reduce the queue size to zero. By the way, do you know if LV Queues are implemented internally as something like a C++ STL Queue or a Forward List? http://www.cplusplus.com/reference/queue/queue/ http://www.cplusplus.com/reference/forward_list/forward_list/
14. ## LV Controls/Icons Package

Ok... I'll categorize and put them there for evaluation.
15. ## Formula nodes: code readability comes at a price

I've forgotten that only RT FIFOs are pre-allocated and so enable constant-time writes. This time I replaced the queue with a DBL functional global variable.
16. ## Formula nodes: code readability comes at a price

Sure! I've added the indicators just for avoiding the "unused code/dangling pin" compiler optimization. You're right, it wasn't very clever, the queue idea is much better. The slow random number generator inside the for loop is there for the same reason to avoid unfair comparisons between the formula node SubVI and the standard one.
17. ## Formula nodes: code readability comes at a price

I just realized now that the percentiles have been calculated in a very wrong way. I invite you all to check the new comparison below with a queue structure. Now with parallelized for loops and queue, the primitives were a full 4 times faster than the formula node SubVI! PerfCompProject3.zip
18. ## LV Controls/Icons Package

Currently, I have tons of custom LV controls/icons in many different resolutions. Most of them have been adapted from Gnome and KDE. Does this kind of package apply for the community repository? Or is it just for block diagram stuff?
19. ## Formula nodes: code readability comes at a price

With output auto-indexing disabled, wouldn't the indicators outside the loop kick in compiler optimizations? Anyway, a queue in this case seems a better option.
20. ## why need to go Industrial computer?

If we're talking about NI Industrial PCs, another possibility would be to have a Certified PC platform to run NI ETS/Pharlap.
21. ## State Machine Basics

Even if some code doesn't actually respond to user interface it could still be useful to model it using a state machine pattern. Useful in a sense that it could actually improve both code readability and performance. For example: imagine a VI with a "latch when released" switch and a boolean indicator. For every push in the switch you toggle an automatic blinking pattern to the output. I have implemented this solution both with and without state machines. Take a look below. Which one do you prefer? without.vi withSM.vi
22. ## Formula nodes: code readability comes at a price

Another test: the comparison with parallelized for loops with 4 instances (number of physical + HT cores) with the i5 laptop has resulted in an amazing 89% faster! PerfCompProject2.zip
23. ## Formula nodes: code readability comes at a price

Ton, Same thing here... I ran the first comparison again in my laptop at work and it was just 5% faster too! Desktop (home): AMD Phenom II 965BE C3 @ 3.7 GHz (quad core) 8GB DDR3-2000 CL5 Laptop (work) Intel Core i5 M540 @ 2.53 GHz (dual core, Hyper Threading enabled) 6GB DDR3-1333 CL8 Both with Win7 x64 and LV2011. bsvingen, I think I'm going to try an equivalent DLL to be called from LV. I have little to no experience with DLLs on LV apart from the system ones. vugie, If I push the code inside a timed loop with manual affinity, is it safe to say it runs only in a single core?
24. ## Formula nodes: code readability comes at a price

Tim, Probably not... though it'd be interesting to know a little bit more about what happens behind the node.
25. ## Formula nodes: code readability comes at a price

LaTex --> G... that's awesome. Definitely should become a core LV feature! It'd be nice to meet Darin in the next NI Week... By the way, the equations represent a simplified First Order Sugeno Fuzzy Inference System. Always a good idea to add them to the VIs!
×