LabVIEW
Share Your Input: The Next LabVIEW Feature to Go Open Source
I'd go with the following list :
- Modbus
- FPGA Timekeeper
- Ethernet/IP
- Quick drop
- Vision VIs
- Anything that is related to a protocol
LabVIEW Embedded (microprocessor SDK, Blackfin and\or C generation, etc.)...
I think it got cancelled for pure financial reasons. Technically, it was neat.
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
LabVIEW Embedded (microprocessor SDK, Blackfin and\or C generation, etc.)...
I think it got cancelled for pure financial reasons. Technically, it was neat.
I don’t think it was simply financial. Unsustainable for sure though, such a thing is simply unsupportable. Using those toolkits turned out for the typical LabVIEW user harder than rocket science. Adaption to any new target hardware was extremely complex and cost a lot of work and expertise. The resulting code was bloatware and very difficult to modify without very deep target expertise. Anyone with that necessary expertise would rather grab their favorite embedded development toolchain, which they need anyhow to turn the LabVIEW generated code into an executable form, and write something from scratch in C. Not-really more effort, much conciser resulting executable and no 5 figure extra license costs for an extra tool besides the embedded compiler toolchain
And open sourcing that part would pretty much mean open sourcing whole LabVIEW. Besides, several parts of the Embedded Microprocessor Toolkit, which was the enabling technology for the other more target specific toolkits, where completely removed from the LabVIEW source code ca 2018/2019 and would almost certainly not compile cleanly anymore without serious effort when adding that code back in.
@JÞB wrote:
@billko wrote:
Let's make NXG open source. Couldn't hurt.
Didn't your mother tell you not to pop that pimple? Or not to make that face "It may freeze that way?"
It could hurt...
....sorry Mr. Ko. I didn't mean to slap you quite that hard. But , a WWYT? "Gibb's slap" seems about right
It had some interesting concepts. Unfortunately, along with it feeling like a beta for a few years plus some design choices I strongly disagreed with (OpenG NXG was so severely crippled by these choices that I think not even 40% of OpenG was ported), it lost steam.
I'd like to see what the community could come up with.
@rolfk wrote:
wiebe@CARYA wrote:
LabVIEW Embedded (microprocessor SDK, Blackfin and\or C generation, etc.)...
I think it got cancelled for pure financial reasons. Technically, it was neat.
I don’t think it was simply financial. Unsustainable for sure though, such a thing is simply unsupportable. Using those toolkits turned out for the typical LabVIEW user harder than rocket science. Adaption to any new target hardware was extremely complex and cost a lot of work and expertise. The resulting code was bloatware and very difficult to modify without very deep target expertise. Anyone with that necessary expertise would rather grab their favorite embedded development toolchain, which they need anyhow to turn the LabVIEW generated code into an executable form, and write something from scratch in C. Not-really more effort, much conciser resulting executable and no 5 figure extra license costs for an extra tool besides the embedded compiler toolchain
And open sourcing that part would pretty much mean open sourcing whole LabVIEW. Besides, several parts of the Embedded Microprocessor Toolkit, which was the enabling technology for the other more target specific toolkits, where completely removed from the LabVIEW source code ca 2018/2019 and would almost certainly not compile cleanly anymore without serious effort when adding that code back in.
All true. (Mostly, adding some targets (like eCos and 'vanilla' Linux) wasn't that hard even for a noob (of the target) like me. I got a LabVIEW FTP file exchange working on both, in a few days.)
I'd definitely want to cherry pick things from it.
Esp. the working of the target project providers would be of interest. Opening the source might not help with that of course.
wiebe@CARYA wrote:
Esp. the working of the target project providers would be of interest. Opening the source might not help with that of course.
No, it seems to rely on some sort of DLL (the files have an mxx extension but are really just DLLs) that defines some entry points although the actual DLL content seems rather template like with only little actual differences between the various providers. I assume it was done like that for performance reason. But there is also an obfuscation factor, as those providers also require a mxxlic file with proper signing in order to be recognized as valid project providers. It doesn't seem strictly necessary as proven by other project providers that are at least partly documented and VI based, but also protected with a signing procedure. The Hobbyist Toolkit target project providers may be the closest to documentation that you can find, although that too looks obfuscated by its DLL interface.
