Antoine Chalons

Would it be possible to add support for maps / sets - as if they were arrays - ? I can really remember if they were added in LV 17 or 18 or 19....

out of the blkue, this issue just appeard on my LV2019 after installing LV2020 😮 Thx for publishing the fix.

Do you have access to any hardware? "Technical task" is a bit vague... A few years ago I started playing around with https://projecteuler.net/ It was a fun way to practice algorithms with LabVIEW, I think I solved the first 50 or 60. I'm not sure if this is "technical" Any idea on what you like to do? Any special interest? What's your course?

Welcome! What you're looking for is called a shift register : https://www.ni.com/getting-started/labview-basics/shift-registers

You can run multiple instances of the same LabVIEW version by adding the following key in your LabVIEW.ini file AllowMultipleInstances=True I have never tried to have more than one L Instance running the application builder at the same time... Now that I think of if it, I've never even tried to use an instance for coding while another instance is compiling. LabVIEW crashes so well without trying all that... I rarely run multiple instances at the same time anyway. The alternative I can suggest is to use a dedicated build machine (virtual or not depending on you IT infrastructure)

I've just installed the whole LV2020 SP1 env and updated my IC-3173, and now I can't reproduce these issues.

Bug described on NI Forum : https://forums.ni.com/t5/LabVIEW/Map-weirdness-on-Linux-RT/td-p/4114641 With video and code. I would be eternally thankful if anyone could try to reproduce on various Linux RT targets with LabVIEW 2020.

I'm confused... what is the connection between SQLite and PostgreSQL?

Here is a nice one, see my post on NI Forums found in LV2019 SP1, if someone could check LV2020, it would be nice.

My informations from inside NI is that this is largely untrue. NXG team will be re-assigned to other projects and a large part focusing on non-Windows OS support 😮 I don't have much details but different sources corroborate this.

Just out of curiosity, how much work was it to reverse engineer the CDF and create the installer in order to be able to install the lvzip library on a RT target from MAX? For the SQLite3 library it might be made more complicated by external dependencies of the libsqlite3.so... But NI is planning to release a new RT Linux with support for SQLite 3.31.1, see here.

If you want NI to update the SQLite version available via opkg, vote here.

I'm not sure where the best place was to post this information, so the original post is on the NI forums (wider audience I think) To make it short, the dll included in the SQLite package is version 3.32, but the latest you can install via opkg on NI Linux RT target is 3.22 The consequence is that some features will not work on Linux RT, it is possible to get the source code from SQLite.org and compile an so file from 3.34, check the link above. Anyone knows if it's possible to include that in the SQLite package in order to deploy the library to Linux RT target via MAX or something? I know @Rolf Kalbermatter did something similar for the LVZip package to deploy the library to Linux RT...

Here is the best I could find : https://forums.ni.com/t5/LabVIEW/Isn-t-it-time-for-LV-2020-SP1/m-p/4108112#M1184087

I think when NIWeek was moved to may instead of august they said the release cycle might change, I think AQ posted something about that on LAVA, can't find it though.

I'm sure you'll get plenty of different opinion on that topic. My rule is to only use SP1 versions for customer release (not sure NI will continue using the 202X and 202X SP1 pattern though). I remember reading a blog post from John Pasquarette in which he described the bi-annual release cycle that started in 2009 but I can't spot the article again.

- I have no idea if what I'm going to say makes sense or not - on Windows the CLFN were all "any thread" and it worked fine.

Ok, it took me some time but in the end, all I had to do to make it work is to set all the CLFNs to run in the UI thread. I'm not a regular user of CLFNs so I'm not sure why and if it was the obvious thing to do but there we are.

It just wasn't installed by default... https://forums.ni.com/t5/NI-Linux-Real-Time-Discussions/LDD-on-NI-Linux-RT/m-p/4111499/thread-id/3368#M3369

It look like ldd should always work... 😢

yeah... well I've tried various different amounts and waited for the full moon but it's still stuck. After doing some digging 9.6 and 9.4 seem to have the same function names and the same arguments for the functions, so now I'm looking at the dependencies. On Windows, Dr Powell includes libeay32.dll, libintl.dll & ssleay32.dll, so now I've got to rabbits to chase : - my Linux RT is 64bit, so could that be an issue - I can't find equivalent *.so file for these 3 dll When I run # opkg depends libpq* I get this And all 3 are installed with correct permissions If anyone has any idea...

Actually - for me - Linux is always a big roadblock 😢 I've taken a similar approach to what you did with SQLite - finding the lib path once at connection, store it in the class private data and setting all the CLFN with a library path input. Of course running that on Windows goes fine, but when trying to run it on a Linux RT target (I have an IC-3173), as soon as the running code gets to a VI that calls the libpq.so.5.7 the execution stops and I get a message that the target was disconnected. I checked the access right for the file /usr/lib/libpq.so.5.7 and they look fine for the account "lvuser" I'm now thinking the issue in libPQ version because I followed this tutorial to install PostgreSQL client on NI Linux RT, it installs version 9.4.17 (latest available on http://download.ni.com/ni-linux-rt/feeds/2019/x64/core2-64/) and the version used in the package is 9.6 How can I install PostgreSQL client 9.6 on NI Linux RT ?

cool, I'm on it. I'll clone your bitbucket repo and create a branch to add RT support. Also, I only have LV2019 SP1, I guess once I'm done someone else can save back to an earlier version.

In reply to Neil's opening, here's my 2 cents about what I suggest NI should do : From what I read in this thread It seems that NI's NXG dev team was made of people who didn't have enough love for LV-CG- or enough experience using LV-CG for real world applications. Well now that NI's plan is to move forward with LabVIEW, my suggestion is that they make every NXG dev spend 50% of their time contributing on LabVIEW related open source project. There's a lot of great project on GitHub, Bitbucket, GitLab, etc. started by passionate LabVIEW users who have the greatness to share their toolkits, frameworks, API, etc. They have limited resources in most cases, so now that NI has a full team of developers with no real purpose and and not enough understanding of what makes LV-CG great, then let's make them contribute to growing the LV-CG eco-system. edit : if you agree >> https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-NXG-dev-team-contribute-to-LV-related-open-source-projects/idi-p/4110996

Actually swiss cheese doesn't have holes, french cheese does. Sometimes proverbs are inaccurate. I'm french.. so no 😉 Lots of white flags in my code 😆