Make labview everywhere a reality

[falkpl]

I have used labview for a long time and avid user.  One issue I have been hitting lately is the "LabVIEW everywhere" slogan never really panned out, it has become LabVIEW everywhere NI allows it to be.  I am getting jealous of the Arduino and Rasberry Pi and hundreds of PICS and ARMs not avaliable to me (Yes I have the pro liscence but not embedded).  I wish Labview pro opened up the toolchain and started porting to many other platforms by default.  I am seeing jobs that labview is loosing ot to where it should be much more competetive like the embedded market. 

Essentially I am looking to see the Labview development environment easily work with toolchains for the most popular processors and also open up a simple standard to add targets to projects. 

Wouldnt it be nice to program a $25 ardunio dirrectly from labview (NO THIS IS NOT WHAT THE TOOLKIT IS DOING).  Add a Ardunio target file (maps the io memory to variables and throw down a loop, boolean shift register, a wait and a digital line variable, download to the micro and the blink led example is done.  Really open up the doors for LabVIEW everywhere.

[vitoi]

Well said Ernie. We did our part promoting LabVIEW and singing its praises and now it National Instruments' turn to deliver LabVIEW Everywhere as promised.

[RavensFan]

---

Peter_B wrote:

The fact that a relatively trivial "Opacity/Semi-Transparency appearance settings for attractive Front Panel objects" idea gets more than twice the votes in less time tells me that you LabVIEW users are content with playing in the sandpit rather than thinking BIG.

---

---

Vitoi wrote:

Surely the smaller Boolean constant is far more useful to us LabVIEW programmers than better embedded offerings including microcontrollers and more OEM friendly sbRIO 🙂

---

I know you are being sarcastic, but actually the smaller Boolean constant probably is far more useful to LabVIEW programmers as a group.  Everyone who uses LabVIEW has to use the Boolean constant at some point.  However, only a small subset of LabVIEW programmers need to use embedded controller hardware.

I'm not saying this idea isn't a perfectly good idea.  I believe it is.  But please don't admonish the readers of the forum for not voting for it.  The readers are going to vote for ideas that are important to them.  And this may be the more superficial or trivial ideas get a lot of votes because they appeal to a broader user base rather than bigger game-changing ideas that might only appeal to a small percentage of users at this point in time.

Remember, the total amount of votes doesn't directly affect what ideas get implemented and which are not.  But it does help guide NI for a level of interest.  Even if this doesn't get some record number of votes, NI is still looking at the idea and evaluating it.  And this idea is one of those that won't ever technically be implemented, but that is because it will be something that has to evaluated at a much higher level of marketing and "roadmap" planning, and hopefully for those in favor of this idea, it will come to fruition.

[RavensFan]

Surely the smaller Boolean constant is far more useful to us LabVIEW programmers than better embedded offerings including microcontrollers and more OEM friendly sbRIO 🙂

[vitoi]

I actually like the little touches such as the smaller Boolean constant. Collectively, all these small changes make my life easier. And yes, I'd like to see more.

However, I'm also after some game changing innovation, which has been lacking lately. This innovation can either be technical or marketing orientated.

Although only a few LabVIEW programmers would be directly interested in embedded programming, I suspect the vast majority of LabVIEW programmers would like the option/possibility of programming embedded devices in LabVIEW and, perhaps more importantly, more people would commit to learning LabVIEW if they saw exciting options beyond the desktop.

[Mads]

Kudos.

9 out of 10 ideas here on the idea exchange is about improving the IDE. Changes that are convenient for the task of programming, but which have little effect on the value of the end products; the applications we build. The focus is just too near-sighted.

Sure, you can say that improvements in the IDE will allow more productivity and less bugs, but that's an indirect effect that just does not deliver enough in the long run. The size of the boolean has never caused any bugs or decreased my productivity, but something as simple as not being able to scale controls on a tab page properly for example does.

LabVIEW everywhere would be great, especially if it also meant life-time support (it would have to) so that you could develop code for an embedded device today, and still be sure to be able to support it without a huge amount of hassle 10 years from now. We love LV and actually put NI hardware subsea for 25 years of operation now, but not being able to choose hardware more freely (right now there is only 1 target from NI available that delivers the IO we need,  and it is supposed to go obsolete in 1 years time - and has significant weaknesses on its dual networking capabilities) - and having to support LV2011 code in LV2026 puts us very close to the point where we would need to look for solutions elsewhere.

[Peter_B]

---

Ravens Fan wrote:

I know you are being sarcastic, but actually the smaller Boolean constant probably is far more useful to LabVIEW programmers as a group.   

---

Actually I wasn't being sarcastic !    If I went to each LV programmer and posed the following question to them, what do you think their answer would be:

"If you had to choose between having a smaller Boolean constant on your BD, or having LV run on all of the following targets: Your Smartphone, your Tablet, your 32 bit Arduino and ARM microprocessors,  what would you want ?".  I'll bet the vast majority would pick the latter.

The point I'm trying to make is that "LabVIEW Everywhere" doesn't just mean targetting some obscure embedded platform, it means having LV run on many popular platforms.

---

Ravens Fan wrote:

But please don't admonish the readers of the forum for not voting for it.

---

I wasn't admonishing them, I was encouraging them to see the bigger picture and consider voting for it.

If everybody continued to focus on ideas that only add small cosmetic and functional changes to LV,  then the amount of "innovative" ideas commited to LV by NI's R&D will continue to offer less and less value to them and their customers.  NI's visionaries need the freedom to implement their big ideas and not be held back by unfounded fears of NI losing market share/control/revenue etc.   Actually if they don't do something big like this soon then NI will continue to lose value.  Don't take my word for it, look at how NI's share price continues to fall (30% down over the last year relative to the Dow Jones US Technology Index).

[vitoi]

I for one would be thrilled to be able to use LabVIEW to programme my smartphone, tablet, Arduino, BeagleBoard and OEM-friendly sbRIO ( http://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Smaller-and-cheaper-sbRIO-based-on-Xilinx-Zynq/id... ) LabVIEW just on the desktop is too limiting.

[GuenterMueller]

vitoi: I get an error when trying to follow the link you provided.

[vitoi]

Here it is again http://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Smaller-and-cheaper-sbRIO-based-on-Xilinx-Zynq/id... or just see the top entry on this page http://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/idb-p/lvfpgaideas

[GuenterMueller]

Thanks vitoi. The 1st link works.

[falkpl]

I was looking over the links to similar topics and found the discussion very interesting.  What I am proposing is a game changer.  I am not trying to cut NI out to the HW marked just help focus them into a market thay can be very influential in, embedded SOFTWARE.  The price points of the embedded system market is so low that NI should not try to compete in Hardware but leverage this to expand the scope and reach of this LabVIEW IDE.  MAKE IT EASY FOR THE VENDORS OF THESE HARDARE TO USE LABVIEW,  this would mean opening up the toolchain on the other side of labview to use 3rd party hardware and define targets in the labview project.  If suscessful the hardware and compiler vendors could use this as a way to make using their products "LabVIEW EASY" in return for higher sales of their products.  AGAIN THESE PRODUCTS DONOT COMPETE WITH NIs offerings except for very low end daq.  I would not mind seeing ni then start offering higher end solutions to complement the low cost offerings already out there.