Filipe Altoe

Totally agree. I don't think NI would go after the end user of the third party product, but just the potential liability I think will be enough to hold up adoption. Like you said very well, we wouldn't expose our companies/clients to a potential dangerous loophole. I am sure many others will follow this way of thinking also. Moreover, I do think NI would go after the vendor if their product starts making a wave; so there is the obvious risk of interruption of support in case the Company goes away. I was considering this HW, but always had in the back of my mind a funny feeling it was in violation of some IP/EULA somewhere. I am glad the specific EULA clauses were brought to light in this forum (I hate reading EULAs  ).

The unfortunate thing is that this company could have elected to take the EULA free route to deploy LV to a cheaper FPGA target and have a much higher chance of success. Though that is a much (MUCH!) longer R&D road than the one they took; as my company felt first hand when we developed the Raspberry Pi Compiler product. 

As my accountant says, "Everything is tax deductible until you get audited". I think the case is similar with EULAs. They may be worthless until a lawsuit is filed; then they become evidence as they are a contract between the SW vendor and the user of said SW. I am not a lawyer, but the way I read these clauses, it seems not only the maker of this HW would be in violation of the EULA but also an end user of LV FPGA who decides to use it with this third party HW. Be as it may, something like this on the EULA about LV FPGA may be enough for companies to be afraid of adopting this new hardware. A shame as the community could use a less expensive HW option.

34 minutes ago, PiDi said:

Out of curiosity I've looked for any restrictions that NI put on their FPGA module in licence agreements.

All Xilinx EULAs provided with NI software have following note:

Fair enough, you can't use any Xilinx tools without LabVIEW. But what's the "licensed use"? Is it limited to NI hardware? Interestingly, I can't find any restrictions for the usage of FPGA module in my LV2015 SP1 installation. There are very specific limitations in some documents "in the Internets" - like the one here, apparently from 2009:

As I said, I can't find anything like this in newer documents. So either NI waived this restriction or it's still there but now it's abstract enough so you need an army of lawyers to decipher it (as a matter of fact, the "license" folder in NI software would need an army of lawyers anyway  ). 

I doubt NI would wave any IP restrictions. They are very good at IP protection. All of this would be a no issue if the work was done outside of the LabVIEW FPGA package, straight from the interpretation of the LabVIEW VI and linkage with the Vivado Webpack free Xilinx tool. Granted, this would be restrictive as to what types of Xilinx targets one would be able to deploy LabVIEW code to as the larger/beefier FPGA targets require the paid Xilinx tools. However, at least the Company would be free from the potential legal shenanigans that in itself could be prohibitive for the community adoption of any alternate HW targets.

Hi Brian

Yes; I knew that was coming. It is still ok as NI's is for non-commercial use only and it only deploys the VI block diagram whereas ours also run the front panel.

Good question.

Even though that is theoretically possible; we have decided not to open that Pandora box. The main reason being that different Linux distros have some subtle differences on how they handle graphics. And, they can actually be different enough to generate run-time problems. Since the RasPi for LV compiler allows front panel deployment, we would be swimming in a pool of support hell if we allowed any Linux distro/target under the sun.

We will not stop on the Pi; but will do a controlled release to other targets as we want to make sure we run some heavy tests on specific distros to make sure things work to some baseline standard before release.

Hi David;

We are not planning on including support for Shared Variables on the first release of the compiler. This is not to say it may not come on follow one releases as we will always listen to the community on the most wanted features and gradually add support to them based on the ones that are asked for the most.

In regards to the Pi 3; yes, it will run on the Pi 3 just fine.

Filipe

Pi in the sky indeed.

This is in the list of yellow features; which means it is still unclear whether or not they will make it to 1.0. They are on the queue though; which means they will come about either on 1.0 or on a follow on release.

Hi Mauricio

Not a firm date yet. We are wrapping up the beta program in the next couple of weeks. Version 1.0 will include support for the GPIO connector features and Ethernet support but probably not USB.

Thanks Jim. Yes; editing the XML did work out great. 

Hi LogMAN;

Yes; I didn't know the VIPB file was XML. I just assumed it was a binary file. I decided to try to open it in a text editor and from that point I ended up editing what I needed straight from the file. Thanks for taking the time to answer it.

Cheers.

Filipe

Hi Guys;

Quick question. I have an old VIPB file for a project and would like to use it for another project. My main interest is to recycle the Palette as I customized it to include a bunch of LV primitives on it. I thought it would be just a matter of saving the VIPB file As another name and change the Source Directory in the Build Information Section. The thing is though, once I change the Source Directory on the new VIPB file, VIPM dumps the old palette altogether and creates a brand new one with the directories that are part of this new Source Directory. Is there a way to reuse the palette from one VIPB file on another one?

I'm looking for an easy button to avoid having to spend hours basically replicating what another package already has.

Thanks!

No; it is a totally different product.

@Benoit;

We are still in the process of defining the final set of primitives that will make to version 1.0. We are looking at releasing the Beta package by this coming weekend (hopefully).

Hey guys;

