ensegre

Indeed, it is buffer preallocation what makes the difference. In my first solution I presume that the compiler is implicitly allocating the output buffer, knowing N and the sizes of the input. Shaun's solution beats all because is in place and the allocation of the input is not accounted for, but destroys the original input. demo3.vi

This is about three times faster for me: demo2.vi

I'm getting immediate segmentation faults when trying to run the import .so wizard, on an ubuntu 20 machine where I have installed LV14, 19, 2021 and 2023 (up to date). All versions of LV appear to behave normally during my usual workflow, but now crash immediately after choosing Tools/Import Shared Library, and displaying the first window of the wizard. I tried to launch LV through ddd, and the only hint I'm able to get is that there is a segmentation fault in early /usr/local/natinst/LabVIEW-XX/resource/headerparser.so. I've tried different versions, running LV as root, clearing cache at no avail. Only a couple of times I was able to go through the dialogs the wizard down to the point of starting the compilation (after choosing .so, .h, include dir, functions to wrap, arg types), but since then not again. Any idea about what could be wrong and how could I debug further?

I landed over https://www.emerson.com/en-us/esg/environmental-sustainability "Greening Of. Greening By. Greening With"🤣

you can do without the Mouse Down event at all, and just use the New Val connector of the Value Change event Bug radio Button-1.vi

For those ignorant as me, https://redis.io/ . Given the shame that shared network variables are, I would tend to say that any other solution, no matter how much of a contraption, might be attractive. I'm curious to read opinions too, as well as ideas for a LV API.

This text has been generated by AI, right? Because it reads like that BS...🤣 We're getting old. In my time, we were just happy laughing about papers generated by "context free grammar generators".

Vistek provides a linux sdk, you could go the hard way and wrap it (I have no experience with this particular SDK, though I've managed to wrap others of other camera vendors across the years)... In case v4l talks to it, maybe adapting this .... Good luck....

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019NYXSA2 https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8MGSA0

So thank you for 16:49 minutes of our time to teach us how to install LabVIEW on windows and what is an Express VI, I think this is really needed in this forum. I prefer to remain ignorant about it. So, these are usb cameras presumably handled by IMAXdx like thousands of others. What's special in them?

Wow, cd /usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE sudo mv lin lin32 sudo ln -s lin64 lin just did it. Compilation time on the linux machine in this case turned out to be 33% larger than locally on the windows machine, but anyway.

Coming back to it, after one year. It turned out, my installation of the worker does run, it was only the gnome menu item which fails: its associated command /bin/bash -c 'cd /usr/local/natinst/nifpgacompileworker/ && /usr/local/natinst/nifpgacompileworker/cw_wrapper.sh mono /usr/local/natinst/nifpgacompileworker/CompileWorker.exe' fails because of mono, as reported above. Omitting mono, or even just running /usr/local/natinst/nifpgacompileworker/CompileWorker.exe directly, the worker comes up, and I do connect to a Windows machine on which LV14 runs as a compilation server. So far so good. Now if I launch the FPGA compilation on the Windows machine, the preliminary steps are done, the job is submitted to the linux worker (I see logs of it both in the compilation window and on stdout of the linux machine). However, the compilation errors out at its very beginning. The log tells essentially /usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE/bin/lin/_cg: error while loading shared libraries: libSM.so.6: cannot open shared object file: No such file or directory which looks to me as a bitness problem. To test, I have tried to launch $ export LD_LIBRARY_PATH=$DIR:/usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE/lib/lin/:$LD_LIBRARY_PATH; /usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE/bin/lin/_cg /usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE/bin/lin/_cg: error while loading shared libraries: libSM.so.6: cannot open shared object file: No such file or directory whereas I note that I have also lin64 directories, and indeed to call $ export LD_LIBRARY_PATH=$DIR:/usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE/lib/lin64/:$LD_LIBRARY_PATH; /usr/local/natinst/NIFPGA/programs/xilinx14_7/ISE/bin/lin64/_cg The XILINX environment variable is not set or is empty. seems to bring one step forward. Any idea how I could move on from here? I thought of renaming various lin64 directories to lin, but it looks to me like running into a rabbithole. Additional detail, in the meantime I upgraded to "LabVIEW 2020 FPGA Compilation Tool for ISE 14.7". These are not yet officially supported on Ubuntu, so alien --install --scripts.

WFM as well

Same result as Antoine also for me here, LV2021-64, Ubuntu 20 (gcc 9.4.0), both with muParser version 2.1.0 and 2.1.0.2, even specifying the library path directly inside the CLFN, explicitly using the .so in <vi.lib> (2.1.0) or <resource> (2.1.0.2). I'd vote for missing dependency. The moment I'll remember how to check with ld, nm, etc. I'd seek which.

me first

imho linked tunnel and explicit wires through all cases is always the sane thing to do to avoid mistakes. Yes, to save wires you could certainly write your ref into a hidden indicator or into a global variable out of Init, and read the local/global variable in the open camera case, but I'd consider it bad practice and a recipe for future races and less readable code.

AFAIU User events don't need the UI thread, in contrast to events bound to e.g. a value change or a mouse interaction in a FP control or indicator. So unless you implement your shutdown as, say, the response to a value change of your FP stop button, there should be no constraint. Other parts of your code may dictate UI thread though. CLFN configured for UI thread, for instance. The blog I linked above for example mentions that Open VI reference goes root loop if it is connected to a Path wire rather to a string wire; one would not suspect that. (You mentioned in earlier posts that you you call dynamically VIs, didn't you?) (Strict) typedefs, I don't see why should they be related.

