LabVIEW for C/C++/Java Programmers

[Alan Anderson]

Originally Posted by timothyb89

So my question is this: has anyone else had trouble "figuring out" LabVIEW when coming from a so-called "conventional" programming background?

The trouble comes when one insists on using that procedural-programming background instead of letting go and opening one's mind to the dataflow paradigm. It took me a couple of days to stop trying to apply what I "knew" about programming, but once I had accepted the way LabVIEW actually works it was smooth sailing.

It's a very Zen-like situation. The less you know, the more you learn. To learn faster, you must first forget the knowledge you already have.

[JamesBrown]

Originally Posted by Alan Anderson

The trouble comes when one insists on using that procedural-programming background instead of letting go and opening one's mind to the dataflow paradigm.

It's a very Zen-like situation. The less you know, the more you learn. To learn faster, you must first forget the knowledge you already have.

This is completely true. I took a course in programming languages, at first glance the class seemed simple, we had to learn the basics of different languages and write relatively simple programs. By this point in my Computer Science Curriculum I had little difficulty picking up languages.

The real test came when new paradigms were introduced. (Functional and Logic programming). You have to forget what you know about programming and start again, obviously it is still easier to learn than it was to learn your first language, however it is much harder than learning an additional language that follows the same paradigm.

Comparing it to learning spoken languages, Java to C++ is like French to Spanish, structure is the same, syntax is simmilar. Going from C++ to Labview is like French to German, the structure and approach are completely different.

When moving to a new programming paradigm, it is important to remember to apply the lessons you have learned about how to learn a language, not to apply the lessons about the actual language.

[Robototes2412]

This might sound like an idiotic question, but is there a way to edit labview code with a text editor?

[Alan Anderson]

Originally Posted by Robototes2412

This might sound like an idiotic question, but is there a way to edit labview code with a text editor?

No, you can't edit LabVIEW code with a text editor. There is no underlying text representation to manipulate.

It might be possible to take the "directed graph" which defines a vi and produce a text report containing all its information, but one would need to invent a syntax for it, and making changes to that report and reversing the process would be extraordinarily error-prone.

[demosthenes2k8]

Ugh...I've learned several text-based languages over the years, but switching to Labview was the hardest one to do. One of the mentors would tease me about how I wrote my labview code with random sequence blocks in it, simply because I wasn't used to having an environment do things for me like race conditions.

I only use it for the dashboard, but it's still taught me some things

[vamfun]

I am comfortable with LV ,C/C++ and matlab. Our team chose to stay with C++ for FRC target code but since I always do engineering simulations of our control systems including the pneumatics my language preferences vary.

For engineering analysis, I usually prefer matlab but find the intended users are often unfamiliar with it or don't have matlab installed. Since most of the kids have C capability, several build seasons I used C to write the simulations and used EXCEL to do the graphing.

Recently, I've wrapped LV I/O functions around C programs to extract the utility of both languages for quick simulation. The LV graphics are powerful and the text editing of C beats the somewhat clumsy data flow editing of LV particularly when dealing with logic and simple math. The plus is that most teams have LV working now so the software is portable.

Had our team used LV, I think it would have been easy to build an autonomous mode simulator that used LV embedded target code for the control system and LV for the simulated dynamics and graphics as some teams have done.

Often times hardware availability dictates the use of LV. At the college where I mentor we had an NI DAQ board lying around so we chose to use LV to write the control system for a STM project to aid a nanotech initiative. It took longer since I had to learn LV but like Alan said when you give in to the data flow concept the work flows easier too.

If NI offered up a good cheap virtual space modeling capability I'd use LV more for sure. Maybe they will include more graphics and virtual capability in next year's kit.

[Egg 3141592654]

I agree, with a heavy background in Java, switching to Labview was a burden, yet I just read the Labview manual once or twice and things started to make sense. I have no clear method to decipher Labview into some other language, other than reading the manual and trial & error.

[Gene F]

I have to agree that Gdeaver hit the nail on the head! Procedural versus data flow are different beasts, both to be tamed and put to good use. A good conceptual middle ground is to learn to exploit the benefits of procedural programming in a multi-tasked/multi-threaded environment. Spend some time learning to use things like semaphores, messaging, state programming.

I've been programming as a professional since the early '80s. I have used many different languages. My first exposure to LabView came in the early '90s. At the time I was working for a controls company and we were investigating LabView as a tool for developing User Interfaces (UIs). One of the tasks I was assigned then was to implement a serial protocol using it. Not the best tool for the job. Like has been stated earlier each choice has its strengths and its weaknesses. Look at the strengths and weaknesses of your programming team and pick the environment that fills in the gaps. There are ways to use both LabView and C++ in a PC environment and I hope they expose that capability for FRC in the near future.

On another note, early on in using LabView for FRC my son and I wrote a simple motor simulator VI in LabView. It was a great learning experience and gave us some tools to work out the bugs in our PID routines. Has anyone else used LabView to build up a virtual library of useful FRC components?