Jump to content

Antoine Chalons

Members
  • Posts

    957
  • Joined

  • Last visited

  • Days Won

    34

Antoine Chalons last won the day on April 12 2023

Antoine Chalons had the most liked content!

Profile Information

  • Gender
    Male
  • Location
    Lausanne Area

LabVIEW Information

  • Version
    LabVIEW 2020
  • Since
    1999

Contact Methods

Recent Profile Visitors

19,859 profile views

Antoine Chalons's Achievements

Collaborator

Collaborator (7/14)

  • Very Popular Rare
  • Reacting Well Rare
  • Dedicated Rare
  • First Post Rare
  • Collaborator Rare

Recent Badges

118

Reputation

  1. Ok, would it take a lot of work to port it to Linux desktop or Windows?
  2. Out of curiosity, can you describe a bit your customer project that runs on OS X?
  3. Good to know, I had missed this one. If I do find the time to look into it I'll report back, I've used Derrick's TinyTCP package and loved it.
  4. Hi all, I'm planning to expose metrics for Prometheus to collect (scrap) them. I saw the PromVIEW VIP on GitHub and vipm.io which works in the default Prometheus way : your app runs an HTTP server and Prometheus is configured to connect to it to collect your metrics. My issue is that I run my app on Linux (Ubuntu) and the NI Web Server is not supported on Linux. I've seen that Prometheus can also be configured to collect metrics from a file as long as we follow the correct format, so I will most probably follow this path. As anyone done this or anything similar?
  5. they're called hash marks and indicate where LabVIEW compiler will optimize and fold it into constant code. you hide these by changing your LabVIEW settings in the 'block diagram' page see online help : https://www.ni.com/docs/en-US/bundle/labview/page/block-diagram-objects.html bonus link : https://forums.ni.com/t5/The-Daily-CLAD/LabVIEW-Compiler-Optimizations/ba-p/3482600
  6. The 'App Directory' primitive returns a wrong output when ran from a Shared Library on Linux Desktop (*.so), I have tried on Windows. I reported this to NI, the bug was confirmed in LV2020 and all more recent versions (could also affect older versions) As building Shared libraries for Linux is not too common, I'm not expecting NI to fix this anytime soon, and anyway I wouldn't be surprised if they argued that it's now the admitted behaviour (if people rely on it, it's a feature - not a bug). My work-around is :
  7. sure, in the recent years NI has really improved Linux Desktop support back in 2014 it was really tough! for now 4.2b works fine so no rush, enjoy ski! This weekend I'm ice diving ❄️🤿
  8. I see... Setting up VMs for Windows, Linux and Mac testing will be a challenge 2014 sounds reasonnable
  9. Is it a must to keep this in LabVIEW 8.6? I mean... OpenG has now moved to 2009, which is still pretty old.
  10. is there a publicly hosted repo for this package? I'd be more than happy to help or at least test on Linux Desktop. For us Linux Desktop is the most important and RT Linux is not critical as we are happy with 4.2b
  11. I've also add issues on Linux (desktop) with the version 5.0 please see here : https://forums.vipm.io/topic/8000-unable-to-install-on-linux/ for details, I'm reverting to 4.2.1b1 for now
  12. Emerson's catch phrase seems to be 'be bold', NI's was 'engineer ambitiously' Maybe someone misunderstandood and NI went to 'be bald' Is it just me or today's webcast was desperately empty?
  13. Well.. not directly, but a LabVIEW built EXE can script the LabVIEW IDE to build an EXE. Of course you need a computer with LabVIEW IDE installed & a valid licence that includes App builder.
  14. Yeah... LabVIEW everywhere was a slogan when LabVIEW RT was released. It was cool at time! I don't think NI's focus is to make it possible to deploy your LabVIEW code to some cheap hardware that generates no revenue for them... As for your question about the repo, if I understand correctly, it's the source of the OS called 'NI Linux RT' fork for RT targets (cRIO, PXIs, IC, etc.) , I once heard there was a way to install NI Linux RT on some Intel PCs, never actually seen it though. Edit : you might want to read this : https://www.ni.com/en/shop/linux/introduction-to-ni-linux-real-time.html
  15. Thanks for trying! I did try with LabVIEW 2022 and get the same result on CentOS 8 On Ubuntu 20 I never had this issue with LabVIEW 2020 SP1 or 2022 Also I saw this old post from Mickael who had a similar issue back in 2014 : and interestingly, on the second start of LabVIEW 2022, the system exec.vi works BUT compiling still fails with the same feedback
×
×
  • Create New...

Important Information

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