Labview: A Ballsorter

[Los Frijoles]

Well, I just finished off my first working robot program with LabView and I do have to say: I am now converted. It was really really easy in the whole picture of things and I see some real possibilities for next year. I only wish I was not going off to college next year so I could program the robot this way.

I used a FischerTechnik RoboPro module and building set along with a couple libraries that my teacher pulled out of nowhere to create a marble sorter.

As I was programming, the possibility occoured to me that this might possibly introduce the possibility for a psuedo-multithread-esque program since the NI controller uses something of an FPGA I believe (correct me if I am wrong). I also found that there are some things which I believe to be quite inefficient:

1. I had to use Case statements to simulate an if () {} sequence
2. The equivilent of var++ was an add 1 to a value sequence which involved several numeric constants
3. Sometimes the wires get tangled and are hard to distinguish...is there any way to change the color? Right now it is based on the type of the variable being passed down the wire (green = bool, blue = #)
4. The control/tools/modules/whatever panel got in the way of programming in the block diagram view and got quite frustrating with having to move it around. Is there any way to circumvent this?

I will probably have video of the marble/ballsorter on youtube tomorrow when I remember to bring my camera to school...

[TDohse]

Originally Posted by Los Frijoles

As I was programming, the possibility occoured to me that this might possibly introduce the possibility for a psuedo-multithread-esque program since the NI controller uses something of an FPGA I believe (correct me if I am wrong).

Whether using a PC or the cRIO multithreading is possible. If you place two loops side by side on your block diagram, they will both execute in parallel in their own thread/task. In many cases, you may naturally end up using multiple threads without really focusing on the issue.

1. The equivilent of var++ was an add 1 to a value sequence which involved several numeric constants
2. Sometimes the wires get tangled and are hard to distinguish...is there any way to change the color? Right now it is based on the type of the variable being passed down the wire (green = bool, blue = #)

There is an "Increment" block under the "Numeric" palette which would probably have solved your var++ issue more easily. As to the wires, if you right click on a wire and select "Clean Up Wire" LabVIEW will automatically move the wire to a better path.

[Russ Beavis]

I typically "close" the function and controls panels and simply right-click (in any white space) to temporarily open them up and find the function/control that I'm looking for. I never leave those panels open but I've seen many LabVIEW programmers with different preferences and styles (all configurable via preferences).

It might make sense to leave a copy of the functions palette open when doing specific tasks (eg the LabVIEW for NXT toolkit since you spend a lot of time in that "directory" when programming for NXT).

I also disable automatic tool selection and use the TAB key to cycle between tools. Maybe newer LabVIEW programmers like to use auto tool selection? Whatever it takes...

When in doubt, right-click. There is a LOT of functionality that is exposed via right-clicking (in white space, on the edges of structures, on terminals, anywhere).

Russ

[Qbranch]

Originally Posted by Los Frijoles

[*]Sometimes the wires get tangled and are hard to distinguish...is there any way to change the color? Right now it is based on the type of the variable being passed down the wire (green = bool, blue = #)
...

I will probably have video of the marble/ballsorter on youtube tomorrow when I remember to bring my camera to school...

Nope, there is no way to change the wire colors. As far as the wires getting jumbled... I believe there is a "Clean Up" button or something to that effect somewhere in the menus... but I'm not sure how far that will get you.

The other thing I've found... wow I wish there was a zoom on Lab View.

Please do take a video!

What controller are you using? Compact RIO?

If so, how'd you get your hands on one?

Cool!

-q

[Sunshine]

The controller that Kevin is using is from Fischertechniks. Kevin is in our Engineering Academy where we use Project Lead The Way (PLTW) equipment.

I wanted Kevin to explore LabVIEW and see if he could help us teach the software during the offseason to other students before he leaves for college.

Kevin has been our lead student programmer the last 2 seasons using C+. Our intent is to use existing hardware that we have available to learn the software. If others would like to try this and have the Fischertechniks Intelligent Interface, This toolkit allows you to control the Fischertechniks Robo Interface and the Fischertechniks Intelligent Interface through LabVIEW..

Good Luck and report back.

Nice work Kevin!

[Greg McKaskle]

Originally Posted by Los Frijoles

...

1. I had to use Case statements to simulate an if () {} sequence
2. The equivilent of var++ was an add 1 to a value sequence which involved several numeric constants
3. Sometimes the wires get tangled and are hard to distinguish...is there any way to change the color? Right now it is based on the type of the variable being passed down the wire (green = bool, blue = #)
4. The control/tools/modules/whatever panel got in the way of programming in the block diagram view and got quite frustrating with having to move it around. Is there any way to circumvent this?

Congrats on your first LV program. You already have some responses, but let me add my own.

1. Case statements aren't really inefficient. They are a more structured, but equivalent way of doing conditional code. You might want to try switching out on numbers, or enums, errors, or strings. All of those work and quickly simplify code used to turn stuff into booleans. You build the ranges of values in the case such as (1..3, 6) and (default) for numbers.
2. As Thomas mentioned, the +1 node will help a bit, but also be sure you aren't using local variables and UI elements on your panel as programming storage. One of the trickier things to unlearn when trying LV, is to avoid naming things and referring to them by name. So, A-->+1-->X, is better than reading A, incrementing, storing back into A, then assigning X from A.
3. The color is tied to the type, similar to syntax coloring in other tools. Using white space to separate and group the wires is usually a more effective technique. Also, if you have many wires, bundle them into a cluster, then unbundle them again later.
4. Currently, LV has many windows, floaters, and menus. It soon becomes second nature to control them, but it can be intimidating at first -- kinda like vi or emacs, or any other editor that has accumulated features over a couple decades.

If you have more specific LV questions, fire away, here or on the ni.com/community/first site.

Greg McKaskle

[Los Frijoles]

Here is the video from it:

http://www.youtube.com/watch?v=4_tsjY-YiPE

[stalepretzel59]

Frijoles,

Could you please post your source?

For next year's competition, I want to use C, but the captain insists upon LabVIEW. I'd really like to see some quality, working robot code, because so far, I think LabVIEW seems pretty worthless.

Would you mind doing that?

Thanks a bunch!

[whytheheckme]

Mr. Pretzel,

Welcome to Chief Delphi!! You will find many helpful resources here, and tons of people willing to help you out. PM me if you have any questions.

Originally Posted by stalepretzel59

For next year's competition, I want to use C, but the captain insists upon LabVIEW. I'd really like to see some quality, working robot code, because so far, I think LabVIEW seems pretty worthless.

Just curious, what makes you think LabVIEW is worthless? It's the industry standard, and time-wise, can be much more efficient than C. Also, LabVIEW can provide simple ways of doing things that would be much more difficult to do in C. C is old and very basic, while LabVIEW is new and very complex. I don't think that judging it as 'worthless' without even using it is a very wise decision.

Also, while C will be supported now, I believe that in the near future, LabVIEW will be the preferred language, and perhaps even C support could be dropped in the long run. LabVIEW, in many ways, is a more practical programming education for students entering the workforce. I wouldn't be so set in your ways (imho).

Happy Coding!
Jacob

[Dave Scheck]

Originally Posted by whytheheckme

It's the industry standard, and time-wise, can be much more efficient than C.

I'm really getting frustrated with statements like this. While Labview may be AN industry standard, it is not THE industry standard. Go onto any job hunting website and search positions requiring Labview expertise. Now compare that to what you find for C++. I'm very confident that you will have a large discrepancy in the number of hits you find.

You're certainly entitled to your opinion, but mine is that a good programmer will be able to write circles around someone using Labview. Another engineer on the team I (both skilled programmers) tried the demo at Championship and was amazed at how ridiculously complex it was to do something simple like do a direct mapping of joystick to motor that we could have done in one line of C code (ignoring all of the libraries since both languages have them).

I also think that all of these hoops that you guys are jumping through to post images/videos of your code is ridiculous. Sharing, collaborating, and requesting help should be a simple task. Text based languages are inherently set up for this.

Also, has anyone considered version control? How do you diff two diagrams? How exactly do you plan on having multiple people working on the same file at the same time and then merging them together? If this is industry standard, a solution must exist. Will this be provided to teams using Labview?

I will go so far as to say that version control is more industry standard than Labview. Why isn't there a push to educate teams on this subject?

I'm sure there are teams that are going to do some wonderful things with Labview, but you won't see it coming from us.

[Dave Scheck]

After posting, I want to be sure to not hijack this thread. I think that Frijoles did a nice job on his project and don't want to take away from that. I would encourage him and others to continue to educate themselves on Labview and its relevant uses.

[whytheheckme]

Originally Posted by Dave Scheck

I'm really getting frustrated with statements like this. While Labview may be AN industry standard, it is not THE industry standard. Go onto any job hunting website and search positions requiring Labview expertise. Now compare that to what you find for C++. I'm very confident that you will have a large discrepancy in the number of hits you find.

Someone else brought this issue up with me over PM. I didn't intend for my statement to sound like LabVIEW is REPLACING C (or any other language for that matter), but in the industry of data acquisition (which is a major part of the robotics industry), NI and LabVIEW is a leading technology. My point wasn't that LabVIEW beats out C or any other language, but that LabVIEW isn't some simpleton's tool. LabVIEW has awesome potential to do many things, and because it's so widely used, it's not 'worthless'.

I'm sorry if I made it sound like LabVIEW replaces any language in the global job market; what I intended to say was that for it's field (data acquisition), it is a leader, and in many ways, can be superior.

Sorry for the confusion,
Jacob

[Dave Scheck]

Originally Posted by whytheheckme

I'm sorry if I made it sound like LabVIEW replaces any language in the global job market; what I intended to say was that for it's field (data acquisition), it is a leader, and in many ways, can be superior.

No worries. I also apologize if you took any of that personally. It wasn't my intention to jump on you or your opinions. I just don't want people to get the idea that Labview is the magic bullet that will solve programming woes.

To be fair, I did poke around on YouTube and watched a few tutorials and saw some cool data acquisition demos. I personally still think there are too many cons to do the rapid development that we're accustomed to with the FIRST program, but that's just me.

Like I said before, if this works for you great. Do some cool things with it and be proud of your accomplishments. After all, that's really what this program is about, right? Inspiration and education (although some may disagree).

[Michael Hill]

You think programming a robot is bad, try writing software for data acquisition and review for a research facility. This is some stuff I've helped "write". (btw, I put "write" in quotes because I don't believe LABView is actually writing code...it's just me.) Of course the code is some proprietary stuff, but I can show you the end result. What the first one is doing is part of our facility data acquisition system. It monitors our test environment from the temperature outside to the pressures, etc. The second one allows us to plot and view data that's already been taken. Also, if anyone here ever needs help with LABView, I can help. Just PM me or get a hold of me on AIM: mahill2006. AIM is probably faster.