View Single Post
  #38   Spotlight this post!  
Unread 05-11-2007, 17:02
Chris Hibner's Avatar Unsung FIRST Hero
Chris Hibner Chris Hibner is offline
Eschewing Obfuscation Since 1990
AKA: Lars Kamen's Roadie
FRC #0051 (Wings of Fire)
Team Role: Engineer
 
Join Date: May 2001
Rookie Year: 1997
Location: Canton, MI
Posts: 1,488
Chris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond reputeChris Hibner has a reputation beyond repute
Re: Opinions wanted: LabView-based controller?

Quote:
Originally Posted by Mike Martus View Post
Question? Is Industry - wide scale using Lab view for their development and also are universities using Lab View for teaching programming in their curriculum?
That's a good question, Mike.

There IS an industry-wide movement to start using rapid prototyping languages in the controls industry. Furthermore, there is an industry-wide movement to move away from hand-generated C coding of signal processing and control algorithms. Here's a little history:

In the VERY old days, a controls engineer would create a block diagram of the control algorithm by hand on paper. The control engineer would perform some basic analyses on the block diagram to determine system stability as well as responses to basic inputs. After this the control engineer would give the paper block diagram to the software engineer who would code it in C. A simulation environment would be created in C to test the control algorithm to determine if it worked like it should.

Since the above took a long time and the control engineer depended on the software engineers to finish a simulation environment, products such as Matlab/Simulink and LabView were developed. Now the control engineer can create the block diagram on the computer and start running simulations immediately. Once again, however, the block diagram must still be given to the software team for coding in C and final testing in a simulation environment.

More recently, products have been developed to "cut out the middle man" (i.e. the software engineer) and automatically generate the C code from the block diagrams. This has the very large benefits of: a) the code should theoretically be 100% bug free, and b) requires virtually zero man-hours to create the code.

In my previous life as a controls engineer, we extensively used Matlab/Simulink/StateFlow (which was much more suited to what we did than LabView). We also extensively used a product called TargetLink which is a 3rd party add-on to Simulink made by a company called dSpace. What TargetLink did was automatically generate production-ready real-time C code from the Simulink block diagrams.

TargetLink works very well, by the way. By the time I left my former job, we had put two generations of product into production using TargetLink to generate all of the control/signal processing algorithm code (not just two products, but two GENERATIONS of products).

Interesting side note: virtually all of the autonomous modes that I have been associated with on teams 308 and 65 have used TargetLink to generate a large portion of the code for the control algorithms.

Keep in mind that this works very well for signal processing and control algorithms. For other things such as certain diagnostics, operating systems, and communications, I think hand coding is still superior.

Sorry this was so long.
__________________
-
An ounce of perception is worth a pound of obscure.