Jump to content

Filipe Altoe

Members
  • Content Count

    26
  • Joined

  • Last visited

  • Days Won

    8

Filipe Altoe last won the day on October 17 2017

Filipe Altoe had the most liked content!

Community Reputation

28

1 Follower

About Filipe Altoe

  • Rank
    More Active

Profile Information

  • Gender
    Male
  • Location
    Bay Area CA

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2015
  • Since
    1997

Recent Profile Visitors

1,422 profile views
  1. #trocadepasses cala boca Roger. Deixa os convidados falarem.

  2. @sxavierfilho Seria interessante ver o que o Rodrigo Caio pensa disso. Será que algum repórter pode perguntar pra e… https://t.co/Au1Hc49MUn

  3. 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.
  4. 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.
  5. Deploy #LabVIEW code, including the front panel, to #RaspberryPi. https://t.co/tRP8DT5Lj5

  6. 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.
  7. 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.
  8. For the ones who couldn't be at NIWeek 2016: https://t.co/V0E73e5S4M

  9. 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.
  10. 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.
  11. 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
  12. 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.
  13. 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.
  14. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.