ensegre

well, some do... Anyway, many years ago I had too a project with 1.25Mp@500fps. Needed a raid array of 8 hard disks to stream seamlessly, raw bytes only, of course.

It's a complete shot in the dark, but have you tried LD_PRELOAD=/lib/x86_64-linux-gnu/libzmq.so ./labview ?

Seven years later, another incarnation of VPN and ubuntu 20.04, still the very same problem hit me again for LV14.0: immediate crash if started while Checkpoint snx is running, no crash if snx is started afterwards Not with LV2019, not 2021 in the same conditions... Since I need specifically LV14 for a legacy project, I have to remember where I put the 14SP1 installation media.

Today I remarked that synaptic knows about ni-daqmx-labview-2021-support, so I marked it and installed it. I guess that NI repos were not updated. The familiar DAQmx VIs appeared in the palette at LV restart, I can open a VI which uses them. I still have to get hold of some device to test that they really work.

It's spam, as it copied sentences from the first post of Thang in this thread. However, with some syntactic changes .... I wonder if that is AI or a literate poor spam factory worker.

Finally officialized by NI, I see: https://www.ni.com/en-il/support/documentation/bugs/22/ni-linux-device-drivers-2022-q1-known-issues.html, 1860393

anecdotal evidence?

Noting down this mainly for self reference since it occurred to me time and again, in case it helps others too. I have several recent versions of LV installed on Ubuntu 20.04 (with alien). The nice thing is that somehow a NI deb package stream became known to the system, and some package upgrades are found automatically. However there is one caveat: each time the kernel is upgraded, several NI dkms kernel modules need to be recompiled. Usually that is automatically done, but sometimes stumbles on a missing config/modversions.h file. It seems that not every kernel headers package includes it. Missing that, LV crashes as soon as anything needing one such modules is loaded. E.g., as an easy test occurrence, when putting a new VISA control on an empty FP. The solution is trivial: if the (usually empty) file is missing, create it with sudo touch /usr/src/linux-headers-XX.YY.ZZ-generic/include/config/modversions.h where XX.YY.ZZ is the kernel du jour version (e.g. 5.13.0-28 as of today). sudo apt reinstall ni-kal and a reboot then fix the crash.

via ini keys, perhaps? https://labviewwiki.org/wiki/LabVIEW_configuration_file/Execution_System#ESys.StdNParallel

right. In fact, all the three DS... I see. The xnode GetValueByPointer is geared to create the CLN in any thread IIUC its code.

The VIs are in <vi.lib>/Utiity/importsl/

Yeah, https://forums.ni.com/t5/Developer-Center-Resources/Dereferencing-Pointers-from-C-C-DLLs-in-LabVIEW/ta-p/3522795?profile.language=en. Still I miss at the moment how to write in memory without writing a wrapper. Btw IMAQ has also https://zone.ni.com/reference/en-XX/help/370281AG-01/imaqvision/imaq_mempeek/, but again only for reading. [in linux, we're talking of /usr/local/natinst/LabVIEW-XX/resource/libmgcore.* I guess]

From memory, basically these. Though not quite, because the write part appears to want a Cstring, and thus stumbles on zeros in the data. I think the most frequent case I had to deal with was that of a library returning the buffer to a filled pointer, which I only had to read.

You display a NI badge and you're asking this from us??? What is this, a joke? Anyway, the problem is solved for NXG and so there is no need to ask further. https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Support-Unicode/idi-p/921449

Also I don't understand the purpose of your while loop

well, they are different, they measure different things. The question would be what is more meaningful in one or another use case. When I started thinking at it I had in mind an input corrector (which I'm not sure I'll really pursue) which warned the user about possible misspellings and likely corrections, but then one might consider that compared to "Digital input D1", "digital input D2" may be more right than "diggital input D1". Heuristics.

The download page says that the package is for 32bit, but all the rpms provided in it are x86_64, and so assumes the INSTALL file at quick skimming through it; OTOH $ file /usr/local/natinst/nifpgacompileworker/CompileWorker.exe /usr/local/natinst/nifpgacompileworker/CompileWorker.exe: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows I added /usr/local/natinst/mono/lib64 to /etc/ld.so.conf and sudoed ldconfig, but I remained at the same point. I think I'll leave it as "whatever", for now, I see that for the project in question I have other compilation options, so I can live without. But thanks anyway for the feedback, Rolf!

Here they come for 2019. For the little these require sets, i.e. only to find the common elements among two character arrays, I think that it would be pretty easy to reimplement them without, for earlier versions. StrikeAMatch.vi StringDigrams.vi

Thanks, I'll check your one too. I've seen out on the internet that the most popular method suggested is the Dice (strike a match) metric, followed by the Levenshtein, beyond that it looks as it is mostly for theoreticians. Since the metrics have different merits, I have yet to figure out which may be better for what I have in mind. In the meantime, however, here is my quick implementation of Dice. LV2021, based on sets, hence not so backportable (down to 2019, perhaps). StringDigrams.vi StrikeAMatch.vi

I see. So your one seems pretty similar to the Strike a Match, IIUC, with the differences that 1) it strips away from the strings all chars not in [0-9,a-z] (what, no uppercase?) (good for literal strings, but otherwise not always) (could be probably done more synthetically with a regexp), and that it uses the arithmetic sum of two ascii codes instead of a true digram, which can create more false matches. A starting point anyway, thanks.

Out of curiosity, does anyone know of an available labview implementation of a string similarity algorithm? I might have a use case for it in a coming project. I've seen that out there there is a lot, so at worst I might end up toying with reimplementing one. e.g. https://stackoverflow.com/questions/653157/a-better-similarity-ranking-algorithm-for-variable-length-strings?noredirect=1&lq=1 https://en.wikibooks.org/wiki/Algorithm_Implementation/Strings/Dice's_coefficient

of course, this I've done by the book as many other times.

Thanks, good to see them. I hadn't done that much, the dependencies I had already picked up probably from whichever other installation, and yet vipm works fine for me with LV2019. In particular these links and +x seems unnecessary for me: (anyway I tried it and does not magically allow connection to 21)

one issue which I had but overcame, about listing, was that the binary of 20 and 21 is /usr/local/natinst/LabVIEW-xx/labviewprofull instead of just labview. A symlink made them appear in the list. Connection to them still fails though.

Is anyone anyway able to use this vipm with LV>2019? I've just checked two installation which connect fine to LV2019, but not to 2020 nor 2021. Standard settings of vi server port & authorization checked by the book. Or are recent versions of LV simply not supposed to be supported by that old release of vipm?