Greetings fellow wire workers. Has anybody considered using one of the SBCs listed here as a target for their LabVIEW programs ? Has anyone successfully done it ? For example something like the Beaglebone SBC (http://beagleboard.org/bone , http://en.wikipedia.org/wiki/BeagleBone#BeagleBone ).
Is there a moderate chance that LabVIEW for Linux would be able to work with the standard inclusion of peripherals such as Ethernet , USB, USB-OTG, RS-232, MicroSD/MMC card slot ? I expect to need to write my own drivers for other peripherals such as I2C, SPI and the general purpose I/O lines etc.
We are seriously entertaining the idea and unless somebody can point out some really difficult problems we might encounter, we plan to buy a couple to evaluate their suitability.
The board you are considering runs an ARM processor, but LabVIEW for Linux is only supported on x86 processors. If you find one that runs an x86 processor (maybe an Atom or some other mobile processor) then it should be possible.
Thanks Adam. What happens if I try to run LV for Linux on an ARM platform, will it simply not launch, or just behave unpredictably?
x86 and ARM are two completely different CPU architectures. The ARM CPU has no idea what to do with the x86 Opcodes in the Linux for x86 LabVIEW executable.
But Linux will already refuse to load the executable since it is not a compatible executable format. It's even more different than trying to run a MacOS X program under Windows (without any form of emulator). And no, running LabVIEW under an x86 CPU emulator on an ARM embedded system is definitely killing its performance to 0.5% if such an emulator would exist.
Thanks Adam and Rolf. It is really dissapointing that NI continues to hold its cutomers hostage to using its own embedded HW which is so expensive, relatively inflexible, large form factored and hardly state of the art. I have tried so many ways to use LV on non NI embedded platforms and perhaps the only viable option left is to investigate the Intel Atom x86 range of embedded solutions running Linux.
LabVIEW sales would increase generously if NI was to release LabVIEW which targets ARM based SBCs/SOMs running say Linux. NI doesn't do this because they prefer to make exorbitant (per unit) profits from their own embedded H/W sales. Embedded computing is here to stay ond growing exponentially. NI recognise the need to give more embedded solutions in their roadmap, but fall short in a major way by choosing not to support (in any serious way) any embedded H/W platform other than their own. (e.g. the ARM generation of embedded offerings.) They have a token gesture solution for CortexM3 and ARM7, but they are dinosaur platforms and LabVIEW runs at ONLY 6-16% efficiency when using more than one loop on those boards (see here). NI market LV as a general purpose programming language. I think it is difficult to make more such a claim anymore when LabVIEW does not target the worlds fastest growing embedded controller (ARM). Of course NI will lose H/W sales, but that will be more than made up for by the increase in LabVIEW sales, not to mention the added respect/kudos they will get too.
NI's share price continues to fall (30% down over the last year relative to the Dow Jones US Technology Index) and I think the best way to arrest this decline is to give their customers the means to program such targets lest they end up using other programming languages to do so.
While it's understandable that you are disappointed the issue is actually a little different than what you think. The reason LabVIEW supports only embedded targets from NI out of the box is that there is a HUGE effort to create a LabVIEW environment to run on any specific embedded target. With their own targets NI has the whole system under control and can make sure it runs smoothly. With COTS embedded targets that is far from true. There are virtually 100ds of different ARM embedded targets (and quite a few other CPU families) with many of them suporting several very different kinds of (RT) OSes. Each of these targets has a specific hardware device selection with many of them requiring their own specific device drivers that adapt to the OS of choice. Putting a LabVIEW system on such a hardware is anything but trivial and quite impossible for NI to do even for a few selected hardware targets. They did it with LabVIEW ARM Toolkit for a few (not using Linux but the Keil RT OS) and almost nobody is using it because it's quite expensive and of course not the HW and/or OS of their choice.
Yes NI of course would like to sell you their hardware and the seemless LabVIEW support for them has a price. And that is not because they want to rip you off, but because targetting any embedded hardware is a very expensive task. NI simply can't support every OS/HW variant out there and if they would try they would be faster out of business than you would need to burn your NI shares :-).
LabVIEW for Linux already shows that it is not as trivial than compiling the LabVIEW source code for the specific OS. Installing LabVIEW on any of the not officially supported Linux x86 distributions is already quite a roulette game, and the embedded target market with different CPUs exponentially multiplies these variations even more. NI doesn't even have an ARM compiler for LabVIEW so far, although that is supposedly not as hard anymore to add since they use the llvm compiler now. Not as hard is however not automatically easy.
How disappointing. As a C programmer the world is my oyster and I can program any platform from desktops, PDA, mobile phones to any microcontroller. With LabVIEW, in effect, there is only the desktop.
National Instruments could extend the LabVIEW Embedded for ARM Tier 1 boards to include 1 (one) more contemporary popular development board, but choose not to. There are only two Tier 1 boards and they are over 6 years old! The effort to introduce another ARM development board is very small. NI could release an inexpensive RIO platform (look up Xilinx Zynq) with a small form factor that plugs into your product (rather than the other way around) for less than $150 (the Zynq chip sells for less than $30 in single units). The list goes on. For more details, see the bottom of the first post on http://forums.ni.com/t5/LabVIEW-Embedded/LabVIEW-Embedded-Performance-Testing-Di fferent-Platforms/td-p/1882581.
Technically, National Instruments is spot on. However their marketing is killing the company - as highlighted by Peter and the dramatic stock price reduction for NI.
National Instruments are trying to herd their relatively small LabVIEW user base that wants to expand into the embedded environment into CompactRIO (very expensive), sbRIO (no prices on the website!) or C Code Generator (ridiculously expensive).
Development environments are evolving at a rapid and exciting pace. National instruments needs to innovate if it is to prosper. And as a LabVIEW programmer, I’m in a symbiotic relationship with National Instruments that needs it to prosper.
National Instruments are exploiting customers to satisfy shareholders. However, in the end neither is satisfied. I may be a single user in the wilderness, but I suspect that my opinion is shared amongst all (non-academic) users who wish to go beyond the desktop. The ability to satisfy shareholders is unquestionable - the share price tells all. Iceberg straight ahead ... what to do.
Hi Rolf. The explanation you present for NI choosing not to target COTS embedded would be believable a few years ago, however given over 6 years has passed since the last ARM targets were introduced, clearly NI do not want to keep releasing new targets otherwise they would have done so by now. It does not take 6 years to target a couple of new platforms that have a good "out of box" experience. In fact earlier this year, NI quoted us only a couple of months work for them to target a new Tier 1 platform of our choosing (which was able to run the Keil RT-OS). Only a couple of months for NI to write the drivers for a majority of the peripherals. And perhaps a couple more months to target all the peripherals on one Tier 1 board. Of course we would have paid them for their efforts, but why should we do that when NI could simply have done it themselves and released a new set of Tier 1 products ? Here are the reasons why we didn't go down that route:
It isn't as hard as you make out for NI to target a new Tier 1 device.
NI choosing to use the LLVM Compiler in LabVIEW now makes it so much easier for NI to target ARM and other platforms.
The other option NI has (which they must seriously consider to stay afloat) is to provide only a limited amount of functionality for a larger set of COTS embedded targets. The community would then take hold of that and start helping each other to write the drivers for other peripherals. NI refuses to let their customers do this because :
All my claims can be ignored, but it is impossible for NI to ignore their dropping share price (30% drop in 1 year is bad). The strategy I propose will generate good will amongst its customers and help NI sales increase. For NIs sake, I really hope there are some NI product managers reading this thread.
Well, you name a few reasons why supporting the ARM targets you would like is not something NI sees much benefit in. The translation of entire LabVIEW VIs into C code is a rather complex and inefficient way to generate code for those typically resource constrained targets. And there is no alternative. LabVIEW is a very complex language to represent in C. It's also not the aproach NI takes for their own targets. Instead they compile a LabVIEW runtime for their hardware target that can execute VIs unaltered without the cumbersome steps of converting them into C, compiling them with a toolchain they have no real control over and keeps staying a moving target. The ARM Toolkit (and the already discontinued AD Blackfin Toolkit) were attempts to see if it could be made workable. The result clearly was that: yes it does work, but no not very well or fast. That added with the sales figures for those Toolkits clearly showed that there has been a lot more effort invested into them, than it has returned so far and chances are not that big that this is going to change, since the aforementioned drawbacks are inherent to these Toolkits and can't really get taken away, without limiting the scope of features considerably that can be used in VIs for those platforms. Once you take out things like inherent multitasking, the translation and execution of code gets a lot easier, but that removes a key feature of the LabVIEW language from it.
The C Code Generator is a way to make use of the already exisiting LabVIEW to C translation engine, without tying it into a specific environment or trying to make entire VI Hierarchies completely into C code. It works and has its niche usecases, but its pricing, while not even extreme in comparison to other EDA tools like FPGA compilers, is kind of prohibitive.
And yes LLVM makes supporting other CPUs a lot easier, but the CPU compiler is only a small part (albeit a complex one and one only few experts can manage) of supporting a new platform. It all needs to be tied together, many corner cases, exemptions, differences and variations need to be identified, fixed, worked around or otherwise prevented and last but not least, a considerable amount of every single release for every single platform is the testing, packaging and testing again. But with embedded targets (and even more so when using Linux on them) the system is very loosely defined in comparison to the existing Desktop solutions. For a Desktop it is relatively easy to create an executable that runs on a large scale of hardware platforms, since the underlaying OS like Windows or MacOSX takes care of almost all differences that might exist there. For embedded devices all your executable can assume is that there is some CPU, some working memory, probably some form of disk that can be accessed through the OS, maybe a network, and everything else may or may not exist, may be enabled in the kernel or not and even more maybe working reliable. That's all ok as long as you work in your own toolchain environment tailored to that target but makes building a LabVIEW runtime engine rather hard and one that works on more than a few very specific targets almost impossible.
NI doesn't believe that engineers and scientist must always have solutions that work out of the box. But a vast majority of customers do expect a seemless work flow from their tools, and don't want to be bothered to figure out how to install a Linux platform with all their sometimes conflicting dependencies to support a new software tool. That doesn't mean that NI doesn't support Linux too, as you can see, but the money clearly is not there. Most users of that platform are in fact academic instititutions, and to make raw sales figures look even worse, they almost never pay the normal license price.
And taking NI share prices in this discussion is clearly a misconception. First, shares have been droppping all over almost every technical company in the last year, as investements into new projects have been cut down considerably because of the anticipated economical crisis. It's simply representing the overal sentiment in technological investments. But if anything would influence that in a positive way, it would be probably more in the decision to throw out Linux, and several other supported platforms in favor of NI's proprietary solutions that succeed in locking customers more into the NI way. That they don't do that is something I find positive. And I'm not saying that it would be a good thing to drop all minor platforms and what else, but those economists who decide about what a company share should be valued, have no technological heart but only an economical, and current economics tend to look only until tomorrow. They rather take 1000 $ gain tomorrow, than 100$ every year for the next 20 years. Who cares if a company goes belly up after they garnished the 1000$ gain?
NI's business model has never been about creating low cost products that make their profit in selling it many million times. It's also not what I think would be a good business model to do.
....The translation of entire LabVIEW VIs into C code is a rather complex and inefficient way to generate code for those typically resource constrained targets. And there is no alternative. LabVIEW is a very complex language to represent in C. .....
And yes LLVM makes supporting other CPUs a lot easier, but the CPU compiler is only a small part (albeit a complex one and one only few experts can manage) of supporting a new platform. It all needs to be tied together, many corner cases, exemptions, differences and variations need to be identified, fixed, worked around or otherwise prevented........
but makes building a LabVIEW runtime engine rather hard and one that works on more than a few very specific targets almost impossible.
When you describe it in those terms it does appear a daunting exercise if one takes a target agnostic approach. However, whatever the obstacles, NI needs to at least be on a par with what MS are doing with their .NET Micro Framework that targets tens of different COTS embedded platforms. NI aren't anywhere close and aren't even planing to. Telling their customers it is too hard to target COTS embedded platforms and they instead must pay a premium for NI H/W will not keep customers at NI, it will tempt them to jump ship.
The C Code Generator is a way to make use of the already exisiting LabVIEW to C translation engine, without tying it into a specific environment or trying to make entire VI Hierarchies completely into C code. It works and has it's niche usecases, but it's pricing, while not even extreme in comparison to other EDA tools like FPGA compilers, is kind of prohibitive.
I'm glad at least one other person has taken the time to actually ask NI for a price of their C Code generator. There is NO way they will sell more than a couple of licenses at that price. I could employ a juinor programmer for a year for the amount they are asking. That C Code generator is part of LV Embedded for ARM which costs about 1/4 the price. The prices for both those prodicts are simply artifically created to seriously reduce demand. There is no viable competitor product so the prices aren't driven by market forces.and NI are free to set the price wherever they choose. At those prices, clearly NI don't want people to buy it because it will enable people to target ANY embedded platform they desire (to varying dergrees of success depending on their C skills). That would cause NI to lose H/W sales which would be unfathomable to them. Can you see any other justification for such high prices in the absence of a competitor ?
And taking NI share prices in this discussion is clearly a misconception. First, shares have been droppping all over almost every technical company in the last year
If you have a look at this link I gave in my post above you will notice that the index I compared NI to was the Dow Jones U.S. Technology index which is very comprehensive and includes 157 constituents/companies. That index has risen 10% over the past year which means that almost every technical company has not dropped, In fact on overage the top 157 (by market cap.) have risen by 10%. NI has fallen by 20% which is a 30% fall relative to that index. I agree economists can be short sighted. Market analysts spend their living pouring through info from everywhere including posts such as these in order to come up with their buy/sell recommendations. In fact they will have read the following Embedded Systems Outlook from NI (here) and then attempted to match NI's claims with reality. If they see sufficient disparity they will be advising their clients to hold or sell NI stocks.
NI's business model has never been about creating low cost products that make their profit in selling it many million times. It's also not what I think would be a good business model to do
I know, but something is wrong with that model if it doesn't serve the needs/wants of an increasing number of their existing customers. I'm certainly not alone in my desire to run LV on embedded targets other than NI H/W.
I know, but something is wrong with that model if it doesn't serve the needs/wants of an increasing number of their existing customers. I'm certainly not alone in my desire to run LV on embedded targets other than NI H/W.
And this is were everything you say goes wrong. While it would be certainly nice to use LabVIEW Everywhere as they had it some time ago as marketing slogan, doing this on non-NI hardware will have very little return of bucks for the bangs NI would need to invest in this. You are not the only one wanting that, but the numbers of those who would do it and cash out several 1000 bucks extra every year for this aren't that big either.
LabVIEW always has been a tool to sell hardware and not a cash cow in itself, but doing what you request from NI, would take out the hardware sales and increase LabVIEW sales only very marginally. It would be in fact diametral to sustaining good share prices, since those analysts don't care about how many devices will run Powered by LabVIEW (TM) but how many dollars that will bring into NIs pockets. So complaining about NI share prices in this respect in fact only weakens your position further.
PS: The 30% drop you claim happens to be in respect to the all time high of the NATI stock. If you disregard the intense (+30% outlier of last year and compare it to a longer period, NATI does compare fairly well to both NASDAQ and Dow Jones. As a single stock it obviously has bigger outliers both positive and negative to an index that is an agregate of quite a few different shares. If you take Apple as a comparison everybody else does bad in comparison to that with several 100%. Just to show what % numbers mean.
My conclusion following this dicussion is: LabVIEW is great on the desktop, but when it comes to the embedded world, NI has nothing to offer.
I would say it depends how you define embedded.
If you mean low cost 3rd party single board computers, especially running Linux, then you are absolutely right. Chances that this is going to change anytime soon are virtually nonexistent, since there is no business for NI there.
However looking at the SBRIO platform for instance there is certainly an offering from NI that can be used for embedded applications.
By "embedded" I mean everything but the desktop. This includes LabVIEW Embedded for ARM and the various LabVIEW RT/FPGA platforms. (Possible exceptions are LabVIEW PDA and similar, since I have no experience with them.)
The closest to suitable embedded offering from NI is the sbRIO platform, but it falls short for reasons that will be explained shortly.
I have used cRIO to develop test equipment. This was started about 8 years ago and at the time it was felt to be the right platform. We've built 14 of the test equipment and each of them cost about $15,000, with cRIO making up about $6,000 of that. Today, there's an effort to build more, but at a lower cost. The target cost is $5,000 to $8,000, which will be hard to achieve when the cRIO costs $6,000 The sbRIO should be able to let me achieve the cost target, however, NI only sells them with a minimum quantity of 100. So, once again NI's marketing is getting in my way. (There are ways around this.)
If I was to start the development of the abovementioned piece of test equipment today there are many more capable platforms available at a fraction of the cost of cRIO and with much more processing power. The BeagleBone is just one example. You can also do some powerful processign with multiple microcontrollers.
Currently, we are about to develop a hand-held test instrument that we are building several hundred of. The target price of the test instrument is $1200, with $200 budgeted for the main processor/module. This precludes the sbRIO since its starting price is about $600. In any case, the size of the sbRIO is too large to fit inside the required case. So, in the end sbRIO was ruled out based on price and form factor. We examined LabVIEW Embedded for ARM. A great concept and it would be perfect, except we found that only about 10% of the microcontroller’s processing power was left over after the OS/LabVIEW overhead. We would gladly accept this by moving up to a more powerful ARM9/ARM11/etc processor, but NI only have ARM7 and Cortex M3 microcontrollers on offer. It took me 2 months to evaluate LABVIEW Embedded for ARM and I dearly wanted to use it since I like programming in LabVIEW. However, much to my frustration, it was not suitable. So, what did we do in the end? We’ve decided to use two ARM Cortex M3 or similar processors (one to perform hard real time and the other to handle everything else) with programming in C. Cheaper, more efficient and with much more support - albeit not in my favourite programming language. (I'm even going to dabble with .NET Micro Framework just to see how it fares for future development.)
The sbRIO is getting close to a good embedded platform, however it has several problems. None of them are technical and could be resolved by NI, but once again, it’s the marketing that gets in the way.
1) Minimum purchase quantity of 100. Assuming I only want the processing functionality, the cheapest sbRIO board is about $600. This means that a developer would need to spend at least $60,000 in sbRIO boards. The same level of performance can be obtained in a SBC that retails for $150 (actually, much better can be achieved, but let’s keep this conservative). So, a developer has to spend an extra $45,000 for the NI solution. What do they get for their $45,000? My estimate is that in a typical development effort of 1 man-year (requirements capture, system design, detailed design (hardware and software), hardware design, programming, unit test, integration test, system functional test and documentation) I will probably save 2 months of effort by using LabVIEW. That’s about a $25,000 development effort saving. So, sbRIO is not cost effective – at least for 100 units. And the cost benefit gets worse if I’m building more.
To me, sbRIO makes sense if you are building about 10 units. (For 1 or 2 units, cRIO makes sense.) Once you get beyond a few dozen, it’s better to switch to one of the very capable and open source boards and C or .NET Micro Framework. Incidentally, regardless of how many units are projected to be built, I have found that we always build more. So even if someone tells me the most we’ll ever build is 10, I use 20 (or 40) in my buy versus build analysis.
2) Price. As detailed above, for more than about 10 units, the price is a problem.
3) Form factor: The sbRIO has all the communication connectors installed. This means that your product must be developed around the sbRIO rather than the sbRIO fitting into your product. The way I would like it is the way the ChipworkX Module does it (http://www.ghielectronics.com/catalog/product/123). This is a sub-credit-card sized boards that readily plugs into your product and also has a development board that has all the communications connectors, display etc. This is a true OEM approach.
4) Price is not on the website. This makes it difficult for me to compare boards or make a business evaluation.
There is an opportunity here for NI to have a compelling product. The recently released Xilinx Zynq chip will allow NI to have an OEM friendly form factor. The board could be sold in single quantities for $150 each and there would still be a healthy gross margin of over 50%.
The Xilinx Zynq chip is both NI’s greatest opportunity in the embedded space and its greatest threat. The opportunity is to develop and market the board mentioned above. The threat is that if NI doesn’t do it, someone else will. The Zynq chip will result in an integrated development environment that targets both the microcontroller and the FPGA. What this will look like I don’t know, but it will happen.
LabVIEW Embedded for ARM
If NI develops LabVIEW Embedded for ARM to target a contemporary high-performance board (such as the BeagleBone) it would have a winner. I believe the performance issue can be resolved. My investigation has put the poor performance to an (expensive) context switch once per loop iteration. If this is the case, each loop could have another input called “switch iteration” it would be possible to select the appropriate number of loops before a context switch is initiated.
I’m sure technically NI could have a powerful product here. However, once again, marketing …
National Instruments' share price
NI’s share price has been dropping. Not over a select period of 1 year, but over any period over the past year. Relative to the Nasdaq, it has fallen 20.6% over the past year, 13.5% over the past 6 months (~27% annualised) and 7.4% over the past 3 months (~29.6% annualised). So, no matter what time period you take, it’s about a 2% decline each and every month. This is significant.
A company’s share price is the universal score card. It is the true reflection of its underlying value and cannot be manipulated (unless there is (illegal) false information). It can deviate for a short time, but it must come back to represent the true value of a company.
C Code Generator cost
The C Code generator cost is prohibitive. There was a mention that this compares favourably with EDA tools like FPGA compilers, however my search has found that FPGA development systems range from free to $2,500. The C Code Generator is at least an order of magnitude more expensive.
My strategy is to become proficient in LabVIEW (desktop, RT, FPGA and Microcontroller) and C/C# (.NET Visual Studio C# desktop, .NET Micro Framework and Code Composer Studio C). This is to ensure that each time I embark on a new project I have the skills to target the development environment and platform that makes the most business sense and not to be restricted by a limited skill set. This is particularly important since LabVIEW is a proprietary product with effectively no competition to drive innovation and pricing. I would suggest that all developers that include LabVIEW in their arsenal should also do similar to ensure they target the best development environment and platform on a case-by-case business case.
Don’t get me wrong, LabVIEW is great on the desktop, but when it comes to the embedded world, NI has nothing to offer. NI could fix this, but chooses not to. I consequently am broadening my skill set. It will make me a better engineer. I hope that for the next project in about a year’s time things are better in the LabVIEW camp, since programming in LabVIEW is fun.
This is an interesting and constructive post for sure. I'm not sure I will hold my breath for NI to support a BeagleBone type board. Whatever board they would choose, it would be considered by a majority of potential users as the wrong one, for varying and sometimes very arbirtrary reasons. Besides of the fact that it does not give NI much sales in the end.
The Xilinx Xynq chip most likely is already in their development labs and gets a full workout in various ways. If there will be a product with it is another question, but it fits much better into the NI business than a BeagleBone board. NI won't comment on this yet, until they have a product ready to show on some event like NI week. And it of course takes some time to come up with such a product, as developing the hardware is not enough. There needs to be done quite a bit of complicated development work and testing for the seamless integration with LabVIEW.
Betting only on LabVIEW is certainly not a good idea. You need to keep your options open although I'm sure that betting on MS in the past for our development environment would have much more often forced us to change direction than NI has. MS has this tendency to introduce a new technology and evangelize it as the newest all in the world development paradigma, only to abandon it after 5 to 10 years to be replaced by yet an even "better" one, with less than ideal migration paths. The days of .Net are already getting counted!