Antoine Chalons

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.

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?

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

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 :

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 ❄️🤿

I see... Setting up VMs for Windows, Linux and Mac testing will be a challenge 2014 sounds reasonnable

Is it a must to keep this in LabVIEW 8.6? I mean... OpenG has now moved to 2009, which is still pretty old.

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

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

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?

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.

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

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

it appears that the system exec.vi just doesn't work, even in the IDE and therefore fails when the build process calls it as shown below, the system exec.vi is runnable but fails with error 42, whatever cmd I try to run

We have a LabVIEW 2020 SP1 project on Linux that compiles well on Ubuntu 20 (not officially supported) We compile as an application and also as a shared library We use the application (with UI) for test and debug and in production we run the shared library as a service We do not use any DAQ or any other NI driver We moved to CentOS 8 (officially supported), fresh install of LabVIEW 2020 SP1 and here the application compiles well but the compiling as a shared library fails, the compilation process runs till the end (or seems to) and then returns the following error : Error 42 occurred at System Exec.vi. Command was "gcc -m64 -shared -g -O2 -fPIC -Wl,-Bsymbolic -I/usr/local/natinst/LabVIEW-2020-64/cintools "synchrohub.c" /usr/local/natinst/LabVIEW-2020-64/AppLibs/lvdll.a -o "synchrohub.so" -lstdc++ -ldl" Any one has any idea what the issue could be? cross-posted to NI forum