Jump to content

ensegre

Members
  • Posts

    549
  • Joined

  • Last visited

  • Days Won

    25

Everything posted by ensegre

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Seems like your slowing VIs have parts which force them, maybe for no reason, to run in UI thread?
  6. 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.
  7. 🤷‍♂️ 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....
  8. 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.
  9. 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.
  10. @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...
  11. 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.
  12. It's a complete shot in the dark, but have you tried LD_PRELOAD=/lib/x86_64-linux-gnu/libzmq.so ./labview ?
  13. 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.
  14. 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.
  15. 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.
  16. 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
  17. 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.
  18. via ini keys, perhaps? https://labviewwiki.org/wiki/LabVIEW_configuration_file/Execution_System#ESys.StdNParallel
  19. right. In fact, all the three DS... I see. The xnode GetValueByPointer is geared to create the CLN in any thread IIUC its code.
  20. The VIs are in <vi.lib>/Utiity/importsl/
  21. 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]
  22. 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.
  23. 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
×
×
  • Create New...

Important Information

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