Leaderboard

This article should provide a helpful perspective: http://www.ni.com/newsletter/51675/en/ C was my first programming language. Then, I learnt assembly for 2 microprocessors, then C++, then LabVIEW, then TestStand. Learning C helped me to understand memory management, which gave me insight into how LabVIEW does buffer allocations behind-the-scenes. TestStand has a very C-like structure, so knowing C made it easier for me to learn TestStand. Learning assembly (together with digital logic) helped me to understand how software translates into hardware steps, which gave me insight into what the LabVIEW compiler needs to do behind-the-scenes, and it made it easier for me to learn the FPGA module in LabVIEW. Learning C++ helped me to understand OOP concepts, which made it easier for me to learn LVOOP. Note: This is my personal journey to my current state. Learning C (and the other languages I wrote about) definitely gave me a better "intuition" on how to write LabVIEW, but they're not strictly necessary. I don't think it's the most efficient pathway if your main goal is to improve LabVIEW skills. Other people have probably developed the same "intuitions" via other pathways. Note also that I no longer use C or assembly these days. Although they were a good learning experience, I find them too unwieldy for my daily use cases. LabVIEW and C++ are now my preferred tools. I'm guessing that's because the move from C to LabVIEW is a big paradigm shift, so they're simply struggling with a language that's "alien" to their "mother tongue". In fact, I experienced the same when going from C to C++! (They might have similar core syntaxes, but they're very different languages) You might experience a similar struggle when you start learning C, but I highly doubt that it will degrade your LabVIEW skills. After all, LabVIEW is your "mother tongue" ;-)

Well. It depends if you are a LabVIEW island in a C [sic] of programmers. Then you only have to learn that you *must* specify the DLL function prototypes and keep shouting "Threadsafe, Threadsafe, Threadsafe" until their ears bleed No need to learn C/C++ then I think every LabVIEW programmer should have a pet C programmer

Hi, I have tried to make a scenario to explain this better. The main use of reset is to reset between samples or to "Stitch" together samples when in continuous mode. In the Scenario Continuous Acquisition With Reset off the VI stores the last Array value in the 1st Sample (White) and uses it as the first Array Value in the 2nd Sample (Red). This effectively "Stitches" together the white and red waveforms in the graph. This helps with data processing as there is no erroneous data point in between samples. although not that important in the time domain it can really skew frequency type stuff. In the Scenario Single shot Acquisition I have emulated a time delay between samples. With the reset off we can see that the VI attempts to "Stitch" together the white and red waveforms and we end up with a flase trigger. Hence when using single shot sampling or using the same vi to sample different waveform we would want to always reset this VI in between calls. This is illustrated in the scenario "Trigger Single shot with reset On" Craig Trigger Reset.vi

I do all my development on a MacBook Pro in Bootcamp and VirtualBox, and I have yet to find something that doesn't work in LabVIEW for Windows. The only thing I've found that doesn't work all the time, is that USB access in virtual machines can be a bit shaky. But, this seems to be more related to VirtualBox than the MacBook. /J

Hey guys, Thread is old and haven't checked up on it in awhile. I have been buzy refining my Lua-to-LabVIEW binding library which I call GLue now. The major improvements are: The API is now more simple and consistent Added support for both 32bit and 64bit Windows Does not link with the C runtime, reduces external dependencies (was quite a bit of work) Does not link implicitly with the LabVIEW executable/runtime (portable accross LabVIEW versions) Hundreds of unit tests Multiple large industrial applications already developed and running flawlessly for last couple of years A welcome side effect from this effort is the ability to debug embedded Lua scripts remotely via the excellent ZeroBrain Studio. This allows for first-class Lua development & debugging within LabVIEW.