Go to Post "I would love to change the world but no one will give me the source code" - programmr [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
 
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 06-06-2010, 22:13
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,756
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: LabVIEW for C/C++/Java Programmers

Let's say that you know base-ten numbers. You learn basic arithmetic, multiplication tables, decimals, fractions, all in base-ten. As far as you know, this is the only way to do math and you are on top of it. Go you.

Then a new teacher, say the CS teacher, decides to teach you base-eight numbers. It is weird. Many of the things you know about math are not necessarily correct. Everything is slow, you make many mistakes, and really just want to pretend this never existed.

Next the teacher brings up base-16, even weirder, and then base-2. Finally things start to click and you realize that there is nothing magic about base-ten, all of these are arbitrary, and there are benefits to knowing more than one system.

A similar analogy to Cartesian coordinate system versus spherical, versus cylindrical, ..., also fits. True, a language is more complex than a mathematical convention, but the point is that many times, the second way to solve a problem is more difficult to learn than the first. That doesn't mean that there was an issue with either of them, but it is simply human nature and is a natural process. Once you get over that hump, the benefits of knowing two mean three and four come far easier.

Greg McKaskle
  #2   Spotlight this post!  
Unread 07-06-2010, 09:52
Gdeaver Gdeaver is offline
Registered User
FRC #1640
Team Role: Mentor
 
Join Date: Mar 2004
Rookie Year: 2001
Location: West Chester, Pa.
Posts: 1,370
Gdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond reputeGdeaver has a reputation beyond repute
Re: LabVIEW for C/C++/Java Programmers

The Key to Successful programming a robot in Labview is to understand the concept of data flow. Many of the text for Labview state that a procedural programming mindset can cause problems, but do not define or give very good examples of exactly what data flow means. There is an opportunity for some one to write a paper on data flow best practices. This would help the FRC community allot. Anyone up to the challenge? The next big thing that could help with the robot programming is a good tutorial on state machines. There are some good college level text on the subject but most students seam to have problems comprehending them. Another opportunity for a white paper. This year our robot code was much more complex than previous years. We had some serious control problems. As the the season progressed and the code evolved, it went from a procedural flavor to data flow and our problems resolved. This happened by experimentation not by design. The question is how to teach these concepts to new Labview programmers.
  #3   Spotlight this post!  
Unread 07-06-2010, 10:04
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: LabVIEW for C/C++/Java Programmers

Quote:
Originally Posted by Gdeaver View Post
The Key to Successful programming a robot in Labview is to understand the concept of data flow. Many of the text for Labview state that a procedural programming mindset can cause problems, but do not define or give very good examples of exactly what data flow means. There is an opportunity for some one to write a paper on data flow best practices. This would help the FRC community allot. Anyone up to the challenge? The next big thing that could help with the robot programming is a good tutorial on state machines. There are some good college level text on the subject but most students seam to have problems comprehending them. Another opportunity for a white paper. This year our robot code was much more complex than previous years. We had some serious control problems. As the the season progressed and the code evolved, it went from a procedural flavor to data flow and our problems resolved. This happened by experimentation not by design. The question is how to teach these concepts to new Labview programmers.
Wow, great post, you hit the nail on the head. The only thing I would add is a brief but usable explanation of the realtime and multitasking aspects of LabVIEW in the FRC context (LabVIEW FRC Framework). Or perhaps this could be integrated into the main topics you mentioned. From posts I have read this season and from personal experience, that was a big stumbling block for many new FRC LabVIEW users.


~
  #4   Spotlight this post!  
Unread 15-06-2010, 14:45
Luke Pike's Avatar
Luke Pike Luke Pike is offline
Programmer
FRC #1501 (THRUST)
Team Role: Mentor
 
Join Date: Jan 2008
Rookie Year: 2008
Location: Huntington
Posts: 114
Luke Pike is a name known to allLuke Pike is a name known to allLuke Pike is a name known to allLuke Pike is a name known to allLuke Pike is a name known to allLuke Pike is a name known to all
Re: LabVIEW for C/C++/Java Programmers

Quote:
Originally Posted by Gdeaver View Post
The Key to Successful programming a robot in Labview is to understand the concept of data flow. Many of the text for Labview state that a procedural programming mindset can cause problems, but do not define or give very good examples of exactly what data flow means. There is an opportunity for some one to write a paper on data flow best practices. This would help the FRC community allot. Anyone up to the challenge? The next big thing that could help with the robot programming is a good tutorial on state machines. There are some good college level text on the subject but most students seam to have problems comprehending them. Another opportunity for a white paper. This year our robot code was much more complex than previous years. We had some serious control problems. As the the season progressed and the code evolved, it went from a procedural flavor to data flow and our problems resolved. This happened by experimentation not by design. The question is how to teach these concepts to new Labview programmers.
Here's my crack on data flow:

LabVIEW Data Flow Explained

Most people who come to LabVIEW from a procedural language like C or C++ have trouble understanding the execution order of the code. The trouble comes from trying to making things happen in a sequence, as in do A then B. LabVIEW code does not have a sequentially defined order like text languages, where the execution goes from line to line. Instead, execution is defined by data flow.

Data Flow

In LabVIEW, any piece of code, either a primitive VI or a user-defined VI, can have input and output terminals. In order to give these terminals a value, data must be "wired" into these terminals from another source, either a UI control, constant, or output terminal. Wires that are connected to inputs must have a value, they cannot be null. The way LabVIEW decides which part of the code to execute depends on what wires have values. Suppose you have two constants wired into a multiply block, and the output of that is wired into a negate block. The negate block cannot execute until it's input wire has a value. Therefore, the multiply block executes first, as it's input wires have values (the constants). After the multiply block has run, the output terminal gives the negate block's input wire a value. Now that all of the inputs to the block have values, the negate block can run.

And that's it. As long as a block or VI's input wires have a value, it can run. Inputs that are not wired and not required have a default value, so as long as the others have values, it can still run. That means that if you have two multiply blocks with constants wired into their inputs and no output from one multiply block goes into an input to the other, the order in which those multiply blocks execute is undefined; for all intents and purposes, they happen at the same time, or in parallel. Now, if you wire the output of one of the multiply blocks to the input of the other, then the first block has to execute first, then the next as it is waiting for a value.

Using Data Flow To Control Execution

Now that data flow has been explained a little, how is it used to control the execution of code? For most operations, nothing else needs to be done. A series of calculations on a number simply execute as the previous calculations complete until it is done. However, some things don't have data dependancies (wires) between each other, yet still must happen in a sequence. Many first time LabVIEW users use the sequence structure to make things happen one after the other. While this can be done, it's generally not the best paradigm to use when solving a problem.

Here's a few alternative things to try:

First, use error clusters to enforce data flow. Most VIs have error in and out terminals that are usually used for error checking. Another way to use them is to wire the error out from one VI to the error in on another VI to make sure the first VI executes before the second.

Secondly, if the VIs don't have error terminals, you could put each segment of code into a sub VI, add error in and out terminals, and wire the error out terminals into the error in terminals to make the VIs execute in order.

Lastly, if your code is too complicated for the other two suggestions, consider a state machine. A state machine executes code based on a state. Once one state is deemed complete, the next state is executed, or any other state depending on the need. State machines consist of a while loop with a case structure inside. An enum in a shift register is used to determine the state. The enum is wired into the case structure and each case has code for each state. To move to another state, simply wire a different value for the enum into the right terminal of the shift register and the next loop will execute it. To make the state machine into a VI that can be called from anywhere, wire a boolean true into the stop condition terminal of the while loop and make sure that nothing is wired into the left side of the enum shift register. Put the code in a sub VI, give it inputs and outputs if needed. The sub VI will remember the values of the shift registers and maintain it's state. Here's a post of mine on how to make a state machine.

If you have any questions or improvements, feel free to post them.
__________________
Twitter Profile
  #5   Spotlight this post!  
Unread 15-06-2010, 23:19
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,756
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: LabVIEW for C/C++/Java Programmers

The description about data flow is pretty accurate, but since LV includes some control structures, there are a few additional descriptions that are useful to know about.

A LV program is made of one or more VIs (Virtual Instruments).
A VI is made up of a panel, a diagram, and descriptive info such as the name, icon, and description.
The panel allows the user to view and interact with data.
A diagram contains nodes and wires and is used to describe how the computer interacts with data.
All control flow structures are nodes that contain diagrams.
*Loops are control flow nodes that contain a diagram and run it as many times as specified.
*Cases and other conditional statements execute only one of their diagrams based on the selector input.
*Sequences execute each diagram, one after the other.
*A subVI call is a node that updates the panel and executes the diagram of the VI referenced by the subVI node.

A diagram executes by propagating data already available on wires, followed by executing nodes that do not need any additional inputs. Each and every node on a diagram is executed once and only once as its data becomes available. When all nodes on the diagram are complete, the diagram completes and propagates data to its outputs wires.

Other things worth noting:
Nodes are functions, but they don't necessarily return immediately -- especially when they are I/O related -- and can be used to regulate or signal downstream or owning code.
Wires are special unnamed variables useful for safe parallel programming. The wire guarantees that the variable is only written to one place in the diagram, then it guarantees that each reader receives the same value -- no uninitialized variables and lightweight synchronization between write and reads.
Global and local variables and other state data can introduce race conditions, but all data accesses are atomic. When reading a global, all writes are locked out, etc.
A subVI can be marked as reentrant or not. By default it is not, and it automatically mutexes so that only one caller is in the code at a time. This is particularly useful to protect global resources to avoid race conditions. If marked reentrant, simultaneous callers will proceed in parallel.
Loops are an easy way to execute code in parallel, but without something to slow down their execution, they will run as fast as possible and can starve out parallel tasks.
Many LV operations are polymorphic -- they operate on many datatypes -- and this can allow for very concise syntax.
LV doesn't support recursion, at least not very well.
LV does have the ability to create objects, protect data fields and methods, and do dynamic dispatching, but it is generally treated as an advanced architectural feature. And the objects are not referenced, but have by-value semantics to work well in a parallel language.

These are the sorts of things I usually try to point out to experienced programmers new to LV. I know some of the lingo is technical, but you have to start somewhere.

Greg McKaskle
  #6   Spotlight this post!  
Unread 16-06-2010, 10:19
Russ Beavis Russ Beavis is offline
Registered User
no team
 
Join Date: Nov 2005
Location: Manchester, NH - DEKA R&D Corp.
Posts: 341
Russ Beavis has a reputation beyond reputeRuss Beavis has a reputation beyond reputeRuss Beavis has a reputation beyond reputeRuss Beavis has a reputation beyond reputeRuss Beavis has a reputation beyond reputeRuss Beavis has a reputation beyond reputeRuss Beavis has a reputation beyond reputeRuss Beavis has a reputation beyond reputeRuss Beavis has a reputation beyond reputeRuss Beavis has a reputation beyond reputeRuss Beavis has a reputation beyond repute
Re: LabVIEW for C/C++/Java Programmers

I often strongly recommend that newcomers to LabVIEW use "Highlight Execution" (the little light bulb on the toolbar) to watch, in slow-motion, the data (and program) flow from VI to VI.

Very useful debugging and educational tool,
Russ
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
PROGRAMMERS: WIND RIVER C++ vs LABVIEW vs JAVA krudeboy51 Programming 92 30-05-2011 17:00
Labview and Java chsrobotics3283 NI LabVIEW 3 13-03-2010 21:36
New TipJar Video: LabVIEW for C++ Programmers. LVMastery Programming 1 06-05-2009 15:41
CMU Cam2 Java app (Help with Labview GUI) Team 1649 Programming 3 26-12-2006 14:25
Hints For Rookie Programmers Noah Programming 30 20-02-2003 20:07


All times are GMT -5. The time now is 03:45.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi