dadreamer

Only when I disable the wrapper generation on the CLFN, I see some small performance gain in MoveBlock against Replace Array Subset: So, in all other use-cases the native nodes do their job just fine and they're much simplier to use (and more safe also). That is just a PoC method to show, that the work with arrays could be done "traditional way" in LabVIEW too as in text-based languages. I even suppose, Replace Array Subset and In Place Element Structure were both optimised/tweaked in some ways to behave better even in a dumb memory copying.

Yeah, I guess it's obvious for (almost) every programmer. And well illustrated by the 4th method with MoveBlock call. Looking at that one might say, this is how the replace operation is made internally. By the way it's possible to speed up MoveBlock method a little disabling the wrapper generation. But still it is inferior in speed to the native methods (i.e., Replace Array Subset and In Place Element Structure).

Maybe then you will find that VI interesting as well. I made that to compare different methods to replace rows/columns in the array (four known at the moment).

So try to pass this cluster to your DLL (Adapt to Type -> Handles by Value) and see what will happen. In theory you should receive NetworkPortNumber in lower half (I32) of v.

Just pass a 8 bytes wide element as an union (U64 / double / 8 x U8 cluster) and treat it according to the type field after the function call. But I also see, that you have to pass a struct (i.e., a cluster), not a single union. So you should bundle order, type and label fields to your cluster as well. I don't see a definition of valueType and valueLabel items of the Value struct. Assume, they are enum (I32) and long (I32), is that correct? I'm also kind of unsure, who is responsible to set the return type (long, unsigned long, double or string) - the caller or the callee?.. If it's the caller and you want the return to be a string, you have to allocate the necessary amount of memory for char *s (DSNewPtr and friends) and deallocate it later. If it's the callee, then when you're getting the return as a string, you have to deallocate that string, when done with it.

You could try the VIs from here: FFMPEG scripting in LabVIEW (.NET). In FFMPEG Examples v1.1.zip archive you may find yuv420p to RGB.vi, that should do the work for you. Also take a look at yuvplayer, it might be helpful to verify that you're doing the conversion properly.

Well, seems like I had to say that LabVIEW also should behave as RTE does, but it does not for some obscure reason. So, my bad in phrasing there. It's not so easy to answer, not knowing how Vision internals work. I suppose, it has something to do with the way, how Vision's memory manager allocates memory. Perhaps it's more optimized to work in LabVIEW and less (or not) optimized for EXE's. I noticed that in IDE IMAQ Create takes nearly the same amount of time to run (0,03 to 0,06 ms), while in RTE that amount starts at 0,03 and raises on each iteration. Here are the shots to illustrate. IDE: RTE: Maybe someone from NI could elaborate on these differences?.. By the way, I found two more similar issues [1, 2] and the reason behind each one was not clarified.

Same behaviour here on LabVIEW 2020 64-bit, but... Do you really need to create and store in memory 10 000 images at once? I'm even not surprised, that both LabVIEW and RTE go crazy trying to do that. When I take IMAQ Create out of the loops, the situation improves significantly. IDE: 0,1 s for the extracts, 0,4 s for the thresholding EXE: 0,2 s for the extracts, 0,4 s for the thresholding Of course, there's no any reason to divide the whole processing into two separate loops in this case (because you would get the same image slice on all 10 000 iterations. Instead there's a need to do the entire processing in one loop and finalize the image after the loop with IMAQ Dispose. With this approach you'd reuse the same memory location on each interation instead of making a new one. If you need to run the processing in several threads, just create N IMAQ images before the loop, do your things and dispose them, when all the work is done.

I believe it appears to be SQL Toolkit for G, that was superseded by SQL Compatibility VIs from Database Connectivity Toolset, which is named as LabVIEW Database Connectivity toolkit these days. I'm sure, you even could try to replace some of your obsolete VIs to their counterparts from \vi.lib\addons\_SQL directory, if you install Database Connectivity toolkit. As to where you could download that old SQL Toolkit, I'm at a loss to suggest as it was obsoleted a long time ago (LabVIEW 5.0 or so), thus likely no any alive links to download that now.

Maybe you could figure out more information, when you add these lines to your labview.ini: You need to restart LabVIEW after that. When started, it will create DPrintf text file near labview.exe with a tons of a technical information. That info is often very low-level and internal to LabVIEW development, so it may be difficult to analyze. But it's something at least.

How to get a list of image buffers? When I need some piece of code to run in a few instances simultaneously, I just set unique image names based on the meaning/purpose, what that code is invoked for (e.g., "sensor 1 - binarization" or "scanner - edge locator" and sort of). No extra magic here. And I even don't dispose the rest of images, as they are always reused on subsequent runs of the program (and between loop iterations too). Although I never launched too many IMAQ code in parallel (max. 5 threads, I think).

It's difficult for me to figure out the reasons behind your situation as I don't have your application and cannot do some tests with it. To me it looks like you don't have all the necessary dependencies extracted, thus LabVIEW fails to open the VI (assuming that you've done every step from the instruction properly). Are you receiving the same message when placing that VI onto the BD of a brand new VI? Well, I spent some time searching for ways to extract project library files (.lvlib, .xctl, .lvclass) and seems I found one. You might try to complete your file list by doing the following steps. 1. Install Full Featured Run-Time Engine (FF RTE) for your LabVIEW. You may find this package in your installation ISO, e.g. for LV 2019 it is ni-labview-2019-ff-runtime-engine-x86_19.* package from pool folder of LV19 image. 2. Go to C:\Program Files (x86)\National Instruments\Shared\LabVIEW Run-Time\2019 folder (for 32-bit LabVIEW 2019). If you have 64-bit LabVIEW, then you go to Program Files without (x86) ending. There you should have both lvrt.dll and lvffrt.dll. 3. Temporary rename lvrt.dll to some other name and make a copy of lvffrt.dll. Rename that copy to lvrt.dll. Now LabVIEW will start FF RTE when running executables instead of a common RTE. 4. Open your exe and put it into a stopped state (Run button should not be pressed). 5. Now you need to craft a dummy .xctl/.lvclass with the same name, that's assigned to the .xctl/.lvclass, you want to extract. That .xctl/.lvclass should already be loaded into the app's memory. As soon as it's crafted, open it in the same app with File -> Open menu entry. You should receive the following window along with some message. 6. Now you may save the project library with File -> Save Project menu entry. RTE will say, that it's unable to save inside the executable and offer you a browse dialog to choose the path to save. 7. Place that .xctl/.lvclass near other VIs (Data.ctl, Facade.vi etc.) and try to open it in a common LabVIEW. On opening it should relink all the files, then you save everything. 8. As a bonus you may try to save the main VI or some subVIs, it uses (File -> Save and View -> VI Hierarchy / Browse Relationships entries). But be prepared for RTE to crash suddenly, because it does not always go firmly. For me it did not want to save XControl files at all. Maybe this hack will work for you or you will find a working combination of few techniques... There are not so many LV users, who ever thought of tearing down the exe's, not even saying about bringing the resulting files to a workable state.

You may easily overcome this with the following modification. But you also will need all .xctl and .lvclass' files (that are plain XML after all) from the exe, otherwise your linked VIs won't open properly. Sadly I don't know the way to pull out such files from a LEIF, because App.ExportedVIs property does not return them. I'm not saying now, that you have to recreate .xctl/.lvclass from a scratch, as they are actually stored inside the exe. But the way to extract them is yet to be found.

To extract the VIs out of LEIF section (produced by Fast File Format option) you may try my instruction above. Depending on the number of the VIs in your executable and their hierarchy it may be not that easy, but it's definitely doable at least.

I confirm that in LabVIEW 2020 (both 32- and 64-bit) on Windows. 32-bit LabVIEW dies silently in case of the error, whereas 64-bit LabVIEW shows the following report.

I'm not completely sure (as I never saw that myself), but you likely have encountered a bug with Event Structure names messed up, described here. So you might try what's suggested there - do a total uninstall (including msi...Blast running after all) and then a fresh install including all the service packs and hot fixes. It may solve that issue or may not. If not, then obviously you have to upgrade LabVIEW or alternatively you may figure out, what's your "Mouse Down" even is really named by going through the event names one by one and checking, whether it works when clicking on a pane. There still may be another oddities though.

I mostly agree with Rolf here. Even though it looks definitely doable, if necessary effort is pushed into, it will require a lot of work for sure, be it Import Shared Library Wizard enhancement or some new tools, based on scripting. At the current stage, I do not even believe that someone will do this in relation to LabVIEW, until it would be done for any other widespread programming languages at least. Besides of that, I suppose, some rework of the current Call Library Function Node is required, as it wasn't really maintained in many years and doesn't allow some use-cases to be automated. For example, many WinAPI functions are able to receive a parameter or NULL instead of that parameter, like MessageBox function: int MessageBox( HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaption, UINT uType ); lpCaption can be a string (that is, String -> C String Pointer in CLFN parameters) or NULL (that is, Numeric -> Unsigned Pointer-sized Integer). That Win32 Metadata framework won't ever know, what we want to pass: a string or NULL value. Thus a CLFN would often require a manual fine-tuning for our needs anyway. There are also some nuances in CLFN on Linux and MacOS platforms, e.g. LabVIEW doesn't produce a drop-down function list in CLFN parameters and does not link to system libraries just by name (like it does on Windows), so a manual pointing is needed. Oh wait, this is about Win32, no Linux/MacOS support is planned at the moment. Also no more SLI wrappers from NXG, please - they are terrible!

Here 😉

I have used PostLVUserEvent Manager function for a few times in my own callback libraries to send the video/image data from the framegrabber into LabVIEW. It was always working fine for me. I'm sure, back in the days I have used this code sample as the base for interaction with a callback DLL. On Linux you may use dlopen (instead of LoadLibrary) and dlsym (instead of GetProcAddress) from \usr\lib\x86_64-linux-gnu\libdl.so to pass your callback into the vendor's API.

I used InpOut32 / InpOutx64 few times in the past. It's very simple to use, because the sys driver is already integrated into the dll and is extracted automatically upon a call, so the user has nothing to do besides calling the functions. But I have never tested it in Windows 10 and absolutely unsure, whether it will work or not. I see that the authour has obsoleted that project due to the need of signing, so no guarantee here. Also see the known issues in red. Moreover you might give a try to WinIo or NTPort , even though they are not so convenient to use. I did use WinIo before InpOut and it is signed with a self-signed certificate and can only be used when Windows is running in a "test" mode (when driver signature enforcement is disabled). I did not have any experience with NTPort, because it's rather old and shareware. upd: By the way, I've found my old speaker test, based on InpOut library. It still appears to work even on Windows 10 and LabVIEW 2020 (both 32- and 64-bit). I'm attaching it "as is" - for 32-bit LabVIEW currently, but you may easily switch to 64 bits by changing the CLFNs to inpoutx64.dll and placing this dll into data folder. If you have a motherboard built-in speaker, you'll hear the beeps, when pressing the gray button (excuse me for non-English UI). Speaker_lv8.6.rar

I'm sure, Rolf as the original author of this library will definitely give you a detailed answer about this issue. I would just ask, whether it's the case of calling the library in 64-bit LabVIEW or on 64-bit Windows. Because if yes, then it's not going to work - both ogportio.dll and ogportio.sys are 32-bit in the 4.x release dated 2011 and I don't see anything freshier. As to 1275 error - if it is a WinAPI error code, then its description should be something like this (according to MSDN) : You might try disabling driver signature enforcement to overcome this.

Finally here it is. Refnum_to_Pointer-Linux.zip Refnum_to_Pointer-MacOS.zip Tested in LV 2020 on Ubuntu 20.10 and macOS Big Sur. It's assumed to work in 64-bit editions of LabVIEW only.

Maybe it's not what you are looking into, but did you consider using VI Tags to store, read and write the data? It's contained inside a VI in a dedicated resource section, so it will be inside an EXE after the building as well. It has one disadvantage though - you can't use OS tools to view and edit the data directly, but have to use LabVIEW/RTE to do that. If you're fine with it, then try to give it a go. https://zone.ni.com/reference/en-XX/help/371361R-01/lvprop/generic_m/ https://forums.ni.com/t5/LabVIEW/Darren-s-Weekly-Nugget-04-13-2009/m-p/888538?profile.language=en

I just hardly understand, how new features of NXG could be integrated into classic LabVIEW editions, given that a classic is written on C/C++, whereas NXG is made on C# mostly. It's also worth mentioning, that some code pieces of classic LabVIEW were not updated for decades, so it would take years literally to rework them and reimplement some NXG possibilities (as zooming, Unicode support etc).