LabVIEW vs C/C++

[3DWolf]

A lot of e-mails my teams advisor has been getting are saying that LabVIEW is going to be pretty much the only supported way to program the robots this year. Weren't we told that we can use C/C++? I personally prefer to write my code then to use a graphical interface, but I'll definitly use LabVIEW for debugging and diagnostics and whatnot, but are there any teams out there going with the standard code-writing method? Can you even still write the code, or is LabVIEW the only way this year? If you can write it, is there anyway to mix LabVIEW generated code or whatever with your written code to use simultaneously?

[Francis-134]

LabView is most assuredly not your only option. You will most CERTIANLY be allowed to use C/C++ with the WPI Library this year. For more info, visit the Resources page of the WPI FIRST website.

[Kevin Sevcik]

C/C++ is supported through the WPI Library, as Francis said. It's important to note, though, the C++ support is lagging Labview in some areas. Also, Labview has a vision assistant wizard to help you set up your vision processing algorithms, which you can then directly copy into a Labview program.

Finally, the Labview and C++ environments aren't compatible. If you write code in C++, you won't be able to directly debug it in Labview, and vice versa. You CAN use C++ library calls in Labview to a limited extent, but I would recommend against trying a hybrid approach where you do most of your coding in C++ and call it from a Labview wrapper.

[Greg McKaskle]

I'm not sure where the emails are coming from. As the beta teams have shown, LV and C++ and in fact C will all be supported. All three use the same libraries developed jointly by FIRST, WPI, NI, and others. All three are fully capable of making a great robot.

If your advisors need further input, please visit the first forums and perhaps look at the C++ code, specifically doxygen formatted docs.

Greg McKaskle

[slavik262]

Originally Posted by Kevin Sevcik

C/C++ is supported through the WPI Library, as Francis said. It's important to note, though, the C++ support is lagging Labview in some areas.

Will this be fixed by kickoff? Our team definately plans to use C++, and it would be unfortunate to be forced to use LabVIEW due to lacking C++ support. I'm not saying that there's anything wrong with LabVIEW, but shouldn't both platforms be equally supported?

[Russ Beavis]

"Lagging" may not be the right word. As Greg mentioned, the Beta teams were very successful in using C and C++ and there is plenty of software written and tested.

LabVIEW for cRIO has been around a LOT longer than C/C++ for cRIO. In that sense, C/C++ will always be lagging.

But that doesn't mean that the tools, functionality and tech support that teams receive over the next few months will be any different. From what I can tell, NI has provided as much or more support for the C/C++ tools as for their flagship LabVIEW tools. WPI, FIRST and others are, of course, "all over" both tools.

Russ

[Kevin Sevcik]

Lagging, in the sense that some of the features that aren't as in demand might not be in the C++ libraries. For instance, SPI is very basically implemented in Labview, but isn't implemented at all in the C++ libraries. Or not yet, at any rate.

[Joe Ross]

Originally Posted by Kevin Sevcik

Lagging, in the sense that some of the features that aren't as in demand might not be in the C++ libraries. For instance, SPI is very basically implemented in Labview, but isn't implemented at all in the C++ libraries. Or not yet, at any rate.

When the beta teams received the software, the C++ version of the WPI Robotics library was more complete then the LabVIEW version. Especially with the WPI Robotics Library, they want both environments to be the same, but they won't withhold a feature that is ready in one environment but not the other. It's really a matter of which developer is available when (and not that features will always be available first in a certain language)

Once a feature is implemented in one environment, it shouldn't be too hard to implement it in the other one. Since a lot of the WPI Robotics library is built around the FPGA, once you know the right FPGA calls (which you get from the other environment), it's not hard at all.

[David Doerr]

We expect to be using C++ this season, but while developing our software we intend to use LabVIEW features not available in C++. One is the Vision Assistant already mentioned. Another -- LabVIEW has an impressive set of PID tools -- automatic and Ziegler-Nichols tuning. Joe Ross has worked with those and he can tell you lots more about them than I can.

My opinion is that C++ support does lag behind LabVIEW. I think there is still no dashboard support. I mentioned the PID tools -- those have caught up a little since the beginning of beta testing. But we did find the WindRiver Workbench C++ tools very capable and a lot of fun to work with, and we expect them to serve us well. Writing, building, downloading and running programs in C++ is very fast once you spend a short amount of time learning the process.

[EricVanWyk]

Originally Posted by DaveD

I think there is still no dashboard support.

Correct, there are currently no provisions to write a dashboard in C++. However, a robot running C++ code can use a dashboard written in LabVIEW. Also, I don't think there is anything preventing people from writing a dashboard in *insert language here*.

[David Doerr]

Originally Posted by EricVanWyk

However, a robot running C++ code can use a dashboard written in LabVIEW.

I don't believe C++ programmers can currently send data from the robot to display on the dashboard -- including either basic I/O data or user data -- but I've been told on the beta test discussion forum that work is being done to add that capability.

[Kevin Sevcik]

Originally Posted by DaveD

I don't believe C++ programmers can currently send data from the robot to display on the dashboard -- including either basic I/O data or user data -- but I've been told on the beta test discussion forum that work is being done to add that capability.

You can set the Digital Outs in C++, at least. I can see where the user bytes go, but there aren't any accessor functions implemented yet. I suspect the problem is coming up with a reasonably clean way to serialize the data teams want to send, such that a Labview dashboard has decent odds of appropriately deserializing it on the other end.