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.

Hi guys; As a friendly heads up, the LabVIEW compiler for RasPi has been released (can you hear my sigh of relief through my post?)... The downloads and documentation are available on this Github repo. Cheers and hope to see you all at NIWeek 2017. I'm supper excited with the possibility of no longer being on the verge of a heat stroke in Austin every NIWeek... This coming one will be my NIWeek number 17 and it will be a new experience for sure. If I don't catch you at the LAVA BBQ, come to our booth to say What's Up.

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.

Hi guys; Wanted to share another exciting upcoming tool we will be releasing in the next few months. The Programmable Wireless Stamp is a tiny (but powerful) wireless hardware target we will be able to deploy LabVIEW code to by using the Arduino Compatible Compiler for LabVIEW. Some high level information on the link below. http://www.tsxperts.com/programmablewirelessstamp/ Our goal is to create an easy to use LabVIEW IoT platform that will allow us to quickly and inexpensively create wireless data acquisition systems and IoT applications. We don't have final pricing on it quite yet, but will be sharing that with the community as soon as we do. It is a great time to be an Engineer... Filipe

Hi Guys; Now that the Arduino Compatible Compiler for LabVIEW has been launched for a few months, it is time to tackle the next challenge; having LabVIEW code deployed to my favorite dessert: Raspberry Pi. http://www.tsxperts.com/labviewforraspberrypi/ My personal favorite thing to do lately has been to watch LabVIEW GUIs running on a Raspberry Pi connected to a small monitor. We got a cool demo of a Vibration Monitoring and Alarm system using an Arduino and a Raspberry Pi; both programmed in LabVIEW. If you are making to NIWeek this year, make sure to stop by our booth to check it out. Once the NIWeek madness is out of the way I will post a video of it. Cheers Filipe

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.