Go to Post How many robotics kids does it take to turn on a light? - demosthenes2k8 [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

 
 
 
Thread Tools Rate Thread Display Modes
Prev Previous Post   Next Post Next
  #15   Spotlight this post!  
Unread 20-04-2008, 21:45
programMORT11
 
Posts: n/a
Re: C or LabVIEW: CompactRIO

1. We will continue to use C, or C++ if OO is really useful for this (think driver control and complex modular end effector systems)

2. C is the industry standard, and frankly, I think that C will continue, at least with veteran teams, just because things like dealing with packet data and interfacing new systems are easier to handle with a text-based language. All experimentation, and complex robot code will probably be done in C. Debugging, though, is where Labview will begin to dominate, since building GUIs is so much easier, and teams can make really nice dashboards.

3. Rookie teams will probably use Labview, just because it doesn't look as intimidating as a C environment with all the functions and brackets, and everything. Things like functions, arguments, parameters, and variable types are all nicely obscured.

4. Was a new version of LabVIEW created specifically for this competition?
A: NI is creating a custom build of LabVIEW made specifically to meet the needs of the FRC
competition. The graphical programming environment, though, is the same one used by hundreds
of thousands of students and engineers worldwide.

That's from the FAQs on the WPI FRC Resources site.

5. YES, NXT would be a great way to prep for LabView (it familiarizes you with wires and stuff like that.) Data flow programming is a slightly different paradigm, and NXT would be good practice.

6. GUIs are very easy with Labview. I've tried Python, C, Java, and VB, and for GUIs related to I/O processing, nothing is easier than LabView. On the other hand, we did have problems with VIs crashing, i.e., CMU2Cam, but hopefully this has been fixed. It just works, and there is amazing documentation if you need it. On the other hand, it will be harder to do a lot of the low-level stuff hard-core embedded systems programmers love to do. Interfacing a custom router, or a PS3 would be a lot harder to code. The capabilities of the C libraries will be easier to modify, and existing C code can be easily ported over, so a lot more code exists. And innovative systems, like the Autoflex 2.0 might take more effort to code.

Personally, I'm planning on having the new programmers on our team write the debuggers and dashboards with LabView, so they learn programming concepts at least, and don't get overwhelmed by the power and complexity of C. But slowly, we will move them from debuggers and dashboards to real robot code, which we will continue to write in C.

Last edited by programMORT11 : 20-04-2008 at 22:42.
 


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
learning LabVIEW Lions for First National Instruments LabVIEW and Data Acquisition 11 21-04-2008 15:26
CompactRIO - new Control System by NI ND4SPD Programming 1 17-04-2008 21:46
Labview tseres Programming 2 23-05-2007 00:27
LABView Error TuaMater LabView and Data Acquisition 1 20-01-2006 02:58
Labview Phreakuency LabView and Data Acquisition 6 14-01-2006 01:14


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

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