Don't use control/indicator properties, and events in it, for example. Or defer all FP updates you can. All these have to compete, in a single thread, with the updates your "spy" (if I got you right) panel is doing, with all its timeseries plots.

Seems like your slowing VIs have parts which force them, maybe for no reason, to run in UI thread?

Update, for those who may have missed, JKI published a beta for linux, which on one installation of mine connects flawlessly to LV21. Problem is, on another very similar one (both Ubuntu 20, both with LV14,19,21), it shows ony LV14 and 19, but not 21, among the list of available versions. And, for the life of me, I haven't found a way to make it recognize it. [This suggestion, removing the Target section from Settings.ini is ineffective, probably outdated] ETA: bingo: once I had also LV2020-64 installed on the second machine, and had a dead symlink /usr/local/natinst/LabVIEW-2020-64/labview -> labviewprofull as a leftover of the removed installation. So this fools VIPM search algorithm, which stops at 2019. I had to peep into /usr/local/JKI/VIPM-2022.0.0.2355-beta/error to realize that.

🤷‍♂️ I came up with this without swearing, though. In truth I still have to test it for real (meaning, that it really compiles smoothly on a target, not just no broken arrow). My goal was to get the job done, not to learn the theory of Xnodes....

I have several, but within bigger applications... Anyway, there are many ways of doing one. The quickest and dirty I can think of is to share the data between main and floating panel via a global variable, to poll periodically the value in the panel, and to trigger a redraw of the chart only when a change between old and current value is detected. Of course this is doesn't scale up very well; for more sophistication you could set up notifiers between the two, transmit only the portion of data which changed. There are several inter-VI communication options, the best one depends on the use case. To make the panel floating and open it pressing a button on from main, etc, VI server FP properties/methods.

Is an ethernet device sitting on the same network of your PC acceptable? Then there are common solutions, common in server cabinets and datacenters. Search for LAN restarter, managed PDU, etc. We are using this one (220V), but there are a number of others. Think of it as a smart timed relay, which publishes its buttons on awebby, but acn also autonomously turn on/off sockets according to a schedule, or upon an ip address not answering anymore to ping.

@infinitenothing, I think I can do what you & danield were looking for, by using first EIOPlaceDownEIONode.vi with an empty State, and then iteratively adding channels with EIONode_ScriptAddChannel.vi, simply providing the channel name. Using LV2014 (for legacy FPGA support), the VIs are in C:\Program Files (x86)\National Instruments\LabVIEW 2014\vi.lib\eio\EIONode. At first was that I was trying to call only EIOPlaceDownEIONode with a populated State array, but that has too many fields to fill in which I wasn't able to guess nor to retrieve from a working example; only passing 'alias' is not sufficient to link with the right resource. So yes, this is actually OT because it is not about Hybrid Xnodes or whatever...