We are going Beta on the LabVIEW for Raspberry Pi! We should be releasing it before Christmas. We have a sign up sheet on this link (very archaic process due to an absolute lack of time to do anything more formal as we have been all hands on deck) if you would like to get your hands on the Beta release and have some fun over the Holidays...

Cheers

Filipe

Hello Hooovahh;

You hit a nerve on the event structure.   We are currently looking at the best way to implement it and are not sure yet if it will make it to the first release. That one is the challenge for the front panel stuff. Just like the Arduino Compatible Compiler for LabVIEW, we are interested in getting something in the hands of the community as soon as possible and let the feedback guide the short term feature set. However, since the Pi is MUCH more powerful than Arduinos, there will be less limitations than on the compiler for Arduinos. Just to cite a few, we will have parallel threading right off the bat, so a typical producer consumer is fair game, with queues and multiple loops in parallel. That is how the Vib Monitoring demo I mentioned was implemented and is working.

We probably won't have property/invoke nodes, and the synchronization primitives (notifier, rendevous, etc); and as far as data types, I don't think we will have waveform. But will have clusters/typedefs. Won't support LVOOP. These limitations are for the first release and it is not to say they won't make it later. Other than that, I don't see other big limitations for the first launch. Don't take this as set in stone yet as we are about 4 months away from release, so the final feature set will become clear a little later. In the last couple of weeks, it has been all about NIWeek week prep, but we will hit it hard again once that is past us.

As far as pricing, we haven't decided yet, but don't think it will deviate much from what we did for the Arduino one. Still TBD at this time though.

As a way of getting a LAVA community member geared up and ready for when we release the Raspberry Pi Compatible Compiler for LabVIEW, TSXperts will be donating a Raspberry Pi B+. 

http://www.tsxperts.com/labviewforraspberrypi/

See you all there!

Filipe

Thanks for this Vito! We are certainly excited about it and it is great to get feedback from the community. Actually, the first release will indeed support the Due, Yun, Mega and Leonardo, along with the Uno. So we got the official Arduino targets covered. Since we are targeting having the same compiler supportting all these targets, and, as you know, the Uno has only 2k of memory, we decided not to implement multithreading on the first version. This, is however, intended to be just the first release, and we are hoping the feedback from the community as feedback will help us focus on what is more important to the user base first. 

As Engineers, we ourselves started falling into the trap of adding lots of LabVIEW features into the compiler. Then we realized (duh) that LabVIEW has been a work in progress for 30 years and by dozens of R&D Engineers working full time on it. We couldn't possibly attempt to match its full feature set at a first release. We figured it would be best to have something released in a reasonable time frame, collect the feedback from the community, and let that better guide us in gradually adding the most asked for features first.

Hopefully the level of adoption will gives fuel to keep improving the compiler and even maybe porting it to other targets,   

Hi James

Thanks for the offer. I will certainly keep that in mind. And hope to see you again at NIWeek.

A portion of the development is being done on a Mac; so I don't think it should be a problem.

But we haven't done any specific testing as of yet to officially claim we support it. As for the Teensy; it will be supported. Any official Arduino target released by the Arduino organization will for sure be supported.

I'm really looking forward to getting this to high schools and potentially even middle school. We haven't decided on pricing as of yet. We will have two versions; base and professional. One targeted to the hobbyists and the other for more complex professional applications. I'm passionate about the makers movement; therefore, pricing will be in line with it for sure. Based on how much work this has been so far; we should charge $10k per license (like NI does for its C code gen).

But it won't happen.

Michael is right. It does not use the C code gen toolkit; otherwise it would cost $10k + a tinny little bit for the Arduino piece. 

This way we can charge just $(a tinny little bit for the Arduino piece).

Not only that but we have better control over the type of optimization we do that is more specific to the Arduino target. As you can imagine, if we were to leave the result of the LabVIEW code interpretation without any optimization on the code generation side, we would starve an Arduino Uno before we could complete the "Hello World!" sentence of the test VI. 

Btw; check out this video we just posted showing a demo of the compiler.

https://www.youtube.com/watch?v=DE2we6o7erI

Currently; we have done all our testing with LV2014 and will release the first version for that version only. If the community requests other versions, we may do that based on the volume of the requests. It will be a paid tool; however, we are aligning ourselves with the makers movement; i.e. it will be very low cost. The actual price of the license is still being decided on and I will share with the community as soon as it has been defined.

Hi ViSci;

I may take you up on your offer of becoming a beta tester. Not sure exactly when we will reach that stage; but it is coming soon for sure if we want to keep the March time lime for release.

Answering your question; yes, the compiler supports all basic LabVIEW primitives structures (case structs, for, while, sequence) as well as subVIs along with over 100 other LabVIEW primitives. A lot of work! But we are excited about the doors something like this may open to the LabVIEW community.

One thing to keep in mind though is that Arduinos (especially the little UNO ) are very small embedded micro controller targets. Therefore, even though the compiler will support arrays and strings, like LabVIEW does, one needs to be extra careful when using those constructs as they are memory vortexes. They will suck the life out of an Arduino Uno very quickly.